Разница между брокером сообщений и ESB
Я прошел через различные вопросы / статьи о брокерах сообщений и ESBs(даже на stackoverflow). До сих пор не знаю, каково четкое разграничение разницы между брокером сообщений и ESB? Теперь я пытаюсь сравнить продукты, Websphere Broker и Mule ESB!!
во-первых , является ли (любая версия) Webshere брокером 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
цитирую:
правило, что может быть только один издатель для данного события тип-это одна из вещей, которые отличает автобусы от брокеров, хотя оба, очевидно, позволяют вам есть несколько подписчики
...
к сожалению, есть много технологии брокерского стиля там которые продаются в рамках баннер служебной шины предприятия. В то время как некоторые продукты обладают способностью для развертывания в обоих централизованных и распределенная мода (иногда называется "федеративным" или " встроенным" режим), Многие не применяют "один конечная точка публикации для каждого типа события" правило.
без этого ограничения, это просто слишком легко ошибиться.
надеюсь, что это помогает.
разница между брокером сообщений и ESB-это в основном слово "шина".
для меня, брокер сообщений-это одно (обычно большой) процесс, который преобразует данные из одной структуры в другую структуру или изменяет контент.
ESB-это промежуточное программное обеспечение, ориентированное на сообщения (MOM), а также дополнительные службы, одна из которых может быть брокер сообщений. Таким образом, ESB может включать брокер сообщений в качестве одного из своих компонентов. Шина состоит из нескольких процессов, иначе я бы не назвал это "автобусом". Природа шины заключается в том, что существует несколько компонентов, обслуживающих различные задачи, каждый из которых взаимодействует через MOM и придерживается некоторой формы "общего формата данных". Шина будет состоять из: приложений, отправляющих данные в MOM, адаптеров баз данных, брокеров сообщений, мостов MOM и т. д.
разделение немного постепенное, но самая большая разница между архитектурой брокера сообщений и шиной-это гранулярности. Если ваш задача заключается в интеграции приложений A, B,.., Z и несколько баз данных, вы можете сделать это с одним большим брокером сообщений, соединяющим всех и каждого. Или с ESB, где несколько небольших компонентов берут на себя только небольшие задачи. Например, один адаптер подключается к A, другой - к B (но они не выполняют преобразование), а затем каждый отправляет свой материал одному (или нескольким) брокеру сообщений, каждый из которых должен быть максимально простым-например, не знать о модели данных " A " или "B". Один хороший ESB должен иметь общее определение данных на шине, абстрагируясь от "различности" отдельных приложений.
преобразование: ESB не помогает с преобразованием, если он не поставляется с брокером сообщений. Но каждый хороший ESB должен включать брокера сообщений в любом случае. Брокер сообщений должен быть экспертом вашего автобуса для преобразований, но ничего больше.
горизонтальное масштабирование: если у вас есть только 3 вещи для подключения (сейчас и навсегда), это, вероятно, не стоит усилия, чтобы получить полноценную ЭСБ. Брокер сообщений имеет то преимущество, что это всего лишь один большой процесс. Вы можете настроить все там и иметь центральное расположение для всех ваших сопоставлений данных, фильтрации и маршрутизации.
но если у вас есть 30 приложений для подключения, один брокер сообщений, вероятно, придет к полной остановке. Конечно, вы можете купить больше экземпляров, запускать избыточные вещи и т. д. но вы должны изменить свою стратегию, чтобы "локализовать" рабочие места. Адаптер каждого приложения (может быть один маленький экземпляр брокера сообщений каждый) должен иметь возможность генерировать и/или получать абстрактную общую модель данных (например, XML с общим XSD). Также может быть центральный брокер сообщений для задач преобразования, но этот экземпляр не должен знать о модели данных A или B. Поэтому ESB должен переместить обработку в компонент expert вместо того, чтобы держать все в центральном месте.
служебная Шина предприятия предоставляет три ключевых значения для бизнеса:
- контекстная или контентная маршрутизация транзакций;
- преобразование из одного домена сообщений или транспорта в другой домен сообщений или транспорт;
- много-ко-многим подключение услуг.
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.