RMI против веб-сервисов. Что лучше для java2java remoting?
Я новичок в веб-службах и RMI, и мне интересно, какой лучший способ сделать удаленное взаимодействие между различными веб-приложениями, когда все эти приложения написаны на Java, то есть когда разные языки программирования не имеют значения (что было бы преимуществом WS).
хотя с одной стороны я думаю, что есть накладные расходы при использовании веб-служб (у кого-нибудь есть цифры, чтобы доказать это?), с другой стороны мне кажется, что веб-сервисы гораздо более свободно связаны и могут быть использованы для реализации более сервис-ориентированной архитектуры (SOA) (что невозможно с RMI, не так ли?).
хотя это довольно общий вопрос, Каково Ваше мнение?
спасибо
9 ответов
веб-службы позволяют свободно связанную архитектуру. С RMI вы должны убедиться, что определения классов остаются синхронизированными во всех экземплярах приложения, а это означает, что вам всегда нужно развертывать все из них одновременно, даже если только один из них изменен (не обязательно, но это требуется довольно часто из-за последовательных UUID и еще много чего)
также он не очень масштабируемый, что может быть проблемой, если вы хотите иметь балансировщики нагрузки.
в моем mind RMI лучше всего работает для небольших локальных приложений, которые не связаны с интернетом, но все равно должны быть отделены. Я использовал его, чтобы иметь приложение java, которое обрабатывает электронные сообщения, и я был вполне доволен результатами. Для других приложений, требующих более сложного развертывания и работы через интернет, я предпочитаю использовать веб-службы.
используете ли вы веб-службы или более "родной" подход, также зависит от среды. Если вам нужно пройти через прокси-сервер или некоторые корпоративные брандмауэры, веб-службы, скорее всего, будут работать, поскольку они полагаются только на HTTP. RMI требует, чтобы вы открыли другой порт для своего приложения, что может быть сложно (не технически, хотя) в некоторых средах...
Если вы знаете, что эта проблема не является проблемой, вы должны рассмотреть, используя RMI. SOA не зависит от технология так же, как и на хорошем сервисном дизайне. Если у вас есть контейнер EJB, вы можете вызвать сеансовые бобы через RMI и дополнительно предоставить их как веб-службы, если вам действительно нужно, кстати.
производительность зависит от данных, которыми вы планируете обмениваться. Если вы хотите отправить сложные объектные сети из одного приложения в другое, это, вероятно, быстрее с RMI, поскольку он передается в двоичном формате (обычно). Если у вас есть какой-то текстовый/XML-контент в любом случае, web услуги могут быть эквивалентны или даже быстрее, так как тогда вам не нужно будет ничего конвертировать вообще (для связи).
HTH,
Мартин!--1-->
одна вещь, которая отдает предпочтение WS над RMI, заключается в том , что WS работает через HTTP-порт 80/443, который обычно не блокируется на брандмауэрах, может работать за NAT и т. д. RMI имеет очень сложный базовый сетевой протокол, который требует, чтобы вы открыли порты RMI, а также может не работать, если клиент НАТТЕД. Во-вторых, с RMI вы ограничиваете slef связью JAVA-JAVA, в то время как с Webservies такого ограничения нет. Гораздо проще отлаживать веб-службы по проводу, поскольку данные являются SOAP / HTTP , который можно легко захватить с помощью инструментов sniffing для отладки. Я не знаю простого способа сделать это через RMI. Кроме того, RMI действительно очень старый и не получал много внимания в течение последних нескольких лет. Он был большим в те дни, когда Корба был большим, и оба RMI CORBA-действительно устаревшие технологии. Лучшим вариантом является REST style Webservices.
мой опыт работы с RMI и веб-службами отражает ваши догадки выше. В целом производительность RMI намного превышает веб-службы, но спецификация интерфейса явно указана для веб-служб.
обратите внимание, что ни один из этих протоколов требует что приложения с обеих сторон являются Java. Я бы использовал веб-службы, когда у меня был один или несколько внешних партнеров, которые реализовывали интерфейс, но RMI, если бы я контролировал оба конца соединение.
@Мартин Играми Klinke
"производительность зависит от данных, которыми вы планируете обмениваться. Если вы хотите отправить сложные объектные сети из одного приложения в другое, это, вероятно, быстрее с RMI, поскольку он передается в двоичном формате (обычно). Если у вас есть какой-то текстовый/XML-контент, веб-службы могут быть эквивалентны или даже быстрее, так как тогда вам не нужно будет ничего конвертировать (для связи)."
насколько я знаю производительность проблема имеет значение во время сериализации-десериализации, другими словами, процесса маршалинга-демарширования.Я не уверен, что оба эти условия одинаковы btw В распределенном программировании я не говорю о процессе, который происходит в той же JVM,речь идет о том, как вы копируете данные.Это либо pass by value, либо pass by reference.Двоичный формат соответствует pass by value, что означает копирование объекта на удаленный сервер в двоичных файлах.Если у вас есть какие-либо сомнения до сих пор, я хотел бы услышать
что разница между отправкой в двоичном формате и текстовым / xml-контентом с точки зрения маршалинга-демарширования или сериализации-десериализации?
Я просто догадываюсь.Это не зависит от того, какие данные вы отправляете.Какой бы тип данных вы ни отправили, он будет частью процесса маршалинга-демарширования и в конце будет отправлен в двоичных файлах, верно?
ура Хакки!--1-->
Как насчет Spring Remoting. Он сочетает в себе REST-подобный протокол HTTP с двоичным форматом RMI. Отлично работает для меня.
Как весенний фанатик и показатель SOA в течение многих лет я бы посоветовал весеннее дистанционное управление. Этот аромат экспортера услуг сделает трюк для RMI.
org.springframework.remoting.rmi.RmiServiceExporter
другое транспорт, конечно. Сериализация вещь вполне управляема, если вы версии интерфейсов (конечных точек) и DTOs разумно и управлять uuids сериализации должным образом. Мы постфиксируем "Альфа", "Браво" на наши интерфейсы и объекты и увеличиваем, уменьшаем и изобретаем, где и когда это необходимо. Мы также зафиксируйте наши UUID сериализации в 1 и убедитесь, что изменения являются только добавочными, иначе мы перейдем от "Браво" к "Чарли". Все управляемые в настройке предприятия.
для Spring Remoting (я догадался, что вы имеете в виду http Invoker), обе стороны должны использовать Spring, если это так, это можно обсудить.
для приложения Java для Java RMI является хорошим решением..., JAX-RPC или JAX-WS для связи Java С Java следует избегать, если клиенты не находятся под вашим контролем или могут перейти на другую платформу.