Message Broker

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Integration Patterns

Contents

Aliases

Context

Problem

Forces

Solution

Example

Resulting Context

Testing Considerations

Security Considerations

Operational Considerations

Known Uses

Variants

Related Patterns

Acknowledgments

Aliases

Hub and Spoke

Context

You have an online store that integrates several systems, such as the Web-based front-end system, the credit card verification system, the retail system, and the shipping system. The control flow usually originates in the front end. For example, a customer placing an order causes the online store to send a request message to the credit card verification system. If the credit card information is validated, the online store sends request messages to the various retail systems, depending on the ordered items. An order for books translates into a purchase order message for the book retailer; an order for electronics translates into a purchase order message for the electronics retailer; and an order for gardening supplies translates into a purchase order message for the home and garden supplier.

The control flow could also originate in a retail or shipping system. For example, when a retailer updates a catalog, the retail system sends catalog update messages to the store so that the store can display the new items. When a shipper changes the shipping rates, the shipping system sends a rate update message to the store so that the store can compute the correct shipping charges. Similarly, when a shipper changes pickup times, the shipping system sends update messages to all the retailers the system serves so that they can have the shipments ready in time.

Problem

How do you integrate applications without enforcing a common interface and also allow each application to initiate interactions with several other applications?

Forces

To integrate applications without changing their interfaces, you must balance the following forces:

• Point-to-point integration requires a large number of connections between applications. Many connections usually translate into many interfaces.
• Message Bus integration facilitates adding new applications, but it requires a common bus interface. Because integration solutions usually involve applications that have proprietary interfaces provided by multiple vendors, Message Bus integration is difficult.
• Run-time control of qualities such as availability and performance may require dynamic reconfiguration.
• The applications in an integration solution could have conflicting quality of service (QoS) requirements.
• The applications in an integration solution could belong to different security realms.

Solution

Extend the integration solution by using Message Broker. A message broker is a physical component that handles the communication between applications. Instead of communicating with each other, applications communicate only with the message broker. An application sends a message to the message broker, providing the logical name of the receivers. The message broker looks up applications registered under the logical name and then passes the message to them.

Communication between applications involves only the sender, the message broker, and the designated receivers. The message broker does not send the message to any other applications. From a control-flow perspective, the configuration is symmetric because the message broker does not restrict the applications that can initiate calls. Figure 1 illustrates this configuration.

Figure 1. A message broker mediating the collaboration between participating applications

The message broker can expose different interfaces to the collaborating applications, and it can translate messages between these interfaces. In other words, the message broker does not enforce a common interface on the applications.

Prior to using a message broker, you must register the applications that receive communications so that the message broker can dispatch requests to them. The message broker may provide its own registration mechanism, or it may rely on an external service such as a directory.

Placing the message broker between the sender and the receiver provides flexibility in several ways. First, the message broker allows the integration solution to dynamically change its configuration. For example, if an application must be shut down for maintenance, the message broker could start routing requests to a failover application. Likewise, if the receiver cannot keep up with the incoming messages, the message broker could start load balancing between several receivers.

Second, the message broker can choose between applications that have different QoS levels. This resembles the dynamic configuration, but the message broker selects the application based on specified criteria. For example, an application for premium accounts may fulfill requests quickly, but an application for general use may have a longer processing time.

Third, the message broker allows the sender and the receiver to reside in different security realms. In other words, the message broker can reside on the boundary between two security realms and bridge requests between those two realms. Table 1 shows the responsibilities and collaborations of a message broker.

Table 1: Message Broker Responsibilities and Collaborations

Responsibilities	Collaborations
–Receive message	–Senders: applications that send messages to the message broker.
–Determine the message recipients and perform the routing	–Receivers: applications that receive messages from the message broker
–Handle any interface-level differences
–Send the message to the recipients

Example

Consider an online store that allows shoppers to browse a variety of retail catalogs and to place orders. When an order is placed, the online store groups the shopping cart items by retailer and places appropriate orders with each retailer. As each retailer fulfills and ships the order, it sends the online store a tracking number. The online store updates its records so that this information is presented on the Check Order Status page. If the customer has configured e-mail alerts, the store also sends an e-mail message that contains the tracking information.

The online store that is illustrated in Figure 2 uses a message broker to communicate with the individual retailers. The broker knows how to reach each retailer and how to place orders, to cancel orders, and to check the order status. Likewise, the retailers communicate with the broker when they send tracking numbers. Each retailer must know how to reach the broker and how to send the tracking number. In other words, both the store side and the retailer side can initiate a communication, and the data flows in both directions.

Figure 2. Online store communicating with retailers through a message broker

Resulting Context

The decision to use a message broker for integration entails balancing the benefits of removing inter-application coupling against the effort associated with using the message broker. Use the following benefits and liabilities to evaluate the balance:

Benefits

• Reduced coupling. The message broker decouples the senders and the receivers. Senders communicate only with the message broker, and the potential grouping of many receivers under a logical name is transparent to them.
• Improved integrability. The applications that communicate with the message broker do not need to have the same interface. Unlike integration through a bus, the message broker can handle interface-level differences. In addition, the message broker can also act as a bridge between applications that are from different security realms and that have different QoS levels.
• Improved modifiability. The message broker shields the components of the integration solution from changes in individual applications. It also enables the integration solution to change its configuration dynamically.
• Improved security. Communication between applications involves only the sender, the broker, and the receivers. Other applications do not receive the messages that these three exchange. Unlike bus-based integration, applications communicate directly in a manner that protects the information without the use of encryption.
• Improved testability. The message broker provides a single point for mocking. Mocking facilitates the testing of individual applications as well as of the interaction between them.

Liabilities

• Increased complexity. Communicating through a message broker is more complex than direct communication for the following reasons:
  • The message broker must communicate with all the parties involved. This could mean providing many interfaces and supporting many protocols.
  • The message broker is likely to be multithreaded, which makes it hard to trace problems.
• Increased maintenance effort. Broker-based integration requires that the integration solution register the applications with the broker. Bus-based integration does not have this requirement.
• Reduced availability. A single component that mediates communication between applications is a single point of failure. A secondary message broker could solve this problem. However, a secondary message broker adds the issues that are associated with synchronizing the states between the primary message broker and the secondary message broker.
• Reduced performance. The message broker adds an intermediate hop and incurs overhead. This overhead may eliminate a message broker as a feasible option for solutions where fast message exchange is critical.

Testing Considerations

A mock message broker can receive requests and send back canned responses. In effect, the mock message broker allows system testers to verify individual applications without removing the individual applications from the integration solution.

Likewise, a mock message broker that emulates some of the message broker's functionality allows testers to verify and to profile the interplay between a few applications, for example, a subset of the integration solution. In other words, a mock message broker allows you to test individual applications and to test subsystems.

Figure 3 shows these configurations; the shading indicates the areas under test.

Figure 3. Using a mock message broker to test applications and subsystems

Security Considerations

Integration by using a message broker places a component between senders and receivers. On one hand, this configuration accommodates management of the security context through consolidation as well as impersonation. On the other hand, the message broker represents a central point of attack. Compromising the message broker compromises the communication between all the applications that use it.

Operational Considerations

The message broker can dynamically change the configuration. It can direct messages to a failover application if necessary or perform load balancing between applications, or the message broker can do both.

Known Uses

Broker-based integration products such as Microsoft BizTalk Server 2004 extend the traditional broker functionality with additional features. For example, BizTalk Server 2004 provides orchestration services, messaging services, and other features associated with these services such as business activity monitoring, transaction and exception handling, correlation, and graphic editing.

Variants

A message broker variant trades ease of integration for performance. The performance-optimized message broker looks up the receiver and then connects it to the sender, thus allowing the sender and the receiver to communicate directly. The direct connection eliminates the performance penalty that is associated with an intermediary between the communicating parties. However, this performance optimization only works if the sender and the receiver have the same interface.

Related Patterns

For more information, see the following related patterns:

• Broker [Buschmann96]. In a distributed setting, the Broker pattern tries to make distribution transparent. Client-side and server-side proxies mediate between the broker and the clients and server.
• Implementing Message Broker with Biztalk Server 2004. This pattern uses the Global Bank scenario to show how you can use BizTalk Server 2004 to implement Message Broker.
• Client-Dispatcher-Server [Buschmann96]. The Client-Dispatcher-Server pattern is a Broker variant that uses the direct communication optimization mentioned earlier in "Variants."
• Content-Based Router [Hohpe04]. The Content-Based Router pattern is a Broker variant that specializes in routing communications to different applications based on the content of the communication.
• Mediator [Gamma95]. The Mediator pattern separates objects so that they are only aware of the mediator but not each other. The Broker deals with similar concerns, but it can only be used in the context of enterprise applications.

Acknowledgments

[Buschmann96] Buschmann, Frank; Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. John Wiley & Sons Ltd, 1996.

[Gamma95] Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.

[Hohpe04] Hohpe, Gregor, and Bobby Woolf. Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions. Addison-Wesley, 2004.

[Trowbridge03] Trowbridge, David; Dave Mancini, Dave Quick, Gregor Hohpe, James Newkirk, and David Lavigne. Enterprise Solution Patterns Using Microsoft .NET. Microsoft Press, 2003. Also available on the MSDN Architecture Center at: https://msdn.microsoft.com/en-us/library/ms998469.aspx.

Start | Previous | Next

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.