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

в чем разница между шиной сообщений [1] и брокером сообщений [2]

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

Как я вижу, единственная релевантная разница - это изображение, используемое для представления каждого из них.

Если между ними есть какая-то разница, скажите, пожалуйста, в чем.
Если они одинаковы, скажите, пожалуйста, почему две концепции относятся к одной и той же функциональности.

Спасибо.

[1] http://www.eaipatterns.com/MessageBus.html
[2 ] http://www.eaipatterns.com/MessageBroker.html


integration messaging routing eai
person Zé Carlos    schedule 29.06.2010    source источник
comment
В книге говорится, что брокер сообщений — это образец архитектуры, а не индивидуальный шаблон проектирования (стр. 324). Я думаю, что шина сообщений может быть одним из типов брокера сообщений, ... но не все брокеры сообщений являются шинами сообщений. Я подозреваю, что на практике между ними много общего. Но вы правы, разница не так очевидна, как могла бы быть. Я обдумывал это несколько дней, для презентации.   -  person FrustratedWithFormsDesigner    schedule 24.11.2020

Ответы (4)


arrow_upward
32
arrow_downward

Шина сообщений подразумевает общий протокол, на котором говорят и понимают все участники. Логики в автобусе практически нет. Обычно сообщение пересылается на все подключенные системы.

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

person Hendrik Brummermann    schedule 29.06.2010
comment
Спасибо. Согласно «Шаблонам интеграции предприятий» Грегора Хопе, внутри шины сообщений есть маршрутизатор. На самом деле, он может поддерживать шаблоны обмена сообщениями, такие как публикация-подписка, так что это не простой повторитель сообщений. Шина сообщений использует каноническую модель данных, но приложения могут использовать адаптеры, поэтому не обязательно, чтобы все приложения использовали один и тот же формат данных. Наконец, вы говорите, что брокер сообщений является центральной частью программного обеспечения, но после его реализации вы можете смотреть на шину сообщений таким же образом (все приложения отправляют сообщения в одну и ту же конечную точку). - person Zé Carlos; 30.06.2010
comment
Спасибо, очень краткое объяснение, через два дня экзамен, это поможет! - person mitchellt; 25.05.2014

arrow_upward
5
arrow_downward

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

Метафора брокера хорошо работает со схемой ступицы и спицы. Метафора автобуса лучше работает в ситуации прямой адресации. Что мешает вашему клиенту отправить сообщение одному из нескольких брокеров, сидящих в шине, узловых или иных? Определения метафор начинают становиться немного глупыми.

Выясните, что вы хотите сделать, и выберите продукт, который делает это лучше всего — подсказка: он, вероятно, будет предоставлять функции как так называемой шины, так и технологии брокера.

person Rick O'Shea    schedule 15.01.2017

arrow_upward
2
arrow_downward

Хорошее объяснение mulesoft о различиях между Message Broker и Enterprise Service Bus -

https://www.mulesoft.com/resources/esb/enterprise-application-integration-eai-and-esb

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

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

person MuzammilUK    schedule 20.08.2016
comment
Добро пожаловать в Stack Overflow! Хотя теоретически это может ответить на вопрос, было бы предпочтительнее включить сюда основные части ответа и предоставить ссылку для справки . - person Enamul Hassan; 21.08.2016
comment
Исправление: это объяснение того, как Mulesoft различает эти термины, к лучшему или к худшему — на самом деле к худшему. - person Rick O'Shea; 15.01.2017

arrow_upward
0
arrow_downward

Согласно урокам Уди Дахана (парня, который изобрел NServiceBus): «.. архитектурный стиль шины [является] ортогональным архитектурному стилю брокера. Брокеры, как правило, больше ориентируются на [технические] границы системы [одна система — это мобильное приложение iOS, созданное одной командой, другая система — это серверная часть Java, созданная другой командой, ..]. Сервисы и архитектурный стиль шины ортогональны/сквозны многим из того, как строятся системы». (В настоящее время вы часто создаете конкретный сервис одной командой, следуя DDD. Сервис предоставляет бизнес-возможности определенного ограниченного контекста, например, платежные сервисы, которые могут использоваться приложением iOS или серверной частью).

https://learn.particular.net/courses/take/DDDEU-explorers-offer/lessons/9737385-services-modelling-workflows-boundaries-and-business-capabilities

person Daniel Schwarz    schedule 19.05.2021