In the process of evaluating and trialling the introduction of messaging to integrate distributed back-end services, and other apps, in our system, the question of whether we were aiming to design a Message Broker or a Message Bus arose. This led to me doing some research to verify and improve my understanding of the difference. This post is a summary of my findings.

Messaging Topologies

Firstly, let’s be clear, the terms Message Broker and Message Bus are used in architectural patterns for messaging systems, also referred to as messaging topologies.

Whilst a Message Bus is one such topology, a Message Broker is only one component in an alternative topology known as Hub and Spoke.

These topologies describe different ways for integrating apps using messaging.

Hub and Spoke

In the Hub and Spoke topology, applications are integrated via a central messaging middleware component. Apps send and receive messages to and from the ‘hub’ only. Senders have no awareness of other apps, or their specific concerns. The hub actively mediates, or ‘brokers’, all communications between applications, to provide additional integration and messaging services. The hub is therefore commonly referred to as a Message Broker.

Ref [1]

Each app is connected to the hub via a ‘spoke’. These are application-specific protocol and API messaging adapters that are logically part of the hub, rather than the apps. (The spokes are implemented and deployed as extensions of the hub rather than apps).

The hub aims to fully decouple apps from one another, such that a sending application has no awareness of either the number or destination / location of consuming apps.

Message Bus

A Message Bus is an architectural pattern that supports integrating apps using a shared (common) set of interfaces. It consists of the following key elements:

• A shared infrastructure (network and messaging channels) for sending messages to recipients.
• A set of agreed-upon message schemas (message headers, and a common data-model in terms of resources and representations used in message payloads).
• A set of common command messages. (Used to support the messaging equivalent of RPC to invoke methods in other apps).

When an app wants to send a message it passes it to the message bus, which is responsible for delivering the message to all the other apps listening for messages on the bus’ shared infrastructure.

Ref [2]

It’s the apps that are responsible for implementing the common bus Interface. An app that sends messages through the bus must prepare the message so it complies with the type of messages the rest of the apps connected to the bus expect. Similarly, an application that receives messages must be able to understand (syntactically, although not necessarily semantically) the message types.

Similarities and Differences

Diagrams like those above visually distinguish the two topologies. Whilst helpful, they can lead to overlooking the fact that messaging systems that are based on both topologies have common features. Whilst both topologies have different strengths (benefits) and weaknesses (liabilities), the primary benefit of both topologies over a point-to-point (direct) integration style is that they reduce the number of integrations that need to be built to fully integrate all the apps in a system – avoiding “integration spaghetti”.

Adopting a Message Bus topology implies applications are integrated using a common protocol and they produce and consume messages that adhere to a common, shared schema, including a data-model (set of resources and their representations). A Message Bus provides little or no centralised messaging services. Sent messages might only be delivered (broadcast) to all connected systems. Although pub-sub messaging, another form of message routing, is typically also supported.

A Hub and Spoke architecture integrates apps without enforcing a common API (message schema) on them, and supports connecting them using disparate protocols. It does so by providing application specific (e.g. protocol) adapters, and an active, central messaging middleware component. This hub, or Message Broker, understands the messages sent to it, knows which app(s) the message needs to be sent, and can transform a message to meet the schema expected by each app. Because it brokers messages sent between apps it can also provide additional messaging services such as message (e.g. content) routing, aggregation and splitting.

Because a Hub and Spoke architecture provides protocol conversion and data transformation services it supports integrating apps that can’t be easily changed, such as legacy and third-party apps. A Message Bus based integration does not.

The Message Broker in a Hub and Spoke architecture contains more logic and maintains more state than a Message Bus. It may therefore be more difficult to scale.

Summary and Conclusions

A Message Broker is one part of the Hub and Spoke messaging architecture (topology), as distinct from the Message Bus topology.

These two topologies are both alternatives to point-to-point (direct) integrations, and primarily aim to reduce the number of integrations that need to be built to fully integrate all the apps in a system – avoiding so-called “integration spaghetti”.

Both topologies have their strengths and weaknesses. One of the main decision points for choosing between them is whether your centralised messaging infrastructure needs to support integrating apps with disparate protocols and / or message schemas, e.g. because the apps can’t be changed to support a common messaging interface.

In practice, messaging middleware will vary in the extent of Message Broker features they support, over and above the more basic features seen in a Message Bus.

Further Reading

The following articles were the primary sources used to research this blog post. They contain much more information, especially around the benefits and limitations of each topology.

[1] MSDN Library patterns & practices > Services Development Integration Patterns – June 2004 Integration Topologies > Message Broker

[2] MSDN Library patterns & practices > Services Development Integration Patterns – June 2004 Integration Topologies > Message Bus

[3] Hub and Spoke or “Zen and the Art of Message Broker Maintenance” , Gregor Hohpe, 11/2003