JMS и ESB - как они связаны?
Для меня JMS и ESB кажутся очень взаимосвязанными вещами, и я пытаюсь понять, как именно они связаны.
Я видел предложение, что JMS может использоваться в качестве транспорта для ESB - тогда что еще, кроме транспорта, должно присутствовать в таком ESB? Является ли JMS простым ESB или если нет, то чего ему не хватает в реальном ESB?
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
И затем все, что нам нужно, - это немного хитрости в самой системе очередей, чтобы затем передавать сообщения из очереди запросов в платиновую очередь или стандартную очередь.
Так что это возможность маршрутизации на основе контента, и это то, что обеспечивает ESB. Обратите внимание, что ESB использует фундаментальные возможности очереди, предлагаемые JMS.
Второй тип связи заключается в том, что потребитель и производитель должны согласовать формат сообщения. В простых случаях это нормально. Но когда вы начинаете заставлять многих производителей помещать сообщения в одну и ту же очередь, вы начинаете сталкиваться с проблемами управления версиями. Введены новые форматы сообщений, но вы не хотите менять всех существующих провайдеров.
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
Я бы сказал, что ESB - это как фасад многих протоколов....JMS - один из них.
JMS плохо подходит для интеграции служб REST, файловых систем, S/FTP, электронной почты, Hessian, SOAP и т. Д., Которые лучше обрабатываются с помощью ESB, который изначально поддерживает эти типы. Например, если у вас есть процесс, который выдает файл CSV размером 500 МБ в полночь, и вы хотите, чтобы другая система взяла файл, проанализировала CSV и импортировала в базу данных, это может быть легко достигнуто с помощью ESB - тогда как решение с помощью простого JMS будет плохим. Аналогичным образом, интеграция служб REST с балансировкой нагрузки / переключением при сбое в несколько внутренних экземпляров может быть лучше реализована с помощью ESB, изначально поддерживающего HTTP/S.
ESB предлагает интеграцию с множеством различных протоколов в дополнение к JMS.
Большинство используют JMS за кулисами для передачи, хранения и перемещения сообщений. Одно из таких решений OpenESB, использует сообщения формата XML.
Есть ESB с открытым исходным кодом, который вы можете проверить -
Реализация JMS, такая как ActiveMQ, поставляется с верблюдом, встроенным в них.
Эта трансформация не происходит автоматически. Вам необходимо настроить службу преобразования или записи
С уважением, Раджа Нагендра Кумар, технический директор www.tejasoft.com
JMS - это протокол для связи с базовым уровнем обмена сообщениями. ESB работает на более высоком уровне, предлагая интеграцию с несколькими технологиями и протоколами, одним из которых будет JMS, единообразным образом, что значительно упрощает управление сложными потоками.
Существуют JMS-брокеры сообщений, которые вы можете легко настроить с помощью ESB. https://docs.wso2.com/display/ESB470/JMS+Transport
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
Вариант использования: использование ESB может оказаться непосильным, если все наши взаимодействующие приложения работают на Java и используют один и тот же формат сообщений. Здесь JMS может быть достаточно.