MESSAGE-ORIENTED MIDDLEWARE (MOM)
MOM is а connectivity software that consists of a set of services that allow multiple applications running on one or more machines to interact across a network. Message queuing applications use asynchronous processing to send and receive messages. They read and operate on the messages independently.
In its simplest form, a message sent from an application to another application will look like something like this:
There are many implementations of this functionality, some are Open Source and some are proprietary. A few examples are IBM MQSeries, Apache ActiveMQ, RabbitM, Kafka, etc.
In this article, we will go into more detail about IBM MQ since it is the most widely adopted implementation in the Enterprise.
IBM MQ allows application programs to use message queuing to participate in message-driven processing. Application programs can communicate across different platforms by using the appropriate message queuing software products.
IBM MQ products implement a common application programming interface known as the message queue interface (or MQI) wherever the applications run. This makes it easier for you to port application programs from one platform to another.
The main component of IBM MQ is the queue manager. The queue manager is a system program that provides a logical container for the message queuing services and owns and manages the set of resources that are used by IBM MQ. These resources include queues, channels, process definitions, and so on.
A simple configuration of two MQ Queue Managers would look like this:
At its simplest, a message queue is an area of storage set aside by the queue manager to hold messages on their way from one program to another. By default, it works like a physical queue: first in, first out [FIFO]. There are several different types of queues:
• Local Queue Object – identifies a local queue belonging to the queue manager to which the application is connected. A local queue is the only place where messages are physically stored.
• Remote queue object – identifies a queue belonging to another queue manager that is a different queue manager from the one to which the application is connected. When an application opens a remote queue, the queue manager to which the application is connected ensures that messages are tagged and stored locally in preparation for sending to another queue manager.
• Alias queue object – is not a queue, but an object pointer to a local or remote queue.
• Model queue object – defines a set of queue attributes that is used as a template to create a dynamic queue. Channels are objects that provide a communication path from one queue manager to another. Channels are used in distributed queuing to move messages from one queue manager to another. There are two categories of the channel in IBM MQ:
• Message channels – are one-way links that connect two queue managers via message channel agents.
• MQI channels – connect a WebSphere MQ client to a queue manager on a server machine, and are established when you issue an MQCONN or MQCONNX call.
An MQ channel is a two-way link used to transfer only MQI calls and responses. There are two-channel types for MQI channel definitions:
• Client-connection channel – connects to the IBM MQ client.• Server-connection channel – connects to the server running the queue manager An IBM MQ message consists of two parts:
- Message header – message control information that contains a fixed-sized portion and a variable-sized portion.
- Message body – application data that contains any type of data (text or binary).
IBM MQ message types include:
- Datagram – no reply is expected.
- Request – a reply is expected.
- Reply – reply to a request message.
- Report – contains status information from the queue manager or another application.