[Bernstein09] Section 4.7. Other Message-Oriented Middleware

4.7. Other Message-Oriented Middleware
ManyTP systems are used in conjunction with other TP systems that offerrelated application functionality. We saw a simple example of this inSection 2.4,which described the integration of TP applications that supportchecking accounts and credit card accounts. To be used together, thesystems need to be integrated.
Integrationis hard because independent TP applications are usually heterogeneousin three ways. They support different communications protocols,different application functions, and different message formats. Tointegrate the applications, all three of these differences must bereconciled.
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 toperform the integration. Bus-based products, sometimes calledenterprise service buses (ESBs), enable clients to communicate directlywith servers. However, the technical distinction between EAI and ESBproducts is not always this sharp. For example, both product categoriesare moving toward incorporating business process managementcapabilities, which will be discussed in the next chapter. As we notedinChapter 1,the terminology for transactional middleware product categories hasbeen evolving over the past 15 years, an evolution that seems likely tocontinue.
Broker-Based Architecture
In a broker-based architecture a message server provides a bridge between the heterogeneous applications (seeFigure 4.10).Instead of communicating directly with the applications, a clientcommunicates with the broker, which forwards the message to the desiredapplication. The client can be one of the applications being integratedor 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.

Thebroker provides three functions, which correspond to the threedifferences to be reconciled. First, it supports all the communicationprotocols required to communicate with the applications. A client sendsa message tothe broker using any of the supported protocols. The broker can forwardthat message to the desired application using the protocol supported bythat application.
Second,the broker supports the union of all the functions offered by theapplications being integrated. Usually, the broker offers a uniforminterface to these functions, such as a canonical message formatdefined by the broker. Thus, a client can call these functions usingthat uniform interface, independent of the message protocol,programming language, or other technologies used by the applicationthat implements the function. Internally the broker stores a mappingthat tells it how to translate each function into the form required bythe application that implements the function. This mapping often isimplemented as a set of protocol adaptors, one for each of theapplication environments being integrated. Some brokers can alsosupport clients that use their own protocols and formats and don’tenforce the use of a single uniform interface
Third,it offers tools for translating between different parameter and messageformats. The translation may be based on a calculation (such astranslating between date formats), a table (such as translating betweencountry codes), or a lookup from an external source (such as anexchange 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 isused, such as an XSLT program that translates one XML document intoanother XML document having a different format.
Somebrokers also offer routing functions. A message may be routed based onthe contents of a request or by requirements that are set by the clientor the server. Other broker functions include logging, auditing,performance monitors, and other system management functions.
Bus-Based Architecture
Ina bus-based architecture all TP applications are invoked using the samecommunications protocol, which is configurable for some products (suchas Microsoft’s WCF and Progress Software’s Artix). For example, theymay all support the Web Service protocols. If a TP system does notsupport the common protocol, then it needs to have a protocoltranslator that translates from the bus’s common protocol to thesystem-specific technology for calling the TP system’s applications(seeFigure 4.11).
Sinceall TP systems can be invoked using the same protocol, the TPapplication interfaces are naturally exposed using the same interfacedefinition technology, namely, the one supported by the protocol. Forexample, if Web Services are used, then interfaces are defined usingWSDL 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.

Sincethere is no broker between the client and the TP system it calls, theclient is usually responsible for translating between formats forparameters and messages. This can be done using a shared library oftranslation functions that can be bound into the client’s applications.Or it can be implemented as a service that the client invokes totranslate parameters before invoking the target application.
Comparing Brokers and Buses
Themain difference between broker-based and bus-based architectures iswhether messages from client to TP system pass through an intermediatemessage server. If so, then it’s a broker-based architecture, in whichcase the protocol translation usually takes place in the messageserver. If not, then it’s a bus-based architecture, in which case theprotocol translation usually takes place in the TP systems running theapplications to be integrated. However, this distinction gets muddywhen a bus-based architecture offers a queuing subsystem. It’s in theeye of the beholder to regard the queue subsystem as another server onthe bus or as a broker that mediates accesses between the client andthe TP system.
Thebroker-based and bus-based approaches are even more similar in theirapproaches to the uniform definition of application functions andparameter format translation. Both architectures require a directoryservice to expose the interface definitions of the TP applicationsbeing integrated. For parameter translation, the main difference seemsto be in choosing where the functionality is implemented: in theclient, in a broker or translation service, or in the TP system.