Message Oriented Middleware

Modern systems operate in complex environments with multiple programming languages, operating systems, hardware platforms. Moreover, the requirement for dynamic flexible deployments with 24/7 reliability, security and high throughput performance while maintaining a high Quality-of-Service (QoS) has increased exponentially. In these environments, the traditional direct "Remote Procedure Call" (RPC) approach will fail to cope with the current demands of software systems and an alternative to the RPC called Message-Oriented Middleware or MOM has emerged.

MOM provides a clean method of communication between disparate software applications and emerged as a approach that distributed enterprise systems are built. In simpler terms, it can be defined as Middleware infrastructure that provides messaging capabilities across different software applications. The client of MOM system can send  and receive messages from other clients of the messaging system. Each client connects to one or more servers that act as an intermediary while sending and receiving messages. The MOM platforms allows enterprises to build cohesive systems  (A cohesive system allows changes in one part of a system to occur without the need for changes in other parts of the system)

Message-Oriented Middleware - Advantages

Asynchronous Messaging. Message-oriented middleware comprises a category of inter-application communication software that usually relies on asynchronous message-passing, as opposed to a request-response architecture. In case of asynchronous systems, message queues provide temporary storage when the destination program is busy or unable to get connected. Apart from this, most asynchronous MOM systems provide persistent storage to back up the message queue which means sender and receiver does not necessarily connect to the network at the same time (asynchronous delivery), and problems with irregular connectivity are also solved. If the receiver application fails for any reason, the senders can continue uninterrupted, as messages which are sent will automatically accumulate in the message queue for processing when the receiver restarts.

Routing. Many message-oriented middleware implementations depend on a message queue system. Most implementations have routing logic provided by the messaging layer itself, while very few depend on client applications to provide routing information or allow both paradigms. Some implementations make use of broadcast or multicast distribution paradigms.

Transformation. In a message-based middleware system, the message received at the destination need not be identical to the message originally sent. A MOM system with built-in intelligence can transform messages en route to match the requirements of the sender or of the recipient. In conjunction with the routing and broadcast/multicast facilities, one application can send a message in its own native format, and two or more other applications may each receive a copy of the message in their own native format. Many modern MOM systems provide sophisticated message transformation (or mapping) tools which allow programmers to specify transformation rules applicable to a simple GUI drag-and-drop operation.

Message-Oriented Middleware - Disadvantages

The primary disadvantage of many message-oriented middleware systems is that they require an extra component in the architecture, the message transfer agent (message broker). As with any system, adding another component can lead to reductions in performance and make the system as a whole more difficult and expensive to maintain.  When introduced due to lack of standards governing the use of message-oriented middleware has caused problems. Most of the major vendors have their own implementations, each with its own application programming interface (API) and management tools.

MOM - Implementation. The message queue is a fundamental concept within MOM. Queues provide the ability to store messages on a MOM platform. MOM clients are able to send and receive messages to and from a queue. Queues are central to the implementation of the asynchronous interaction model within MOM. Usually the messages contained within a Queue is sorted in a particular order. The standard queue found in a messaging system is the First-In First-Out (FIFO) queue; as the name suggests, the first message sent to the queue is the first message to be retrieved from the queue. Many attributes of a queue can be configured. These include the queue’s name, queue’s size, the save threshold of the queue, message-sorting algorithm etc. Typically each application may have its own queue, or applications may share a queue, there is no restriction on the set-up. MOM platforms support multiple queue types for different purposes.

MOM - Messaging Models. A solid understanding of the available messaging models within MOM is key to appreciate the unique capabilities it provides. Two main message models that are commonly available, the point-to-point and publish/subscribe models. Both of these models are based on the exchange of messages through a channel (queue). A typical system will utilize a mix of these models to achieve different messaging objectives.

Point-to-Point Model. The point-to-point messaging model provides a straightforward asynchronous exchange of messages between software entities. In this model, messages from producing clients are routed to consuming clients via a queue. As discussed earlier, the most common queue used is a FIFO queue, in which messages are sorted in the order. While there is no restriction on the number of clients who can publish to a queue, there is usually only a single consuming client, although this is not a strict requirement. The model allows multiple receivers to connect to the queue, but only one of the receivers will consume the message. The techniques of using multiple consuming clients to read from a queue can be used to easily introduce smooth, efficient load balancing into a system. In the point-to-point model, messages are always delivered and will be stored in the queue until a consumer is ready to retrieve them.

Publish/Subscribe Model. The publish/subscribe messaging model, is a mechanism used to disseminate information between anonymous message consumers and producers. These one-to-many and many-to-many distribution mechanisms allow a single producer to send a message to one user or potentially hundreds of thousands of consumers. In the publish/subscribe (pub/sub) model, the sending and receiving application is free from the need to understand anything about the target application. It only needs to send the information to a destination within the publish/subscribe engine. The engine will then send it to the consumer. Clients producing messages “publish” to a specific topic or channel, these channels are then “subscribed” to by clients wishing to consume messages. The service routes the messages to consumers on the basis of the topics to which they have subscribed as being interested in. Within the publish/subscribe model, there is no restriction on the role of a client; a client may be both a producer and consumer of a topic/channel.

MOM - Summary. MOM solves a number of the inadequacies inherent in the RPC mechanism. When constructing large-scale systems, it is vital to utilize a state-of-the-art enterprise level MOM implementation. Enterprise-level messaging platforms will usually come with a number of built-in services for transactional messaging, reliable message delivery, load balancing, and clustering. If the distributed systems are geographically dispersed deployments with poor network connectivity and stringent demands in reliability, flexibility, and scalability, then MOM is the ideal solution. MOM-based systems are proficient in coping with traffic bursts while offering a flexible and robust solution for disperse deployments. Remote systems do not need to be available for the calling program to send a message. Loose coupling exists between the consumers and producers, allowing flexible systems to grow and change on demand. MOM also provides an abstract interface for communications. When MOM is used in conjunction with XML messages and web services, we are able to create highly flexible service oriented architectures. This form of architecture allows for the flexible integration of multiple systems.

If you would like to find out more about how MuleSoft could help you make the most out of your current infrastructure while enabling you to open your digital horizons, do give us a call at +44 (0)203 475 7980 or email us at Salesforce@coforge.com

Other useful links

Anypoint Microsoft Azure Connector Developed by Coforge

The Anypoint Asana Connector developed by Coforge

The Anypoint Expedia Connector Developed by Coforge