Разница между брокером сообщений и ESB
Я прошел через различные вопросы / статьи о брокерах сообщений и ESBs(даже на stackoverflow). Все еще не знаю, каково четкое разграничение между брокером сообщений и ESB? Теперь я пытаюсь сравнить продукты, WebSphere Broker и Mule ESB!!
во-первых, является ли (любая версия) Webshere Broker ESB? Наши ребята из IBM утверждают, что это ESB!(Меня это не удивляет).
моя ограниченная информация говорит мне, что сообщение Брокер работает на модели со ступицей. Однако ESB работает на архитектуре шины. И что это должно означать? Я прочитал, чем если концентратор терпит неудачу (недоступен, я думаю), то брокер полностью терпит неудачу. Что не относится к ESB(так говорят эти ребята). То, что я не понимаю здесь, это "что, если автобус" терпит неудачу?
теперь обычный материал об ESBs и брокерах заключается в том,что они обеспечивают маршрутизацию, преобразование, оркестровку и т. д.. Так если они оба обеспечивают это, то почему я бы предпочел одно другому.
еще одна область конфликта касается трансформации. Esbs облегчает его по-другому по сравнению с брокерами сообщений? Мне бы очень хотелось получить некоторое представление об этом.
теперь поговорим о горизонтальном масштабировании. Кто кого превосходит? Или оба они одинаково масштабируемы с точки зрения сложности(или любых других факторов). Конечно, стоимость мудрая, Брокер Webshpere будет взимать плату за каждую коробку (не говоря уже о каждом процессоре). Я считаю , даже коммерческий мул ESB этого не делает. Оставляя в стороне часть затрат, каковы последствия масштабирования ESB и масштабирования брокера сообщений. Я знаю, что вы можете масштабироваться до уровня обслуживания в ESB. Возможно ли это в брокере сообщений?
5 ответов
вы можете использовать брокер преобразования без служебной Шины и наоборот. Что касается конкретных продуктов, я не думаю, что кто-то из них является чисто одним или другим из-за того, как они дополняют друг друга. Некоторые продукты сильнее в одной области, другие сильнее в другом. Возможно, выбор должен быть сделан на основе того, какая функция лучше всего охватывает индивидуальную проблему.
брокер может иметь лучшие встроенные "блоки lego" для построения цепочки преобразований, чем ESB продукт делает. Брокер, введенный в эксплуатацию в качестве ESB, может быть раздавлен под нагрузкой и плохо масштабируется или может не иметь надежного ведения журнала и инструментов для работы с журналами.
некоторые ESBs позволяют откатывать обновления базы данных и воспроизводить очереди в исправленное приложение после обнаружения и исправления вопиющей ошибки в логике. Я не думаю, что большинство брокеров интегрируют этот уровень транзакционной поддержки. Чтобы это работало на всех ваших "транзакциях", почти должны быть бизнес-мероприятиях (продажа, обновление, смена собственника и т. д.), а не что-то вроде "обновления базы данных RPCish"."
отказ от ответственности: я консультант IBM и специализируюсь в WebSphere ESB. Этот комментарий не оставлен в официальном качестве.
ESB больше из архитектурноакустической картины или принципиальной схемы чем продукт - широко, обслуживани-основанный путь инженерства свободного соединения. Его определение оспаривается и не совсем высечено в камне. В общем, ESB-это набор несвязанных (в техническом смысле) сервисов - они предоставляют интерфейсы и потребляют их из других сервисов. Вообще нет хаб и спицевая архитектура задействованы, хотя могут быть.
IBM, безусловно, продает WebSphere Message Broker и WebSphere ESB как продукты, которые упрощают создание ESB (вместе с аппаратным устройством DataPower). Они имеют различные технологические корни, но имеют некоторое совпадение по назначению. Кроме того, это не значит, что вы не можете построить ESB с множеством других вещей, которые не заклеймены как "продукт ESB".
Это не ответ на все ваши вопросы, но надеюсь, это касается части IBM.
Я только что прочитал эту статью Уди Дахана несколько дней назад, которая может дать вам более четкое представление о том, что я считаю одним из фундаментальных различий.
http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences
цитирую:
правило, что может быть только один издатель для данного события тип-одна из вещей, которые отличает автобусы от брокеров, хотя оба явно позволяют есть несколько подписчики
...
к сожалению, есть много брокерские технологии там которые продаются под баннер служебной шины предприятия. Пока некоторые продукты имеют способность быть развернутым в обоих централизованных и распределенная мода (иногда называется "федеративный" или " встроенный" mode), многие не применяют " один конечная точка публикации для каждого типа события" правило.
без этого ограничения, это просто слишком легко ошибиться.
надеюсь, что это помогает.
разница между брокером сообщений и ESB в основном заключается в слове "шина".
для меня брокер сообщений-это один (обычно большой) процесс, который преобразует данные из одной структуры в другую или изменяет контент.
ESB-это промежуточное программное обеспечение, ориентированное на сообщение (MOM), плюс дополнительные службы, одна из которых может быть брокер сообщений. Таким образом, ESB может включать брокер сообщений в качестве одного из его компонентов. Шина состоит из нескольких процессов, иначе я бы не назвал это автобусом. Характер шины заключается в том, что существует несколько компонентов, обслуживающих различные задачи, каждый из которых общается через маму и придерживается некоторой формы "общего формата данных". Шина будет состоять из: приложений, отправляющих данные в MOM, адаптеров базы данных, брокеров сообщений, мостов MOM и т. д.
разделение немного постепенное, но самая большая разница между архитектурой брокера сообщений и шиной-это гранулярности. Если ваш задача-интегрировать приложения A, B,.., Z и несколько баз данных, вы можете сделать это с одним большим брокером сообщений, соединяющим всех и каждого. Или с ESB, где несколько небольших компонентов берут на себя только небольшие задачи. Например, один адаптер подключается к A, другой - к B (но они не выполняют преобразование), затем каждый отправляет свои материалы одному (или нескольким) брокеру сообщений, каждый из которых должен быть максимально простым-например, не знать о модели данных " A " или "B". Ля хороший ESB должен иметь общее определение данных на шине, абстрагируясь от "различности" отдельных приложений.
преобразование: ESB не помогает с преобразованием, если он не поставляется с брокером сообщений. Но каждый хороший ESB должен включать брокера сообщений в любом случае. Брокер сообщений должен быть экспертом вашей шины для преобразований, но ничего больше.
горизонтальное масштабирование: если у вас есть только 3 вещи для подключения (сейчас и навсегда), это, вероятно, не стоит попытка получить полноценный ESB. Брокер сообщений имеет то преимущество, что он является всего лишь одним большим процессом. Вы можете настроить все там и иметь центральное расположение для всех ваших сопоставлений данных, фильтрации и маршрутизации.
но если у вас есть 30 приложений для подключения, один брокер сообщений, вероятно, придет к остановке. Конечно, вы можете купить больше экземпляров, запускать избыточные вещи и т. д. но вы должны изменить свою стратегию, чтобы "локализовать" рабочие места. Адаптер каждого приложения (может быть один каждый экземпляр брокера сообщений должен иметь возможность генерировать и / или получать абстрактную общую модель данных (e.G XML с общим XSD). Также может быть центральный брокер сообщений для задач преобразования, но этот экземпляр должен не знать о модели данных A или B. Поэтому ESB должен переместить обработку в экспертный компонент вместо того, чтобы держать все в центральном месте.
служебная Шина предприятия предоставляет три ключевых значения для бизнеса:
- контекстная или контент - ориентированная маршрутизация транзакций;
- преобразование из одного домена или транспорта сообщений в другой домен или транспорт сообщений;
- многие-ко-многим подключение услуги.
ESBs обеспечивают свободное соединение служб, позволяют службам быть восстановлены в совершенно разные контексты приложений, чем когда службы были первыми предусмотрено и разработано, и способствует повторному использованию приложений без необходимости переписывать приложения. WebSphere Message Broker (или теперь называется IBM Integration Bus) является ярким примером корпоративной служебной шины. Для примера простоты кода, который приносит большую силу в нескольких строках, вы можете просмотреть мой пост здесь:http://soabus.org/viewtopic.php?f=3&t=13 . Фундаментальная конструкция внутри среды выполнения IIB называется Логическое Дерево Сообщений (LMT). Все, что разработчик хочет сделать, это какой-то тип операции на LMT. ESQL-самый эффективный язык, который разработчик может использовать для выполнения этих операций на LMT, хотя поддерживаются многие другие языки (например, Java, PHP, Python и т. д.) Никакой другой продукт не приближается к эффективности и простоте разработки приложений ESB, чем IBM Integration Bus, поскольку 90 процентов кодирования этих приложений выполняется путем перетаскивания узлов на поддон. Это оставляет только 10 процент кодирования, выполняемого разработчиком потока сообщений. Кстати, WebSphere ESB был прекращен IBM и многие конкурирующие продукты IBM Integration Bus не видели никаких новых разработок на них в течение нескольких лет. Список различных предложений продуктов ESB можно посмотреть по адресу soabus.org - ...