Разница между JMS и веб-службой

Ответ 1

JMS - это API, который абстрагирует промежуточное программное обеспечение для обмена сообщениями, такое как ActiveMQ или IBM MQSeries.

Связующее ПО для обмена сообщениями имеет парадигму типа "store-and-forward" и асинхронную передачу сообщений, в то время как веб-службы имеют тенденцию продвигать синхронную процедуру, вызывающую парадигму. В распределенных системах, где многое может пойти не так, что касается асинхронности вещей, они лучше фокусируют внимание на том, что вам нужно делать, когда часть системы недоступна или плохо работает, а код, необходимый для решения этой проблемы, как правило, много менее сложно.

Элементы кластеризации становятся тривиальными, если у вас несколько серверов, которые прослушивают одну и ту же очередь, parallelism и в этом случае свобода загрузки свободна.

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

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

Если это "просто шлепает удаленный API на webapp", то, конечно, он не платит ни за установку асинхронного обмена сообщениями.

Ответ 2

проверить ссылки

разница между использованием промежуточного ПО JMS/Messaging и веб-служб

Сообщения, JMS и веб-службы

Веб-службы HTTP против JMS

Выбор между JCA, JMS и веб-службами

Служба сообщений Java

Веб-сервис

Таким образом, если связь Приложения используются на основе Java JMS, и если они могут быть разными, то веб-сервисы... вот что я следую.

Ответ 3

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

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

JMS - это разумный API для взаимодействия с шиной обмена сообщениями, и я обнаружил, что Active/MQ здесь очень хорош. Active/MQ поддерживает JMS на многих языках.

При обмене сообщениями вы можете использовать шаблон интеграции "запрос/ответ" для получения ответов и возврата их через веб-службу. Однако подумайте о том, заслуживает ли немедленная обратная связь вопрос о том, был ли обработан порядок, а также от того, что заказ был получен; вам может не потребоваться выполнить запрос/ответ, чтобы подтвердить, что заказ получен.

Преимущества обмена сообщениями можно найти здесь: http://www.eaipatterns.com/Messaging.html

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

Ответ 4

Для обеспечения совместимости используйте веб-службу. JMS мало используется вне Java-мира.