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

Question

Каковы большие преимущества от JMS над веб-сервисами или наоборот?

(Являются ли веб-сервисы раздутыми? JMS в целом лучше для обеспечения интерфейсов?)

Answer 1

ИЗМЕНЕНО после исправления от Эриксона:

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

---

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

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

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

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

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

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

Источник

Answer 5

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

Answer 6

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

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

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

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

---

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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