Main features of message queuing

The main features of applications that use message queuing techniques are:

• There are no direct connections between programs.
• Communication between programs can be time-independent.
• Work can be carried out by small, self-contained programs.
• Communication can be driven by events.
• Applications can assign a priority to a message.
• Security.
• Data integrity.
• Recovery support.

No direct connections between programs

Message queuing is a technique for indirect program-to-program communication. It can be used within any application where programs communicate with each other. Communication occurs by one program putting messages on a queue (owned by a queue manager) and another program getting the messages from the queue.

Programs can get messages that were put on a queue by other programs. The other programs can be connected to the same queue manager as the receiving program, or to another queue manager. This other queue manager might be on another system, a different computer system, or even within a different business or enterprise.

There are no physical connections between programs that communicate using message queues. A program sends messages to a queue owned by a queue manager, and another program retrieves messages from the queue (see Figure 1).

Figure 1. Message queuing compared with traditional communication

As with electronic mail, the individual messages that may be part of a transaction travel through a network on a store-and-forward basis. If a link between nodes fails, the message is kept until the link is restored, or the operator or program redirects the message.

The mechanism by which a message moves from queue to queue is hidden from the programs. Therefore the programs are simpler.

Time-independent communication

Programs requesting others to do work do not have to wait for the reply to a request. They can do other work, and process the reply either when it arrives or at a later time. When writing a messaging application, you need not know (or be concerned) when a program sends a message, or when the target is able to receive the message. The message is not lost; it is retained by the queue manager until the target is ready to process it. The message stays on the queue until it is removed by a program.

Small programs

Message queuing allows you to exploit the advantages of using small, self-contained programs. Instead of a single, large program performing all the parts of a job sequentially, you can spread the job over several smaller, independent programs. The requesting program sends messages to each of the separate programs, asking them to perform their function; when each program is complete, the results are sent back as one or more messages.

Event-driven processing

Programs can be controlled according to the state of queues. For example, you can arrange for a program to start as soon as a message arrives on a queue, or you can specify that the program does not start until there are, for example, 10 messages above a certain priority on the queue, or 10 messages of any priority on the queue.

Message priority

A program can assign a priority to a message when it puts the message on a queue. This determines the position in the queue at which the new message is added.

Programs can get messages from a queue either in the order in which the messages appear in the queue, or by getting a specific message. (A program may want to get a specific message if it is looking for the reply to a request it sent earlier.)

Security

Authorization checks are carried out on each resource, using the tables that are set up and maintained by the WebSphere MQ administrator.

• Security Server (formerly known as RACF) or other external security managers may be used within WebSphere MQ for z/OS.
• Within WebSphere MQ on UNIX systems, Windows systems, Compaq OpenVMS Alpha, Compaq NonStop Kernel, and OS/400, a security manager called the Object Authority Manager (OAM) is provided as an installable service. By default, the OAM is active.

Data integrity

Data integrity is provided via units of work. The synchronization of the start and end of units of work is fully supported as an option on each MQGET or MQPUT, allowing the results of the unit of work to be committed or rolled back. Syncpoint support operates either internally or externally to WebSphere MQ depending on the form of syncpoint coordination selected for the application.

Recovery support

For recovery to be possible, all persistent WebSphere MQ updates are logged. Hence, in the event that recovery is necessary, all persistent messages will be restored, all in-flight transactions will be rolled back and any syncpoint commit and backouts will be handled in the normal way of the syncpoint manager in control. For more information on persistent messages, see Message persistence.

WebSphere MQ clients and servers

A server application will not have to be changed to be able to support additional WebSphere MQ clients on new platforms.

Similarly, the WebSphere MQ client will, without change, be able to function with additional types of server. See WebSphere MQ Clients for more information.