Разница между брокером сообщений и ESB

Question

Я прошел через различные вопросы / статьи о Message Brokers и ESB (даже о stackoverflow). До сих пор не знаю, что такое CLEAR, разграничивающая Message Broker и ESB? Теперь я пытаюсь сравнить продукты, Websphere Broker и Mule ESB !!

Во-первых, является ли (любая версия) Webshere Broker ESB? Наши парни из IBM заявляют, что это ESB! (Я не удивлен этим).

Моя ограниченная информация говорит мне, что Message Broker работает на модели HUB-SPOKE. Однако ESB работает на архитектуре шины. Теперь, что на земле это должно означать? Я прочитал, что, если HUB отказывает (недоступно, я думаю), то брокер полностью отказывает. Что не относится к ESB (так говорят эти парни). Что я не понимаю здесь, это «Что делать, если автобус» не удается?

Теперь обычные вещи о ESB и брокерах состоят в том, что они обеспечивают маршрутизацию, преобразование, оркестровку и т. Д. Итак, если они оба предоставляют это, то почему я выберу одно из другого?

Другая область конфликта касается ТРАНСФОРМАЦИИ. ESB облегчают это по-другому по сравнению с Message Brokers? Мне бы очень хотелось немного разобраться в этом.

Теперь поговорим о ГОРИЗОНТАЛЬНОМ масштабировании. Кто кого превосходит? Или они оба одинаково масштабируемы с точки зрения сложности (или любых других факторов). Конечно же, брокер Webshpere будет взимать плату за каждую коробку (не говоря уже о каждом процессоре). Я верю, что даже коммерческий MULE ESB этого не делает. Оставляя в стороне часть затрат, каковы последствия масштабирования ESB и Message Broker. Я знаю, что вы можете перейти на уровень обслуживания в ESB. Возможно ли это в Message Broker?

Answer 1

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

У брокера могут быть лучше встроенные «лего-блоки» для построения цепочки трансформации, чем у продукта ESB. Брокер, введенный в эксплуатацию, поскольку ESB может быть сломлен под нагрузкой и плохо масштабироваться, или может не иметь надежного ведения журналов и инструментов для работы с журналами.

Некоторые ESB позволяют откатывать обновления базы данных и воспроизводить очереди в исправленном приложении после обнаружения и исправления вопиющей ошибки в логике. Я не думаю, что большинство брокеров интегрируют этот уровень поддержки транзакций. Чтобы это работало во всех ваших «транзакциях», вам, скорее всего, должны быть деловые события (продажа, продление, смена владельца и т. Д.), А не что-то вроде RPCish «обновления базы данных».

Answer 2

Отказ от ответственности: я являюсь консультантом IBM и специализируюсь на WebSphere ESB. Этот комментарий не оставлен ни в каком официальном качестве.

ESB - это скорее архитектурный шаблон или концепция, чем продукт - в общем, сервисный способ проектирования слабой связи. Его определение обдумано и не совсем заложено в камне. В общем, ESB - это набор несвязанных (в техническом смысле) сервисов - они предоставляют интерфейсы и используют их из других сервисов. Обычно здесь не используется хаб и спица, хотя это может быть.

IBM, безусловно, продает и WebSphere Message Broker, и WebSphere ESB как продукты, облегчающие создание ESB (вместе с аппаратным устройством DataPower). У них разные технологические корни, но они частично совпадают по назначению. Кроме того, это не значит, что вы не можете создать ESB с множеством других вещей, которые не обозначены как «продукт ESB».

Это не отвечает на все ваши вопросы, но, надеюсь, относится к части IBM.

Answer 3

Разница между Message Broker и ESB состоит в основном из слова «шина».

Для меня Message Broker - это один (обычно большой) процесс, который преобразует данные из одной структуры в другую или изменяет содержимое.

ESB - это промежуточное программное обеспечение, ориентированное на сообщения (MOM), плюс дополнительные сервисы, одна из которых может быть брокером сообщений. Таким образом, ESB может включать Message Broker в качестве одного из своих компонентов. Шина состоит из более чем одного процесса, иначе я бы не назвал это «шиной». Природа шины заключается в том, что существует несколько компонентов, выполняющих разные задачи, каждый из которых взаимодействует через MOM и придерживается той или иной формы «общего формата данных». Шина будет состоять из: приложений, отправляющих данные в MOM, адаптеров баз данных, Message Brokers, мостов MOM и т. Д.

