РМИ против.Веб-сервисы.Что лучше всего подходит для удаленного взаимодействия Java2Java?

Question

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

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

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

Спасибо

Answer 1

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

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

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

Answer 2

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

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

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

ХТХ,
Мартин

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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

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

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

Ура Хакки

Answer 7

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

Answer 8

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

org.springframework.remoting.rmi.RmiServiceExporter

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

Answer 9

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

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