Messaging and MOM

Even though computing technologies have evolved from dumb-terminal-based computing systems with small green screens to complex distributed enterprise systems, the most elementary purpose of these applications remains the same—to enable the exchange of data between different pieces of computing software. Message-oriented middleware (MOM) is typically a piece of software that sits between communicating parties and provides the infrastructure responsible for handling disparate dependencies between them, such as operating systems, hardware, and communication protocols. It enables participants involved in the data exchange to focus on the application domain rather than on the mechanics of how the communication takes place.

A MOM exposes its facilities using an API that defines how distributed applications should use the underlying MOM to communicate with each other. MOM can be thought of as the postal service of messaging technology. People write a letter (the message), include the from/to address details on the envelope (the headers), and drop it in the mailbox, which acts as the standard interface for the post office (the API). The postal service (MOM) takes care of picking up the message, sorting the address details, and transporting it to the mailbox of the addressee (the receiver). The mail (message) is passed between parties (applications) via the postal service (MOM) in a manner that does not block the sender of that message from doing other work—that is, the sender can allow the postal service (MOM) to ensure that the message arrives without waiting for a response from the receiver (Figure 11.1).

Figure 11.1: MOM

In general, messaging refers to the act of sending metadata or information about the message and the message content itself, using one or more MOMs, between applications typically located on the periphery of the enterprise. These MOM-based messaging solutions can be architected in three broad topologies:

• Centralized MOM topology. A MOM may be deployed in a centralized hub-and-spoke topology, shown in Figure 11.2, where the MOM acts as a message bus between application components. The bus component was introduced in Chapter 2. In this approach, the components communicate with a central MOM (typically a vendor's MOM server) that behaves like a hub and is responsible for routing messages to the recipients. It also provides other features, such as persistence to ensure reliability and clustering for availability.

  
  Figure 11.2: Centralized MOM topology

The advantages of such a topology are numerous and allow messaging parties to be added and removed on the fly, without breaking other communication paths or affecting other parties. The disadvantages include increased network overhead, the single point of failure, performance of the hub (it has to do extra work in acting like the post office to sort mail), and possibly increased latency.

• Decentralized MOM topology. The decentralized topology shown in Figure 11.3 breaks up the hub-spoke layout to an application-centric approach. Each communicating party typically has its local MOM that acts as a sort of messaging proxy, receiving messages as though it were the intended recipient and then dispatching them to the respective applications.

  
  Figure 11.3: Decentralized MOM topology

The advantages of a decentralized approach are that the MOM functionality, such as security, transactions, and persistence, is distributed between servers. The disadvantage is that parties are a little more tightly coupled. In the centralized topology, since only a single MOM and its API are used, issues of interoperability are limited. In the decentralized approach, if the parties use different vendor MOMs or even different versions of the same MOM, numerous interoperability issues could arise.

• Hybrid topology. The third topology shown in Figure 11.4 offers a hybrid of the centralized and decentralized scenarios. It uses a central MOM that acts as a router between communication parties that use their own local MOMs. A hybrid architecture brings together the best and worst of both topologies. It is flexible yet most complex in terms of use, deployment, and maintenance.

  
  Figure 11.4: Hybrid MOM topology

In all the topologies discussed above, MOMs play a significant role by

• Not requiring the sender and receiver to be simultaneously connected

• Ensuring strong delivery guarantees on the request and response between participants

• Adding functionality in some cases by translating and formatting messages en route between participants

MOM-based messaging solutions are typically a good fit for five broad application categories:

• Applications requiring asynchronous communication. Synchronous or connection-based applications typically send requests at a known instance of a receiver and block until that request is processed. This results in directly shared state information between the two applications for the duration of the call—that is, the receiver uses the input data for processing, and the message sender must know the outcome of that processing to continue its own processing. This approach is not always practical. For example, applications that require guaranteed delivery cannot wait for the receiver to be online, or the recipient may not always be known in advance (especially with multiple recipients). MOMs, with their inherent proxying capabilities, offer a good solution for applications that require asynchronous behavior.

• Store-and-forward applications. In these applications, one or more of the eventual message receivers is not expected to be available. For example, some data processing applications run only after normal business hours, because of their intense consumption of computing resources, but they must receive the data they process from applications that run only during business hours. MOM-based messaging facilities ensure that messages will be delivered as soon as connectivity is restored or applications become available to begin their processing.

• Applications that require a higher level of reliability. Often termed guarded communication applications, these are also a good candidate. In this variation of store-and-forward applications, the messaging participants do not rely on the availability of connectivity to participating applications and are precognizant of the intermittent network. Because MOM acts as a proxy for the eventual receiver, it ensures that messages are protected against communication losses by delivering them reliably.

• Application with multiple recipients. Applications requiring delivery of the same initial message to multiple recipients are best implemented using a MOM-based solution. This is often known as the publish-subscribe messaging design. MOM takes the responsibility of asynchronously delivering messages to multiple receivers and also offers the capability of receiving their responses on behalf of the message initiator.

• Applications requiring message trails. Most MOM implementations offer the ability to maintain detailed message trails. Applications that require the ability to create records of all communications activity for logging, auditing, error recovery, and other quality of service measures can use these services.