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

45

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

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

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

Спасибо

Ваш Ответ

9   ответов
2

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

4

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

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

12

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

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

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

НТН,
Мартин

У меня проблема, веб-сервисы (текстовые) могут быть даже быстрее, чем rmi. Итак, что произойдет, если мы используем сериализатор / десериализатор (ы) ex: -jacson для обоих концов. Сериализация и десериализация имеют свои издержки. Какова будет общая стоимость передачи? Будет ли общий процесс быстрее, чем RMI. Это проблема, которую я имею в разработке приложений. Спасибо!
Приятно объяснено, да, RMI используется, когда необходимо совместно использовать сложные объекты. Для получения текстовой информации используйте протокол HTTP, используйте REST или SOAP для удобного чтения данных.
1

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

8

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

Как вы сказали, использование инструментов Sniffing также может быть использовано другими для поиска конфиденциальных данных :)
2

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

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

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

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

ура Хакки

-1

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

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

0

я бы посоветовал Spring remoting. Этот вариант сервисного экспортера поможет RMI.

org.springframework.remoting.rmi.RmiServiceExporter

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

33

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

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

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

Upvoted комментарий выше. Нужно быть очень конкретным, когда кто-то называет что-то «не масштабируемым» или "не готов к производству"; или "не подходит для больших приложений";
Я упоминал выше, что причина, по которой я считаю это проблематичным, заключается в том, что определения классов объектов должны оставаться синхронизированными во всех развертываниях, что означает либо то, что вы должны быть очень осторожны с тем, что вы развертываете, либо очень осторожно, как вы расширяете свои классы. Обе вещи, хотя и выполнимые, часто приводят к ошибкам. Это можно сделать? конечно! это будет работать? уверен, что будет! будут ли пользователи совершать ошибки? наверняка!
& quot; Также он не очень масштабируемый & quot; почему вы думаете, что это не масштабируется?

Похожие вопросы