57

what's the difference between a message bus[1] and a message broker[2]

  • Both is middleware for applications
  • Both can be used to decouple various systems
  • Both can have a canonical data model
  • Both route messages and could offer other features such as data transform

As i see, the only relevent difference is the picture used to represent each of one..

If there's some difference between then, please tell-me what.
If they are the same, plese tell-me why two concepts to refer the same functionality.

Thanks.

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

Zé Carlos
  • 3,627
  • 5
  • 43
  • 51
  • In the book, they say that a Message Broker is "an architecture patter as opposed to an individual design pattern" (page 324). I think a Message Bus could be one _type_ of Message Broker, ...but not all Message Brokers are Message Buses. I suspect in practice, there's a lot of overlap between the two. But you're right, the distinction isn't as clear as it could be. I've been thinking this over for days, for a presentation. – FrustratedWithFormsDesigner Nov 24 '20 at 17:17

4 Answers4

42

The message bus implies a common protocol spoken and understood by all participants. There is little to no logic in the bus. Usually the message is forwarded to all connected systems.

The hub-and-spoke architecture (or "message broker") has a central piece of software which understands the messages sent to it, can translate them, and forward them to the systems which need the information.

Hendrik Brummermann
  • 8,242
  • 3
  • 31
  • 55
  • 13
    Thanks. According to "Enterprise Integration Patterns" by Gregor Hohpe, a message bus has a router inside. In fact, it can support message exchange patterns such as publish-subscribe, so it is not a simple message repeater. The message bus use a canonical data model but aplications can use adapters, so it is not mandatory all aplications use the same data format. Finally, you say that a message broker is a "central piece of software" but after implemented, you can look at message bus by the same way (all aplications send messages to the same endpoint). – Zé Carlos Jun 30 '10 at 14:06
  • Thanks, very succinct explanation, have an exam in two days, this will help! – mitchellt May 25 '14 at 16:05
9

First recognize that these are made-up terms adopted from existing metaphors, like most domain-specific terms are. Nobody has the authority to define them, rather we are just making this stuff up as we (the industry) goes along.

The broker metaphor works nicely with a hub-and-spoke layout. The bus metaphor works better in a direct addressing situation. What is stopping your client from sending a message to one of a number of brokers sitting on the bus, hub-spoke or otherwise? The definitions of the metaphors starts to get a bit silly.

Figure out what you want to do and choose a product that does it best -- hint: it's probably going to provide features of both so-called bus or broker technologies.

Rick O'Shea
  • 1,410
  • 19
  • 15
2

Nice explanation on mulesoft on the differences between Message Broker and Enterprise Service Bus -

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

Quote from the article: " Enterprise Bus: ...While it (i.e Message Broker) is still used a central routing component to pass messages from system to system, the bus architecture sought to lessen the burden of functionality placed on a single component by distributing some of the integration tasks to other parts of the network.

These components could then be grouped in various configurations via configuration files to handle any integration scenario in the most efficient way possible, and could be hosted anywhere within the infrastructure, or duplicated for scalability across large geographic regions."

MuzammilUK
  • 29
  • 3
  • Welcome to Stack Overflow! Whilst this may theoretically answer the question, [it would be preferable](//meta.stackoverflow.com/q/8259) to include the essential parts of the answer here, and provide the link for reference. – Enamul Hassan Aug 21 '16 at 00:00
  • 2
    Correction: it's an explanation of how Mulesoft distinguishes these terms, for better or worse -- worse actually. – Rick O'Shea Jan 15 '17 at 20:02
1

According to Udi Dahan’s lessons (the guy that invented NServiceBus): “.. the bus architectural style [is] orthogonal to the broker architectural style. Brokers tend to be more aligned with [technical] system boundaries [one system is an iOS mobile app built by one team, another system is the Java backend built by another team, ..]. Services and the bus architectural style are orthogonal/crosscutting to many of how the systems are build”. (Nowadays, you often build a particular service by one team following DDD. A service provides business capabilities of a particular bounded context, e.g., a payment services that could be used by the iOS app or the backend).

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

Daniel Schwarz
  • 31
  • 2