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