JMS против веб-сервисов

ОТРЕДАКТИРОВАНО после исправления Эриксона:

JMS требует, чтобы у вас был поставщик JMS, класс Java, реализующий интерфейс MessageListener для обработки сообщений, и клиент, который знает, как подключиться к очереди JMS. JMS означает асинхронную обработку — клиент отправляет сообщение и не обязательно ждет ответа. JMS можно использовать в режиме очереди «точка-точка» или с публикацией/подпиской.

"Сервис" - расплывчатый термин. Я думаю о службе как о компоненте, который живет в сети и рекламирует контракт: «Если вы отправите мне X, я выполню эту задачу для вас и верну Y».

Распределенные компоненты существуют уже давно. Каждый из них общался с использованием другого протокола (например, COM, Corba, RMI и т. д.) и раскрывал свой контракт по-разному.

Веб-сервисы — это последняя тенденция в распределенных сервисах. Они используют HTTP в качестве своего протокола и могут взаимодействовать с любым клиентом, который может подключаться через TCP/IP и делать HTTP-запросы.

Вы можете использовать стили SOAP, RPC-XML, REST или «сначала договориться», но основная идея распределенного компонента, использующего HTTP в качестве протокола, остается.

Если вы принимаете все это, веб-сервисы обычно являются синхронными вызовами. Их не нужно раздувать, но вы можете писать плохие компоненты в любом стиле и на любом языке.

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

Системы на основе сообщений, включая JMS, обеспечивают возможность «хронологической развязки» с другим концом. Сообщение может быть отправлено, когда другой конец не доступен.

Все другие распространенные подходы A2A требуют, чтобы партнер мог реагировать немедленно, что требует от него способности справляться с пиковыми нагрузками с небольшой способностью распределять обработку.

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

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

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

Веб-службы — это реализация архитектур, ориентированных на службы (SOA). SOA состоит из трех слабо связанных сторон: поставщика, посредника и запрашивающей стороны. Провайдер предлагает бизнес-услугу, представляющую конкретную реализацию, которая не видна непосредственно запрашивающей стороне. Инициатор запроса узнает от брокера структуру информации, которую он должен отправлять и получать от поставщика, и какой протокол использовать для доступа к этой службе. Заявитель не знает, как провайдер реализует бизнес-сервис.

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

• Они могут быть тесно связаны, а их развертывание может основываться на использовании инфраструктур вызова.
• Они могут работать как в синхронном режиме запроса/ответа, так и в асинхронном режиме.
• Они могут предоставляться провайдерами J2EE или не-J2EE.
• Они могут предлагать или не предлагать поддержку транзакций и безопасности.

JMS – это асинхронный интерфейс на основе сообщений. Вы также можете использовать JMS для доступа к бизнес-логике, распределенной между разнородными системами. Наличие интерфейса на основе сообщений позволяет выполнять следующие функции:

Механизмы «точка-точка» и «публикация/подписка». Фреймворки, основанные на сообщениях, могут передавать информацию другим приложениям, не запрашивая их явным образом. Одна и та же информация может доставляться многим абонентам параллельно.

Независимость от ритма. Платформы JMS работают в асинхронном режиме, но также предлагают возможность моделирования синхронного режима запроса/ответа. Это позволяет исходной и целевой системам работать одновременно, не дожидаясь друг друга.

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

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

Более гибкий обмен. Переключение в режим сообщений позволяет более детально обмениваться информацией.

Источник

Добавил бы это как комментарий к сообщению dyffymo, но пока нет представителя.

Цитата из вашего ответа:

«Веб-сервисы — это последняя тенденция в распределенных сервисах. Они используют HTTP в качестве своего протокола и могут взаимодействовать с любым клиентом, который может подключаться через TCP/IP и делать HTTP-запросы.

Вы можете использовать SOAP, или RPC-XML, или REST, или стили «сначала контракт», но основная идея распределенного компонента, использующего HTTP в качестве протокола, остается».

Я предполагаю, что под веб-службами вы подразумеваете набор протоколов WS-*, WSDL и SOAP. Если это так, то ни один из них не требует использования HTTP в качестве «транспортного» протокола. Набор протоколов SOA не зависит от используемых протоколов передачи, поэтому вы можете использовать HTTP, NamedPipes, необработанный TCP и даже JMS в качестве средств для передачи сообщений в веб-службу и из нее.

Таким образом, в случае прямого использования JMS по сравнению с использованием «веб-сервисов», я думаю, это в основном сводится к инструментам, уровню комфорта и тому, действительно ли вам нужен прямой доступ к какой-либо конкретной функции JMS (которая с помощью WS- * может быть скрыта от ты). На данный момент я бы подумал, что только достаточно специализированные приложения потребуют прямого доступа к JMS.

Из тех, что я сделал, вот отличия, которые я обнаружил: JMS — я привязан к провайдеру JMS — однако у меня есть выбор типа реализации (pub/sub, точка-точка) Веб-служба — проще в обработке/архитектуре - однако это скорее прямая связь между ящиками. Множество инструментов для разработки, а также чистый интерфейс (WSDL), благодаря которому разработчик и вызывающая сторона могут быть независимыми.

Какой использовать? Зависит от того, в чем проблема.

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

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

JMS и WS позволяют распространять приложения. Разница заключается в асинхронности (JMS) и синхронности (веб-службы). Веб-службы могут быть реализованы в стилях SOAP или REST. JMS — это API, который поддерживает связь в двух режимах — точка-точка и публикация-подписка. Apache ActiveMQ, RabitMQ — некоторые из многих реализаторов JMS.