JMS vs Webservices

Ответ 1

EDITED после исправления от erickson:

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

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

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

Ответ 6

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

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

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

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

Механизмы "точка-точка" и "публикация/подписка" . Структуры на основе сообщений могут передавать информацию другим приложениям без их явного запроса. Та же информация может быть доставлена ​​многим абонентам параллельно.

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

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

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

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

Источник

Ответ 7

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

Ответ 8

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

Какой из них использовать? Зависит от проблемы.

Ответ 9

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

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