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 apps 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 app domain rather than on the mechanics of how the communication takes place.

A MOM exposes its facilities using an API that defines how distributed apps 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 (apps) 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 ( ScreenShot).

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 apps 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 ScreenShot, where the MOM acts as a message bus between app components. The bus component was introduced in . 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.

  

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 ScreenShot breaks up the hub-spoke layout to an app-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 apps.

  

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 ScreenShot 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.

  

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 app categories:

• apps requiring asynchronous communication. Synchronous or connection-based apps 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 apps 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, apps 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 apps that require asynchronous behavior.

• Store-and-forward apps. In these apps, one or more of the eventual message receivers is not expected to be available. For example, some data processing apps run only after normal business hours, because of their intense consumption of computing resources, but they must receive the data they process from apps that run only during business hours. MOM-based messaging facilities ensure that messages will be delivered as soon as connectivity is restored or apps become available to begin their processing.
• apps that require a higher level of reliability. Often termed guarded communication apps, these are also a good candidate. In this variation of store-and-forward apps, the messaging participants do not rely on the availability of connectivity to participating apps 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.
• app with multiple recipients. apps 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.
• apps requiring message trails. Most MOM implementations offer the ability to maintain detailed message trails. apps 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.