New version!

A new version of this website is available at architectural-patterns.net.

Message Bus a.k.a. Event Bus

If your application requires a number of modules that need to communicate with each other in various ways, this architecture is a sure bet. It is endlessly flexible: you can add and remove modules at run-time, communicate directly or broadcast messages. It is completely free.

Examples

• Process monitoring
• Trading Systems
• Software development environments

When should you use it?

Use it when your application can be factored in functionally separable modules that are capable of communicating through simple messages.

How does it work?

Modules may be added and removed at any time.

When a module wishes to communicate with another module or other modules, it places a message on the Event Bus. The Event Bus takes care of delivering the message to the recipients.

There are several types of communication that may occur on the Event Bus:

• Publish-Subscribe: Modules may subscribe to certain message types. Whenever a module publishes a message to the bus, it will be delivered to all modules that subscribed to its message type.
• Broadcast: The message will be delivered to all (other) modules.
• Point-to-point: The message has one and only one recipient.

The sending module normally doesn't care when the other modules receive and process the message. If the time of processing is important, the message may be sent immediately. It corresponds to calling the function in receiving modules directly, with the difference that the modules are still decoupled.

Problems

• If the modules share large amounts of data, it may not be a good idea to pump these over the bus all the time. If you choose to share the data between the modules, make sure no synchronization issues occur.

Common implementation techniques

• Relates to the Observer Design Pattern, with added functionality.

Links

• MSDN, Patterns and Practices: Message Bus