[Bernstein09] Section 4.7. Other Message-Oriented Middleware

4.7. Other Message-Oriented Middleware

Many TP systems are used in conjunction with other TP systems that offer related application functionality. We saw a simple example of this in Section 2.4, which described the integration of TP applications that support checking accounts and credit card accounts. To be used together, the systems need to be integrated.

Integration is hard because independent TP applications are usually heterogeneous in three ways. They support different communications protocols, different application functions, and different message formats. To integrate the applications, all three of these differences must be reconciled.

There are two main architectures for performing this reconciliation: broker-based and bus-based. Broker-based products, sometimes called enterprise application integration (EAI) systems, use a broker as intermediary between client and server to perform the integration. Bus-based products, sometimes called enterprise service buses (ESBs), enable clients to communicate directly with servers. However, the technical distinction between EAI and ESB products is not always this sharp. For example, both product categories are moving toward incorporating business process management capabilities, which will be discussed in the next chapter. As we noted in Chapter 1, the terminology for transactional middleware product categories has been evolving over the past 15 years, an evolution that seems likely to continue.

Broker-Based Architecture

In a broker-based architecture a message server provides a bridge between the heterogeneous applications (see Figure 4.10). Instead of communicating directly with the applications, a client communicates with the broker, which forwards the message to the desired application. The client can be one of the applications being integrated or an external program such as an end-user device.

Figure 4.10. Broker-Based Application Integration. The Message Broker mediates message transfer from clients to TP applications.

The broker provides three functions, which correspond to the three differences to be reconciled. First, it supports all the communication protocols required to communicate with the applications. A client sends a message to the broker using any of the supported protocols. The broker can forward that message to the desired application using the protocol supported by that application.

Second, the broker supports the union of all the functions offered by the applications being integrated. Usually, the broker offers a uniform interface to these functions, such as a canonical message format defined by the broker. Thus, a client can call these functions using that uniform interface, independent of the message protocol, programming language, or other technologies used by the application that implements the function. Internally the broker stores a mapping that tells it how to translate each function into the form required by the application that implements the function. This mapping often is implemented as a set of protocol adaptors, one for each of the application environments being integrated. Some brokers can also support clients that use their own protocols and formats and don’t enforce the use of a single uniform interface

Third, it offers tools for translating between different parameter and message formats. The translation may be based on a calculation (such as translating between date formats), a table (such as translating between country codes), or a lookup from an external source (such as an exchange rate server to translate a money field between currencies). Some applications import or export structured documents (e.g., in XML), rather than individual parameters. In this case document translation is used, such as an XSLT program that translates one XML document into another XML document having a different format.

Some brokers also offer routing functions. A message may be routed based on the contents of a request or by requirements that are set by the client or the server. Other broker functions include logging, auditing, performance monitors, and other system management functions.

Bus-Based Architecture

In a bus-based architecture all TP applications are invoked using the same communications protocol, which is configurable for some products (such as Microsoft’s WCF and Progress Software’s Artix). For example, they may all support the Web Service protocols. If a TP system does not support the common protocol, then it needs to have a protocol translator that translates from the bus’s common protocol to the system-specific technology for calling the TP system’s applications (see Figure 4.11).

Since all TP systems can be invoked using the same protocol, the TP application interfaces are naturally exposed using the same interface definition technology, namely, the one supported by the protocol. For example, if Web Services are used, then interfaces are defined using WSDL and are made available to callers using UDDI.

Figure 4.11. Bus-Based Application Integration. The client talks directly to TP applications using a standard wire protocol.

Since there is no broker between the client and the TP system it calls, the client is usually responsible for translating between formats for parameters and messages. This can be done using a shared library of translation functions that can be bound into the client’s applications. Or it can be implemented as a service that the client invokes to translate parameters before invoking the target application.

Comparing Brokers and Buses

The main difference between broker-based and bus-based architectures is whether messages from client to TP system pass through an intermediate message server. If so, then it’s a broker-based architecture, in which case the protocol translation usually takes place in the message server. If not, then it’s a bus-based architecture, in which case the protocol translation usually takes place in the TP systems running the applications to be integrated. However, this distinction gets muddy when a bus-based architecture offers a queuing subsystem. It’s in the eye of the beholder to regard the queue subsystem as another server on the bus or as a broker that mediates accesses between the client and the TP system.

The broker-based and bus-based approaches are even more similar in their approaches to the uniform definition of application functions and parameter format translation. Both architectures require a directory service to expose the interface definitions of the TP applications being integrated. For parameter translation, the main difference seems to be in choosing where the functionality is implemented: in the client, in a broker or translation service, or in the TP system.