JMS и ESB-как они связаны?

для меня JMS и ESB, похоже, очень связаны, и я пытаюсь понять, как именно они связаны.

Я видел предложение, что JMS можно использовать в качестве транспорта для ESB - тогда что еще, кроме транспорта, должно присутствовать в таком ESB? Является ли JMS простым ESB или если нет, то чего ему не хватает от реального ESB?

26
esb jms

8 ответов

JMS предлагает набор API для обмена сообщениями: поместите сообщение в очередь, кто-то другой, когда-то позже, возможно, географически далеко, берет сообщение из очереди и обрабатывает его. Мы отделились во времени и местоположении поставщика и потребителя сообщений. Даже если потребитель сообщения какое-то время не работает, мы можем продолжать создавать сообщения.

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

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

 if ( message.customer.type == Platinum )
      do something special

очевидно, мы можем написать такой код, но альтернативой было бы иметь систему обмена сообщениями, которая может отправлять разные сообщения в разные места, мы создали три очереди:

 Request Queue, the producer(s) puts their requests here
 Platinum Queue, platinum consumer processing reads from here
 Standard Queue, a standard consumer reads messages from here

и тогда все, что нам нужно, это немного ума в самой системе очередей, чтобы перенести затем messsage из очереди запросов в платиновую очередь или стандартную очередь.

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

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

  Request Version 1 Queue  Existing providers write here
  Request Version 2 Queue  New provider write here, New Consumer Reads here

и ESB подбирает сообщения очереди версии 1 и преобразует их в сообщения версии 2 и помещает их в очередь версии 2.

преобразование сообщений-еще одна возможная возможность ESB.

посмотрите на продукты ESB, посмотрите, что они могут сделать. Поскольку я работаю в IBM, я лучше всего знаком с WebSphere ESB

31

Я бы сказал, ЭСБ-как фасад в ряд protocals....JMS-один из них.

5
  • В дополнение к выше список последних открытых источников ЭСБ - UltraESB

JMS не хорошо подходит для интеграции служб REST, файловых систем, S / FTP, электронной почты, Hessian, SOAP и т. д. которые лучше обрабатываются с ESB, который поддерживает эти типы изначально. Например, если у вас есть процесс, который сбрасывает CSV-файл 500 МБ в полночь, и вы хотите, чтобы другая система забрала файл, проанализировала CSV и импортировала в базу данных, это может быть легко выполнено ESB-тогда как решение только с JMS будет плохим. Аналогично, интеграция служб REST с балансировкой нагрузки / отработкой отказа на несколько бэкэнд-экземпляров может быть выполнена лучше с ESB, поддерживающей HTTP / S изначально.

2

это преобразование не происходит автоматически. Необходимо настроить сопоставление или написать службу преобразования

посмотрите на https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_SOA_Platform/4.2/html/SOA_ESB_Message_Transformation_Guide/ch02s03.html

с уважением, Раджа Нагендра Кумар, С. Т. О. www.tejasoft.com

1

ESB предлагает интеграцию с большим количеством различных протоколов в дополнение к JMS.
Большинство используют JMS за кулисами для передачи, stor и перемещения сообщений. Одно из таких решений OpenESB, использует сообщения формата XML.

есть ESB с открытым исходным кодом, который вы можете проверить -

реализация JMS, как в частности, ActiveMQ приходите с верблюдом, встроенным в них.

1

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

0

есть брокеры сообщений JMS, которые вы можете легко настроить с помощью ESB. https://docs.wso2.com/display/ESB470/JMS + транспорт

0

JMS и ESB оба обеспечивают способ связи между различными приложениями. но контекст для JMS и ESB отличается. JMS для простой потребности. JMS реализуется поставщиком JMS. Он является Java конкретными.

примерами поставщиков JMS являются: Apache Active MQ, IBM MQ,HornetQ и др.

ESB для сложной потребности. ESB является компонентом в EAI снабубежать средство связи различные применения. он является общим и не специфичным для Java. JMS является одним из поддерживаемых протоколов.

примеры поставщика ESB: MuleESB, Apache Camel, OpenESB

Use Case: использование ESB может быть накладными расходами, если все наши коммуникационные приложения находятся на Java и используют один и тот же формат сообщений. Здесь JMS может быть достаточно.

0