9.3 Message-Oriented Middleware

Message-oriented middleware (MOM) is an inherently loosely coupled , asynchronous technology. This means that the sender and the receiver of a message are not closely bound together, unlike synchronous middleware technologies, such as CORBA. Rather, the sender and the receiver stay independent and autonomous. The sender can send a message to a receiver and know that it will be delivered, even if the network link is down or the receiver is not available. MOM technologies also typically support one-to-many and many-to-many communications, using the publish/subscribe paradigm.

Different applications require different degrees of certainty about the delivery of a message. MOM technologies offer a different quality of service (QoS) for the messages they transport. Typically, this includes a fast, best-effort QoS, a slower but more reliable guaranteed QoS, and a transactional QoS that ensures complete delivery or failure of batches of messages, often in conjunction with database updates.

IBM MQSeries is a middleware product that provides distributed-communication services for application programs. (Although other products exist, such as Microsoft Message Queue and TIBCO Rendezvous, we will limit our discussion to MQSeries because it was selected by the corporate architecture team as part of the SRF.) Applications communicate with one another by using a communication model known as message queuing. In message queuing, applications send one another data in messages rather than calling one another directly, as with remote procedure calls (RPCs). Messages are not sent directly to the intended receiver but instead are sent to a message queue, which is a named destination. Messages accumulate on this queue until they are retrieved by the program that is designated to service the queue.

This communication model offers several advantages: providing reliable once-only delivery of messages, allowing applications to communicate in an asynchronous manner with no direct connection between them, and allowing applications to run independent of time. Because the sending and receiving application programs are decoupled, the sender can continue processing after sending a message without waiting for the receiver to acknowledge its receipt. Messages that are sent to target applications are queued independently of the application. Thus, the receiving application does not need to be available when the message is sent. Instead, it can retrieve its messages once it has been started or becomes available.

The basic architecture of MQSeries with application interaction is shown in Figure 9-2. The concepts used in MQSeries messaging are messages, message queues, queue managers, triggers, and the message queue interface (MQI). Each of these concepts is described in turn in the following sections.

Figure 9-2. MQSeries architecture

Messages

As Figure 9-3 shows, MQSeries messages have two parts : a message descriptor and application data. The message descriptor is a header that identifies the message and contains control information understood by the queue manager. The control information includes such items as the type of message, target-queue name , length of user data, message priority, persistence, and reply-to queue name.

Figure 9-3. MQSeries message format

Each message has an attribute that determines whether it is persistent or nonpersistent. Persistent messages are written out to logs and queue data files. If restarted after a failure, a queue manager recovers these persistent messages as necessary from the logged data. Messages that are not persistent are discarded if a queue manager stops for any reason.

Application data can contain any sequence of bytes and is defined by the application. Therefore, this information is not understood by the queue manager but rather is private information between the two communicating applications.

MQSeries defines four types of messages:

1. Datagram: a simple message that does not require a reply

2. Request: a message that requires a reply

3. Reply: a response to a request message

4. Report: a message that describes an event, such as an error

As shown in Figure 9-4, coupling these message types with MQSeries messaging semantics produces three styles of messaging: send-and-forget, request/response, and publish/subscribe. In the send-and-forget message style, the application simply sends the message and assumes that it will be processed correctly. In the request/response style, the sending application waits for a response. In the publish/subscribe style, multiple applications can subscribe to a particular queue. When a message is sent to this queue, all the subscribers are notified.

Figure 9-4. MQSeries messaging styles: (a) send-and-forget, (b) request/response, (c) publish/subscribe

Messages are retrieved from the queue by an application through the queue manager. Applications can control the order in which messages are retrieved from a queue. MQSeries provides the following options for message retrieval:

• Priority. Messages can be retrieved in the order of priority that was assigned to them by the receiving application. Messages of equal priority are stored in a queue in order of arrival, not the order in which they were committed.

• FIFO . First in, first out (FIFO) refers to the order in which the messages were received.

• Identifiers. The application can retrieve the first message that matches a specific identifier.

Queues

A message queue is a data structure that stores messages. Queues reside in and are managed by a queue manager. Messages accumulate in a queue until they are read by the receiving application. Each queue has a unique name for identification and exists independently of the applications that use it. Thus, a queue can serve as a named destination for messages. Queues usually exist in memory but can also be maintained on disk for recovery in the event of a system failure.

