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

Question

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

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

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

Спасибо

Answer 1

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

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

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

Answer 2

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

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

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

НТН,
Martin

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

org.springframework.remoting.rmi.RmiServiceExporter

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

Answer 9

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

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