IBM's MQSeries Transaction Messaging Software Follow this link for the official IBM web site for MQSeries. A brief introduction to MQSeries What constitutes a message Queue Managers Queues Channels The MQSeries API MQSeries Techniques Some example programs using MQSeries A Java MQSeries Configuration Tool A brief introduction to MQSeries As a whole MQSeries enables messages to be exchanged, either synchronously or asynchronously, between application programs running on one or more target systems. Messages travelling between programs are stored on message queues, which are under the control of a service provider called a queue manager. In general, a queue manager is required on each target system. Messages destined for a different system than the one on which it was created, a remote system, will be communicated to the queue manager on that system via an MQSeries channel. To the programmer MQSeries is presented as an application programming interface (API) which is unified across the supported hardware and software platforms. The API is very simple and is available in a variety of languages including C, Java and Cobol. MQSeries can be configured to provide assured delivery of the messages. Assured delivery means that even if the hardware or software platform crashes the messages within the system will still be delivered, once the platforms are brought back up. On a typical target system MQSeries consists of a queue manager and a number of queues and channels. What constitutes a Message An MQSeries message is simply a collection of data sent by one program and intended for another program. The message consists of control information and application specific data. The control information is required in order to route the message between the programs, and, to some extent, describe the contents of the application data section. The application data is free-form and MQSeries places no overall constraint on the contents except a maximum length (4 Mb, or 100 Mb on Version 5). A message can be classed as persistent or non-persistent. A persistent message will survive a software or hardware crash / reboot, once communicated to a queue manager, whereas a non-persistent message will not survive. Persistent messages are used as part of the implementation of the assured delivery service supported by MQSeries. Queue Managers It is the queue manager that provides the queuing services to the application programs. A queue manager also provides additional functions so that administrators can create new queues, alter the properties of existing queues and control the operation of the queue manager. Many applications can make use of the queue manager's facilities at the same time, and they can be completely unrelated. It is possible to connect queue managers on different platforms together, this is achieved via a mechanism called channels. Queues Queues are named message repositories upon which messages accumulate until they are retrieved by programs that service those queues. Queues reside in, and are managed by, a queue manager. Programs access queues via the services provided by the queue manager. They can open a queue, put messages on it, get messages from it, and close the queue. It is also possible to programmatically set, and inquire about, the attributes of queues. Queues are either defined as local or remote. Local queues allow programs to both put messages on, and get messages off, while remote queues only allow programs to put messages on. Remote queues are used in order to provide put access to queues that are local to another platform. Any message put onto a remote queue is automatically routed to the associated platform and local queue by the queue manager via the channels mechanism. Channels Channels are named links between platforms across which messages are transmitted. On the source platform the channel would be defined as a sender and on the destination platform as a receiver. It is the sender channel definition that contains the connectivity information, such as the destination platform's name or IP address. Channels must have the same name on both the source and destination platform.