Message-Oriented Middleware

Message-Oriented Middleware (MOM) acts as an intermediary, and provides a common reliable way for programs to create, send, receive, and read messages in any distributed enterprise system. MOM ensures fast, reliable asynchronous electronic communication; and guaranteed message delivery, receipt notification, and transaction control.

The central MOM notion is the concept of a destination (a queue or a communication topic). Messaging clients send messages to the MOM, which in turn routes these messages to the appropriate receiver. The figure overleaf shows a couple of enterprise application messaging clients sending messages to each other using the services of a MOM provider:

Messaging systems are classified into different models that determine which client receives a message. The most common messaging models are:

• Publish/Subscribe messaging

• Point-to-Point messaging

• Request-Reply messaging

Not all MOM providers support all these models. We will discuss these models in more detail as we get into Messaging Domains in JMS.

Features of MOM

Some of the important features and services provided by MOM are described in the following paragraphs:

• Guaranteed Message Delivery

  Applications sending messages between each other need not even be connected to the network at the same time. MOM guarantees that the messages will be delivered as soon as the network connections are established and the receiving application issues a request for sent messages. You will be able to appreciate this better if you realize that traditional synchronous solutions would require that the two systems be up and accessible to each other at the same time.

• Asynchronous Communication

  Once a client application sends out a message to a receiving application, the MOM allows the client application to handle other tasks without waiting for a response from the receiving application.

• Transaction Support

  MOM supports transactions and is also tightly integrated with transaction services. When transaction services are present, they may participate in a MOM transaction.

• One Time, in-Order Delivery

  MOM can provide guarantees that each message will be delivered once and only once, and that the messages are received in the order in which they are sent

• Message Routing Services

  These services give the client application the ability to send messages to their destination using least-cost routing. The administrator only needs to define the cost of each route, and the MOM will automatically calculate the most economical path for the message. Moreover, this routing is capable of eliminating single points of failure. Hence, the MOM can reroute around network problems. This is very helpful if you are dealing with unreliable networks such as the Internet.

• Notification Services

  Even though the MOM allows messages to be sent asynchronously freeing up the client application, in some instances, the sending application may want to be notified whether the message was received successfully. So, the MOM also allows the sender the option to review responses, let another application handle them or just completely ignore them. The MOM can also journal messages to provide audit trails.

Advantages of MOM

Message-Oriented Middleware software reduces the complexity involved in developing applications that span multiple operating systems and networking protocols. It achieves this by insulating the application developer from the details of the various operating systems and network interfaces. By providing API (such as JMS) implementations that extend transparently across diverse platforms and networks, MOMs increase the flexibility of an architecture and enable applications to exchange messages with other programs without having to know what platform or processor the other application resides on.

Distributed systems based on the messaging paradigm are relatively easy to modify because event dependencies are resolved through runtime event names, rather than by compilers, linkers or operating systems. Clients of messages operate independently of, and asynchronously from, each other and may change without recompilation. All communication between applications is through messages that are routed through the MOM server. This allows new applications to be added to the distributed system later without recompiling, re-linking or even stopping and restarting any current applications. The messaging paradigm greatly reduces complexity in distributed system design and implementation. Events are published to destinations as they happen; business processes that depend on these events automatically receive them as they occur.

The other advantages of using MOMs are:

• Robustness to Change

  Applications on heterogeneous platforms communicate and interoperate transparently yet each application operates independently of, and asynchronously with, others. Communicating programs remain separately maintained and individually replaceable.

• Time Independence

  Neither the message sender nor the message recipient needs to be online at the same time. The MOM queues messages when their recipients are not available.

• Location Independence

  The message sender, and the message recipient can be migrated from computer to computer at runtime, since both senders and receivers are decoupled using destinations (either message queues or communication topics). This enables continuous uninterrupted operation, because software and hardware can be serviced without bringing down the system. Applications can be moved between machines without disrupting other component applications; developers use a logical, consistent naming convention and are completely isolated from low-level details of network programming.

• Latency Hiding

  In traditional synchronous systems, a client is typically suspended while its request is transmitted to the server, and a reply sent back to the client. This makes for hard to design user interfaces, as the application GUI would freeze during a long-running transaction. Making the user-interface responsive in spite of this problem places a heavy demand on the developer. The developer is then forced to work with threads, and potentially has to interrupt pending calling at any time. However, with MOM, the request and reply phases are totally decoupled. Once a request is transmitted, the user-interface can immediately proceed with the next task. This makes for more user-friendly client applications, but still carries a dependency on the developer to cater for the reply phase.

• Scalability

  If you have several clients that generate requests, for example, purchase requests, and one system that processes them, for instance order processing, then you can scale the order processing capacity by adding more machines that look at the same queue. Considering the fact that there is always a limitation on the number of concurrent sockets that a single server machine can keep open, Publish/Subscribe MOM systems scale well in respect to the number of receivers of a particular message.

• Event-driven Systems

  Since events are essentially a form of message, MOMs explicitly support the development of event-driven distributed enterprise applications.

• Simplicity

  MOMs are based on the simple idea of a destination that messages are sent to or received from, which developers can grasp easily and thus quickly become productive.

• Configurable Quality of Service

  With synchronous systems, the Quality of Service is always 100% reliability. Given that, one could easily argue against the need for a different model. However, QoS is a much broader concept than simply reliability, including speed, resilience, latency, and availability. The reality is that sometimes, configurable reliability is preferred, simply because of the cost to speed, resilience, latency, and availability, involved in achieving that 100% reliability.

A MOM-based system can make certain assumptions about the messages it needs to distribute. For example, let us consider that we need to send out a stock quote message to 100,000 clients. As a message carrier, the MOM can decide that since the message is identical for all the 100,000 clients, it will use a more efficient transport protocol than TCP/IP to send the message, like IP Multicast. This means that the message has to be sent only once, irrespective of the number of recipients. In this type of system, let us assume it is adequate if 98% of the clients get the stock quote message. In a synchronous system, to be sure that any client received the message, the system would have to send synchronous messages, in this case, 100,000 of them. This would not only be time-consuming, but also far too expensive for the extra benefit.

However, if MOM clients need reliable and guaranteed delivery I would configure the QoS to be so, such that all my 100,000 clients (100% of them) received the message. Remember, previously we stated that the QoS is configurable. In essence, what we're saying is that MOMs have a choice of QoS as opposed to synchronous systems. It's configurable according to client needs.