RMI против веб-служб. Что лучше для удаленного Java2Java?

Я новичок как в веб-сервисах, так и в RMI, и мне интересно, какой из них лучший способ делать удаленные действия между различными веб-приложениями, когда все эти приложения написаны на Java, то есть когда разные языки программирования не имеют значения (что было бы преимуществом WS).

В то время как, с одной стороны, я бы предположил, что при использовании веб-сервисов есть накладные расходы (есть ли у кого-нибудь номера, чтобы это доказать?), с другой стороны мне кажется, что веб-службы гораздо более слабо связаны и могут использоваться для реализации более сервис-ориентированной архитектуры (SOA) (что невозможно с RMI, правильно?).

Хотя это довольно общий вопрос, каково ваше мнение?

Спасибо

Ответ 1

Веб-службы позволяют свободно связать архитектуру. С RMI вы должны убедиться, что определения классов остаются в синхронизации во всех экземплярах приложений, а это значит, что вам всегда нужно развертывать все из них в одно и то же время, даже если изменяется только один из них (не обязательно, но это требуется довольно часто из-за последовательных UUID и еще чего)

Также он не очень масштабируемый, что может быть проблемой, если вы хотите иметь балансировки нагрузки.

На мой взгляд, RMI лучше всего подходит для небольших локальных приложений, которые не связаны с Интернетом, но все же их нужно развязать. Я использовал его, чтобы иметь приложение Java, которое обрабатывает электронные сообщения, и я был вполне доволен результатами. Для других приложений, требующих более сложного развертывания и работы в Интернете, я предпочитаю использовать веб-службы.

Ответ 2

Если вы используете веб-службы или более "родной" подход зависит от среды. Если вам нужно пройти через прокси-сервер или какой-либо корпоративный брандмауэр, веб-службы с большей вероятностью будут работать, поскольку они полагаются только на HTTP. RMI требует от вас открыть другой порт для вашего приложения, который может быть затруднен (но не технически, хотя) в некоторых средах...

Если вы знаете, что эта проблема не является проблемой, вам следует подумать об использовании RMI. SOA не зависит от технологии так же, как от хорошего дизайна обслуживания. Если у вас есть контейнер EJB, вы можете вызывать сеанс beans через RMI и дополнительно выставлять их как веб-службы, если вам действительно нужно, кстати.

Производительность зависит от данных, которые вы планируете обменять. Если вы хотите отправлять сложные сетевые объекты из одного приложения в другое, оно, скорее всего, быстрее с RMI, поскольку оно передается в двоичном формате (обычно). Если в любом случае у вас есть какой-то текстовый/XML-контент, веб-службы могут быть эквивалентными или даже быстрее, так как тогда вам вообще не нужно будет что-то конвертировать (для связи).

НТН,
Мартин

Ответ 3

Одна вещь, которая поддерживает WS over RMI, - это то, что WS работает через HTTP-порт 80/443, который обычно не блокируется в брандмауэрах, может работать за NAT и т.д. RMI имеет сложный базовый сетевой протокол, который требует открытия портов RMI, а также может не работать, если клиент NATTED. Во-вторых, с RMI вы ограничиваете ваш спутник связью JAVA-JAVA, в то время как с Webservies такого ограничения нет. Гораздо проще отлаживать веб-сервисы на проводе, так как данные SOAP/HTTP, которые можно легко захватить с помощью инструментов обнюхивания для отладки. Я не знаю, как это сделать с RMI. Кроме того, RMI действительно очень старый и не получил много внимания за последние несколько лет. Это было большим назад в те дни, когда CORBA была большой, и оба RMI CORBA - действительно устаревшие технологии. Лучший вариант - это веб-службы стиля REST.

Ответ 4

Мой опыт работы с RMI и веб-сервисами отражает ваши предположения выше. В целом производительность RMI намного превышает веб-службы, но спецификация интерфейса явно указана для веб-служб.

Обратите внимание, что ни один из этих протоколов не требует, чтобы приложения с обеих сторон были Java. Я хотел бы использовать веб-службы, когда у меня был один или несколько внешних партнеров, которые выполняли интерфейс, но RMI, если бы я контролировал оба конца соединения.

Ответ 5

RMI может быть лучшим направлением, если вам нужно поддерживать сложное состояние.

Ответ 6

@Мартин Клинке

"Производительность зависит от данных, которые вы планируете обменивать. Если вы хотите отправлять сложные сетевые объекты из одного приложения в другое, это, вероятно, быстрее с RMI, поскольку оно передается в двоичном формате (обычно). имеют какой-то текстовый/XML-контент в любом случае, веб-службы могут быть эквивалентными или даже быстрее, так как тогда вам вообще не нужно будет что-то конвертировать (для связи).

Насколько я знаю, проблема с производительностью делает разницу во время сериализации-десериализации, другими словами, процесс маршаллинга-демаршаллинга. Я не уверен, что оба этих термина являются одинаковыми В распределенном программировании я не говорю о процессе, который происходит в той же JVM, о том, как вы копируете данные. Это либо пропуск по значению, либо передача по ссылке. Бинарный формат соответствует пропуску по значению, что означает копирование объекта на удаленный сервер в двоичных файлах. Если у вас есть какие-либо сомнения до сих пор, я бы хотел услышать

какая разница между отправкой в двоичном формате и текстом/xml-содержимым с точки зрения маршаллинга-демаршаллинга или сериализации-десериализации?

Я просто угадываю. Это не зависит от того, какие данные вы отправляете. Какой бы тип данных вы ни отправили, он будет частью процесса маршаллинга-демаршаллинга и в конце будет отправлен в двоичных файлах правильно?

веселит Хакки

Ответ 7

Как насчет Spring Remoting. Он объединяет REST-подобный протокол HTTP с двоичным форматом RMI. Отлично работает для меня.

Ответ 8

Для Spring Remoting (я догадался, что вы имеете в виду HTTP Invoker), обе стороны должны использовать Spring, если это так, это можно обсудить.

Для Java-приложения Java RMI - это хорошее решение, следует избегать JAX-RPC или JAX-WS для связи Java-to-Java, если клиенты не находятся под вашим контролем или могут перейти на другую платформу.

Ответ 9

Будучи фанатом Spring и экспонентом SOA в течение многих лет, я бы посоветовал Spring удалять. Этот аромат экспортера услуг сделает трюк для RMI.

org.springframework.remoting.rmi.RmiServiceExporter

Конечно, доступны и другие транспортные средства. Сериализация вполне управляема, если вы правильно определяете свои интерфейсы (конечные точки) и DTO, и правильно управляете UUID сериализации. Мы добавляем "Alpha", "Bravo" к нашим интерфейсам и объектам и увеличиваем, уменьшаем и изобретаем когда и когда это необходимо. Мы также фиксируем наши идентификаторы UUID для сериализации до 1 и гарантируем, что изменения являются только дополнительными, иначе мы переходим от "Браво" к "Чарли". Все управляемые в настройках Enterprise.