Ответ 1
JMS предлагает набор API для обмена сообщениями: поместите сообщение в очередь, кто-то еще, когда-нибудь позже, возможно, географически далеко выведет сообщение из очереди и обработает его. Мы развязали время и местоположение поставщика сообщений и потребителя. Даже если потребитель сообщения не работает некоторое время, мы можем продолжать создавать сообщения.
JMS также предлагает возможность публикации/подписки, где производитель помещает сообщение в "тему", и любые заинтересованные стороны могут подписаться на эту тему, получая сообщения по мере их создания, но на данный момент фокусируются только на очереди capabilty.
Мы отделили некоторые аспекты взаимоотношений между поставщиком и потребителем. Однако некоторое сцепление остается. Во-первых, по мере того, как все выглядит так, каждое сообщение обрабатывается одинаково. Предположим, мы хотим ввести различные виды обработки для разных видов сообщений:
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 использует основные возможности Queuing, предлагаемые 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