Разделение немного постепенное, но самое большое различие между архитектурой Message Broker и шиной заключается в зернистости . Если ваша задача - объединить приложения A, B, .., Z и пару баз данных, вы можете сделать это с помощью одного большого Message Broker, соединяющего всех и каждого. Или с ESB, где несколько небольших компонентов выполняют только небольшие задачи. Например, один адаптер подключается к A, другой к B (но они не выполняют преобразование), затем каждый отправляет свои данные одному (или нескольким) Message Broker, каждый из которых должен быть максимально простым - например. не нужно знать о модели данных «А» или «В». Хороший ESB должен иметь общее определение данных на шине, абстрагируясь от «различий» отдельных приложений.

ТРАНСФОРМАЦИЯ: ESB не помогает с преобразованием, если он не поставляется с Message Broker. Но каждый хороший ESB в любом случае должен включать Message Broker. Посредник сообщений должен быть экспертом вашего автобуса для преобразований, но не более того.

ГОРИЗОНТАЛЬНОЕ масштабирование: если вам нужно подключить только 3 вещи (сейчас и навсегда), вероятно, не стоит усилий, чтобы получить полноценный ESB. Message Broker имеет преимущество в том, что он представляет собой один большой процесс. Вы можете настроить там все и иметь централизованное расположение для всех ваших отображений данных, фильтрации и маршрутизации.

Но если у вас есть 30 приложений для подключения, один Message Broker, вероятно, остановится. Конечно, вы можете покупать больше экземпляров, запускать избыточные вещи и т. Д., Но вы должны изменить свою стратегию, чтобы «локализовать» рабочие места. Адаптер каждого приложения (может быть один маленький экземпляр Message Broker каждый) должен иметь возможность генерировать и / или получать обобщенную общую модель данных (например, XML с общим XSD). Также может быть центральный Message Broker для задач преобразования, но этот экземпляр не должен знать о модели данных A или B. Поэтому ESB должен перенести обработку на экспертный компонент, а не хранить все в центральном месте.

Answer 4

Я только что прочитал эту статью Уди Дахана несколько дней назад, которая может дать вам более четкое представление о том, что я считаю одним из фундаментальных отличий.

http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences

Цитирование:

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

...

К сожалению, есть много технологии брокерского стиля там которые продаются под баннер Enterprise Service Bus. Хотя некоторые продукты имеют возможность для развертывания как в централизованном и распространяемая мода (иногда называется «федеративным» или «встроенным» режим), многие не соблюдают публикация конечной точки по типу события » править.

Без этого ограничения это просто слишком легко совершать ошибки.

Надеюсь, это поможет.

Answer 5

Enterprise Service Bus предоставляет бизнесу три ключевых значения:

1. Контекстная или контентная маршрутизация транзакций;
2. Преобразование из одного домена сообщений или транспорта в другой домен сообщений или транспорта;
3. возможность подключения «многие ко многим».

ESB обеспечивают слабую связь сервисов, позволяют реконструировать сервисы в совершенно иной контекст приложения, чем когда сервисы впервые были задуманы или разработаны, и способствуют повторному использованию приложений без необходимости перекодирования приложений. WebSphere Message Broker (или теперь называется IBM Integration Bus) является ярким примером Enterprise Service Bus. Для примера простоты кода, который дает большую силу в несколько строк, вы можете просмотреть мой пост здесь: http://soabus.org/viewtopic.php?f=3&t=13. Фундаментальная конструкция внутри среды выполнения IIB называется Логическое дерево сообщений (LMT). Все, что хочет сделать разработчик, - это какая-то операция на LMT. ESQL является наиболее эффективным языком, который разработчик может использовать для выполнения этих операций на LMT, хотя поддерживаются многие другие языки (например, Java, PHP, Python и т. Д.). Ни один другой продукт не приблизился к эффективности и простоте разработки ESB. приложений, чем IBM Integration Bus, так как 90 процентов кодирования этих приложений выполняется путем перетаскивания узлов на поддон. Это оставляет только 10 процентов кодирования, выполняемого разработчиком потока сообщений. Кстати, IBM прекратила выпуск WebSphere ESB, и многие конкурирующие с IBM Integration Bus продукты уже несколько лет не видят в них новых разработок. Список различных предложений продуктов ESB можно увидеть на soabus.org.