 |
Many patterns in this chapter present ways to route messages to the proper destination without the originating application being aware of the ultimate destination of the message. Most of the patterns focused on specific types of routing logic. However, in aggregate, these patterns solve a bigger problem.
How can you decouple the destination of a message from the sender and maintain central control over the flow of messages?
Use a central Message Broker that can receive messages from multiple destinations, determine the correct destination and route the message to the correct channel. Implement the internals of the Message Broker using the design patterns presented in this chapter.
Using a central Message Broker is sometimes referred to as hub-and-spoke architectural style, which appears to be a descriptive name when looking at the diagram above.
The Message Broker pattern has a slightly different scope than most of the other patterns presented in this chapter. It is an architecture pattern as opposed to individual design patterns we presented in this chapter. As such, it is comparable to the Pipes and Filters architectural style, which gives us a fundamental way of chaining components together to form more complex message flows. Rather than just chaining individual components, the Message Broker concerns itself with larger solutions and helps us deal with the inevitable complexity of managing such a system.
The Message Broker is not a monolithic component. Internally, it uses many of the message routing patterns presented in this chapter. So once you decide to use the Message Broker as an architectural pattern, you can choose the correct Message Router design patterns to implement the Message Broker.
The advantage of central maintenance of a Message Broker can also turn into a disadvantage. Routing all messages through a single Message Broker can turn the Message Broker into a serious bottleneck. A number of techniques can help us alleviate this problem. For example, the Message Broker pattern only tells us to develop a single entity that performs routing. It does not prescribe how many instances of this entity we deploy in the system at deployment time. If the Message Broker design is stateless (i.e. if it is composed only of stateless components), we can easily deploy multiple instances of the broker to improve throughput. The properties of a Point-to-Point Channel ensure that only one instance of the Message Broker consumes any incoming message. Also, as in most real-life situations, the ultimate solution ends up being a combination of a patterns. Likewise, in many complex integration solutions it may make sense to design multiple Message Broker components, each specializing on a specific portion of the solution. This avoids creating the über-Message Broker that is so complex as to become unmaintainable. The apparent flip-side is that we no longer have a single point of maintenance and could create a new form of "Message Broker spaghetti". One excellent architectural style to use a combination of Message Brokers is a Message Broker hierarchy (see picture). This configuration resembles a network configuration composed out of individual subnets. If a message has to travel only between two applications inside a "subnet" the local Message Broker can manage the routing of the message. If the message is destined for another subnet, the local Message Broker can pass the message to the central Message Broker who then determines the ultimate destination. The central Message Broker performs the same functions as a local Message Broker, but instead of decoupling individual applications it decouples whole subsystems consisting of multiple applications.
... Read the entire pattern in the book Enterprise Integration Patterns
Related patterns:
Canonical Data Model, Event-Driven Consumer, Message Channel, Message Endpoint, Message Router, Pipes and Filters, Point-to-Point Channel, Publish-Subscribe Channel, Recipient List
Further reading:
Integration Pattern Language
