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

Я просмотрел разные вопросы / статьи о брокерах сообщений и ESB (даже о stackoverflow). Все еще не понимаете, в чем ЧЕТКО разграничивающая разница между брокером сообщений и ESB? Теперь я пытаюсь сравнить продукты Websphere Broker и Mule ESB !!

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

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

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

Другая область конфликта касается ПРЕОБРАЗОВАНИЯ. Облегчают ли ESB это иначе, чем брокеры сообщений? Мне бы очень хотелось узнать об этом.

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

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

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

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

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

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

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

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

Разница между брокером сообщений и ESB (Enterprise Service Bus) в основном заключается в слове «шина».

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

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

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

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

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

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

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

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

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

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

...

К сожалению, существует множество брокерских технологий, которые продаются под маркой 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.

С тех пор IBM изменила названия своих предложений ESB, поэтому я не буду вдаваться в названия или поставщиков.

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

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

Для возможностей очень высокого уровня, которые предоставляет ESB, вы можете перейти по следующей ссылке => https://en.wikipedia.org/wiki/Enterprise_service_bus