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

Question

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

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

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

Благодаря

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

НТН,
Martin

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

Answer 8

@Martin Klinke

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

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

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

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

веселит Hakki

Answer 9

В Спринге фанатика и показатель SOA в течение многих лет я посоветую Spring Remoting. Этот аромат экспортера услуг сделает трюк для RMI.

org.springframework.remoting.rmi.RmiServiceExporter 

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