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

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

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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

Ответ 3

Разница между Message Broker и ESB (Enterprise Service Bus) заключается в основном в слове "шина".

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

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

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

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

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

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

Ответ 4

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

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

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

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

...

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

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

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

Ответ 5

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

Context- или content- маршрутизация транзакций;
Преобразование из одного домена сообщений или транспорта в другой домен сообщений или транспорт;
связь многих со многими.

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.

Ответ 6

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

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

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

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