Section 11.1. What Is a Message Broker?

11.1. What Is a Message Broker?

A Message Broker is a centralized hub that simplifies communication among heterogeneous systems. A Message Broker is not a technological breakthrough, but a sensible solution to a common problem: a dramatic increase in number of point-to-point connections between applications in the enterprise.

If there are N applications, and every application links to every other application, the total number of point-to-point connections required is N * (N - 1)/2. If applications instead connect through a central Message Broker, this number is reduced to just N, as in Figure 11-1, where a tangled web of 36 connections is replaced with a tidy 9.

Figure 11-1. Point-to-point connections versus connections through a Message Broker

The argument is a straw man because no company ever requires anywhere near the mathematical maximum number of links. Worse than the quantity of connections is the quality: each connection potentially has its own transport mechanism and message format, and in many cases is poorly documented, hard to integrate, or hard to maintain. Some systems are new, some are legacy, some speak XML, some fixed-position text, and some obscure binary.

A Message Broker's solution is, first, to be a central integration point with a well-documented and clearly understood interface. New applications requiring enterprise integration simply plug into this open architecture. A good broker supports a variety of transports, such as MQ/Series, web services, FTP, and others, though many companies prefer to standardize on just one. As for message format, many Message Broker implementations mandate the use of a canonical format ,^[*] which abstracts many common types of entities referred to in interapplication communication.

^[*] A canonical format is a common format for exchanging information, and can apply across an industry (for example, the OAGIS standard from the Open Applications Group) or an enterprise.

Though canonical format can apply across an industry (and especially in B2B entities), achieving the required abstraction even within a single company is a challenge. In company X, for example, some divisions identify a customer by social security number (SSN), whereas others use a proprietary 11-digit format. The canonical XML form of customer for company X supports both, as well as common forms of name, addresses, and phones:

     <Customer>        <Name/>        <Addresses/>        <Phones/>        <SSN/>        <OurWeird11DigitID/>     </Customer>

In addition to its open interface, a Message Broker helps existing applications participate by providing adapter-based integration. If system Y's inbound interface is binary over named pipe, for example, but the Message Broker expects it to offer a web service that accepts canonical XML, then system Y requires an adapter that exposes itself as a web service that accepts canonical XML, but internally transforms the XML to binary and sends the binary on the named pipe. Message Broker interfaces with the adapter as it would with any other participant, unaware of the internal adaptation.

NOTE

An adapter is a component that helps plug an external system (e.g., SAP, Siebel, or a mainframe application) into a particular infrastructure. An adapter always has two parts: the part that knows how to converse with the external system and the part that fits into the infrastructure. In a BPM message broker, that infrastructure is web services; the adapter delivers messages from the external system to the process by calling the process's web service; the process calls the adapter's service to deliver messages to the system.

11.1.1. BPM and Message Broker

Having N systems connect to a central broker over common transports and with canonical messaging is worthless unless the central broker performs useful work. The precise work required by the broker is company-specific, but it generally involves listening for inbound messages, sending outbound messages, and performing rule-based logic in between.

BPM is the perfect candidate for implementing this functionality. As Figure 11-2 illustrates, the flow logic of a BPM process can be coded to listen for inbound canonical messages from one application, and to send a canonical message (after some decision making) to an application through its adapter, and to then wait for its response.

Although BPM is a good fit here, several considerations are worth noting:

• Processes used in the broker are for enterprise infrastructure, and are not intended to serve the needs of a particular line of business. They are for routing across lines of business, and thus are not business processes per se.

  Figure 11-2. Message Broker architecture

  
  
  

• Routing is not a single, universal process, but, for a given company, a specific set of processes. Significant custom development is always required. Never buy a message broker product that positions itself as the HAL of the enterprise.

• A broker process is more like a choreography than an orchestration because its purpose is the management of participantseven if they are intraenterprise applications and not external parties, rather than logic of particular scenario.

The final point suggests that choreography standards such as WS-CDL are more suitable broker-process technologies than are pure BPM models such as BPEL. Perhaps, but BPEL also fits, and its immense lead in vendor support makes it the clear winner. A BPEL broker process, as we will discuss later, has a distinctive message communication look: numerous partner links and receive, reply, and invoke activities.

The architecture supporting a BPM message broker should resemble the one presented in Chapter 2: a graphical modeling tool that can export BPEL code to execute on a runtime processor; an adapter-based systems interface; and administration and monitoring capabilities with an extensible data model. The elements used in this chapter's example are a BPMN modeling tool from ITPearls (with no export capability) and a BPEL engine with administration, monitoring, and adapters from Oracle; adapter capabilities are not demonstrated here.