В чем отличие сервисной шины предприятия(ESB) от брокеров сообщений (например RabbitMQ)?

Question

[Паша Андреев]

ESB и очереди сообщений. Что между ними общего и в чем они отличаются друг от друга?

Для полного понимания происходящего, посоветуйте фундаментальную литературу, где подробно рассмотрены паттерны (и реализации) межсервисного взаимодействия.

Comments

[epolyak]

Если все упростить, то MQ это транспорт решающий главным образов вопросы доставки данных из системы А до системы В или из системы А до систем В1, В2.... Решающие задачи гарантированной доставки данных и маршрутизации. Как правило построенное на основе очередей. Как работать с этим транспортом определяет его АПИ (как правило достаточно простое) в принципе все. ESB решает куда бОльший круг задач. Как правило в качестве транспорта в ESB используется или внешняя или своя MQ или ее подобие, также ESB предоставляет наборы различных коннекторов, адаптеров, таймеров и других клмпонент. Как правило есть встроенный BPM. Большенство ESB позволяют запускать "под собой" пазличные приложения нечего не подозревающие сто они начали работать в некотором окружении. Как то так.

Answer 1

[Алексей Черемисин]

Простым языком. ESB помогает связать кучу разрозненных приложений в единое целое. Например. Есть старый ftp, email серверы и новое приложение j2ee. Нужно, по приходу файла на ftp сообщить об этом по email и обработав, залить через REST в j2ee приложение. ESB будет сканировать папку на ftp, сообщит об этом по email, отпарсит файло и пульнет результат по http в j2ee.
В нутрях у ESB обычно прячется MQ, но не всегда.

MQ, собственно, занимается умной доставкой сообщений, и только, предоставляя пару тройку API для этого.

Другими словами, ESB не подразумевает внедрения нового кода в старые приложения, MQ требует использовать во всех приложениях совместимый API.

Comments

[Паша Андреев]

Умную книжку бы на эту тему

[Алексей Черемисин]

У!! Сейчаз... Как вариант начать отсюда (для ESB) -www.mulesoft.org
Ну и также почитать конкурентов apache servicemix и apache camel. На просторах интернета также встречал кучу книжек по ним. Ну а про MQ, смотрите rabbitmq, zeromq и далее. Документации и книжек полно!
С другой стороны, чаще для связки легче нарисовать простой скрипт на bash/python/perl или java и не пытаться внедрить ESB-монстров.
И кстати! как пример ESB-подобной архитектуры - spring framework! Хотя они себя так не пропагандируют.

[Алексей Черемисин]

Ах, да, совсем забыл! многие серверы ESB поддерживают транзакции, распределенные, с откатом, по возможности... Но как-то я забил на этих монстров :-( Предпочитаю паттерн KISS всем остальным паттернам.

[Паша Андреев]

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

[Алексей Черемисин]

Ну, как бы это выразиться... С одной стороны это устоявшийся стек технологий, вроде бы как должный работать на любом ESB провайдере. С другой, из-за разных соглашений между вендорами, много упущений и недосказанности. Вы пробовали, например, приложение, написанное под JBoss просто запустить, без переделки, на каком нибудь GlassFish? Конечно там есть куча протоколов, соглашений, реализаций. В типичном случае, как это задумывалось, должно бы обходиться только связыванием уже готовых компонентов через дескриптор описания, и всё. Максимум что, по идее (задумывалось), написать какой нибудь фильтр или коннектор, и, типа, дело в шляпе... Но дьявол, обычно, в мелочах. И начинается, а вот мы сейчас здесь применим кучу JEB, тут напишем правила на BMP, тут применим фильтр (напишем), тут кофеварку включим.. И это для того, чтобы просто отпарсить файл по крону и загнать его в базу данных, уведомив почтовиком...
ESB хороши, но это боооольшой, очень бооольшой, карьерный самосвал, и чтобы его внедрять, нужно сотню раз подумать., а оно действительно так нужно?

[Паша Андреев]

Благодарю за столь доходчивый ответ и комментарии.

Answer 2

[Тимур Шемсединов]

ESB это обычно API в сервисной архитектуре, это RPC или REST, но принцип - атомарный вызов и получение ответов в виде кусков данных, это диалог в стиле клиент-сервер. А вот MQ - это совсем другое, это шины сообщений, тут вообще не происходит диалога в стиле запрос-ответ, а обмен данными происходит по принципу очередей сообщений, которые распределяются между каналами обработки (используется для масштабирования). По сути MQ - это реализация СМО (системы массового обслуживания), по которым можно найти много теории и которые уже давно широко используются в автоматизации технологических процессов на производстве, для транспорта и перевозок, в других сферах. RabbitMQ я не использовал, а про ZeroMQ могу сказать, что это гораздо больше, чем MQ. ZeroMQ - это не только шина событий, но и множество других паттернов обмена данными, как запрос-ответ, публикация-подписка и т.д. Посмотрите полный список этих паттернов: zguide.zeromq.org/page:all Из них можно собирать различные коммуникационные конфигурации. Шины сообщений и броккеры могут использоваться для построения ESB, но как одна из вспомогательных технологий.

Comments

[Паша Андреев]

Ну а все же, что такого мне может предложит ESB, чего нет в брокерах?

[Паша Андреев]

или вы полагаете, что ESB и брокеры - это одно и то же, только с разной архитектурой?

[Тимур Шемсединов]

Это все равно, что спросить, что мне может предложить ресторан, чего нет в сборнике рецептов. ESB - это чаще всего сервер приложений, комплексное решение для обеспечения всех задач предприятия, как то SAP, JBoss, WebSphere, все включено. А MQ - это отдельные технологические решения, ZMQ - это целый конструктор из технологических решений, это поваренная книга, к которой еще нужен хороший повар, чтобы провести проектирование архитектуры и использовать эти рецепты в разработке приложения.