Each queue has set of attributes that determine which applications can retrieve messages from the queue, which applications can put messages on the queue, and whether access to the queue is exclusive to one application or shared among applications. Queue attributes can also set the maximum number of messages and the maximum length of messages that can be stored.

MQSeries queues can be either local or remote. A local queue is owned by the queue manager that is connected to the application. Remote queues are not owned by the queue manager that is connected to the application. Applications can put messages in local or remote queues but can get messages only from local queues. Applications send data to remote queues by using a local definition of a remote queue. This object holds the information necessary for the local queue manager to locate the remote queue.

Queue Manager

The queue manager allows applications to put messages in a queue and get messages from a queue. The queue manager can also generate events when special conditions, defined by the application, are satisfied. Queue managers also have an interface that allows administrators to create new queues, alter the properties of existing queues, and control the operation of the queue manager. An application must establish a connection to a queue manager to use its services. Several unrelated applications can use the queue manager at the same time.

As with queues, a queue manager can be local or remote. A queue manager is remote to an application if the application is not connected to that queue manager. Thus, the queue manager connected to an application is the local queue manager for that application.

Communication between the local queue manager and any remote queue managers requires defined message channels. A message channel provides a communication path between two queue managers on the same or different platforms. As shown in Figure 9-5, the message channel transmits messages from one queue manager to another and will transmit data only in one direction. Thus, two message channels are required for two-way communication between two queue managers. Because queue managers also route messages to other queue managers, it is not necessary to define a channel directly to the target queue manager. A queue manger will usually route messages to the appropriate queue manager by simply defining the next hop.

Figure 9-5. Channel communication

Triggers

As stated earlier, the queue manager can generate events to an application when special conditions are satisfied, as defined by an application. At that time, as shown in Figure 9-6, the queue manager sends a trigger message to an initiation queue to indicate that a trigger event has occurred. The message contains information about the application that processed it.

Figure 9-6. MQSeries triggers

The initiation queue is read by an application called a trigger monitor. The trigger monitor reads trigger messages and takes the appropriate action, such as starting an application to read and process messages from the appropriate queue. Trigger monitors are not really different from other MQSeries applications but read messages from the initiation queue.

Message Queue Interface

MQI is an API used by applications to send and receive MQSeries messages. This interface is standard across all supported platforms and makes it easy to port applications from one platform to another.

Transaction Support

MQSeries supports transactional messaging. It allows operations on messages to be grouped into units of work. A unit of work is either committed in its entirety or rolled back. When a group of operations is rolled back, it appears as if none of the operations took place. This functionality keeps the data shared by distributed applications in a consistent state.

For example, an application retrieves a message from a queue and processes the data in the message. In response to the received message, the application creates a set of messages to be sent to other applications, all within one unit of work. If the output queue for one of the messages to be sent is full, the application can roll back the entire unit of work so that the input message received from the queue is returned to the queue and the messages that were put into output queues are removed. After the rollback, everything is returned to the state it was in before the message was read from the application's input queue. It is as if the application had never processed the message in the first place. MQSeries can also coordinate units of messaging work with other transactional work, such as database updates, so that message data and database data remain synchronized.

MQSeries products are available for more than 35 platforms, including the Unisys ClearPath OS2200 and Sun Solaris. MQSeries supports multiple protocols, (SNA, TCP/IP, SPX, DECNet, NetBIOS) and a variety of programming languages, including Visual Basic, C, C++, Java, COBOL, and PL/I.

Products

MQSeries for ClearPath OS 2200

MQSeries for ClearPath OS 2200 is based on IBM MQSeries v5.0 and was developed by Unisys under license from IBM. OS 2200 applications may use MQSeries to communicate with other MQSeries implementations. Language bindings are provided for UCS COBOL (UCOB) and UCS C (UC). Communication with other MQSeries implementations uses a TCP/IP infrastructure and COMAPI ^[3] as the interface.

^[3] The communications API (COMAPI) provides a simple socket interface for OS 2200 programs.

WebSphere MQ

IBM MQSeries, already an important part of the WebSphere software platform for e-business, will have an even tighter association with WebSphere. MQSeries, responsible for dynamic integration, will be known as WebSphere MQ, reflecting the fundamental part it plays in dynamic e-business. MQSeries products will be renamed as part of the WebSphere family with each new release.