Каковы плюсы и минусы использования RMI или JMS между веб-уровнями и бизнес-уровнями?

Question

Для типичного приложения Web-клиента-Servlet / WS-to-Business Tier (Spring или EJB), каковы компромиссы подходов, таких как удаленный RPC или уровень обмена сообщениями для Web (Servlet), к удаленному бизнес-уровню, помимо основных аспектов синхронизации / асинхронности?

Answer 1

Под веб-клиентом вы подразумеваете веб-браузер? Если так, глядя на такие вещи, как DWR или JAX-RS, мои рекомендации. RMI или JMS действительно работают только тогда, когда обе стороны являются Java-кодом.

При использовании любой технологии удаленного взаимодействия самой большой проблемой является их использование в качестве навязчивой технологии для ваших бизнес-объектов. например использование интерфейса RMI / исключений везде или использование JMS API внутри вашего бизнес-кода.

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

Например, см. реализацию Camel Spring Remoting , которая затем позволяет использовать любой из этих транспортов и протоколов , таких как RMI, JMS или даже простой HTTP, электронную почту, файлы или XMPP - затем переключайтесь между ними тривиально, используя простое изменение строки URI.

Answer 2

Мы используем RMI через Spring и находим его очень простым в использовании, достаточно надежным и быстрым. Хотя наши требования касались довольно отзывчивой ссылки, и в действительности не было необходимости добавлять компонент обмена сообщениями.

Answer 3

SUN RMI сломался для нас.

Настройки и сборка мусора для очень долго работающего приложения с непрерывной обработкой сообщений. Мы исправляем, чтобы это работало непрерывно. Приложения JMS, которые мы запускаем, не получают ошибок памяти или проблем с gc, что делает RMI. Все, что необходимо периодически вызывать System.gc () и не работает с инкрементным сбором для восстановления ресурсов, закодировано неправильно.

Надежность RMI повышается с JDK 6 и правильными настройками свойств, но JHC - это сложная структура. RMI будет значительно улучшен за счет использования каналов в nio и исправления использования system.gc () в Sun nio.

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