To help you understand MessageQ MQSeries Connection and the software technology behind it, this chapter discusses the following topics:
Message queuing is the interprocess communication and information exchange between two or more cooperating processes, which is accomplished by directing messages to a memory- or disk-based queue as an intermediate storage point. Message queuing applications are generally designed so that the messages flow in a request/reply fashion. After the messaging system accepts the message from the application, the application is free to continue work. It is the responsibility of the messaging system to deliver the message to the target queue, or to take the appropriate action if the messaging system cannot deliver the message.
Most message queuing applications use asynchronous processing to send and receive messages. The sending and receiving applications are uncoupled or loosely coupled at best. They read and operate on the messages independently. If your application requires a tightly coupled (synchronous) relationship between the sending and receiving applications, you must design and enforce the tight coupling in the application logic using predefined message flow protocols.
MessageQ is the BEA Systems, Inc. implementation of a message queuing system; MQSeries is the IBM implementation of a message queuing system.
Most messaging systems provide a message queuing interface for applications to access resources at remote locations. Applications access these resources through common calls that contain no communications protocol-specific variables. The message queuing interface is independent and isolated from any communications protocol implemented by the messaging system.
The communications engine of the messaging system is responsible for all of the physical communications protocols and message delivery. This insulation provides the application with a network-independent topology, and facilitates a true heterogeneous application environment.
Both the MessageQ and MQSeries messaging systems provide a common application programming interface (API). The API is a set of basic functions, in the appropriate language, that provide applications access to the messaging system resources. The use and format of the API functions remains constant across all environments supported by the messaging system. Therefore, properly designed applications are platform-independent.
The basic API for most messaging systems consists of functions that perform the following tasks:
Message Queuing
Message Queuing Interfaces
In addition to these basic functions, the messaging system may offer advanced features such as message recovery, selective messaging, message broadcasting, and application development tools.
On MessageQ systems, the API is called the PAMS API. For more information, see the MessageQ Programmer's Guide. On MQSeries systems, the API is called the message queuing interface (MQI). For more information, see the MQSeries Message Queue Interface Technical Reference Manual.
MessageQ software is a message queuing system for heterogeneous computing environments that eliminates the need to learn system-level communications software for sending and receiving messages. MessageQ software offers a common mechanism for message exchange, called the MessageQ message queuing bus, that provides a single attachment point for all applications to send and receive messages.
After the application attaches to the MessageQ message queuing bus, it can send and receive messages from applications running on any supported platform. MessageQ software runs on most UNIX systems, OpenVMS, and Windows NT. All platforms use a common MessageQ API.
MessageQ software uses a client/server architecture to implement distributed communications. A client is a software module that, while performing its function, requests services of a server. A server is a software module that responds to the client's request by providing a specific set of functions to the client.
The configuration of each MessageQ environment requires a message routing system, or message server, to distribute messages between remote nodes. A MessageQ client can exchange messages locally, or remotely with other applications on the message queuing bus through a message server.
For a complete explanation on how to install, configure, and use MessageQ, see the MessageQ documentation for your MessageQ Server product.
IBM MQSeries products enable applications to use message queuing to participate in message-driven processing. With message-driven processing, applications can communicate across the same or different platforms using the appropriate message queuing product. With MQSeries products, all applications use the same kinds of messages and communication protocols are hidden from the applications.
Message-driven processing requires that application design be divided into separate, discrete, functional modules. Each module must have well-defined input and output parameters and be coded as an application program. The program's input and output parameters can be interchanged between other application programs by placing their values in messages, which are then sent to queues.
Using the appropriate MQSeries programming mechanisms, an application program can start executing as a result of one or more messages arriving on a queue. If required, the program can terminate when all messages in a queue have been processed. Message-driven processing allows you to build or modify applications more quickly than with some other application design styles.
MQSeries implements a common application programming interface, called the message queuing interface (MQI), across all supported platforms.
For more information on MQSeries, refer to the IBM MQSeries technical documentation for the platform that you are using.
Message queuing systems work by enabling applications to communicate without having applications talk directly with each other. Messages are placed on message queues for a target application to read. The target application reads the message and responds appropriately.
Figure 1-1 shows how a typical message queuing system, which has a simple request/reply paradigm, sends messages.
Note the following about Figure 1-1:
The BEA MessageQ Product
The IBM MQSeries Product
How Message Queuing Systems Work
Figure 1-1 Typical Message Queuing System
Typically, message queuing systems do not allow applications to send messages to queues that are written using a different message queuing system. For example, MessageQ applications cannot place messages on MQSeries queues and vice versa. Because message queuing systems cannot communicate with each other, this can be a problem for businesses that merge and want to integrate their information systems that use different message queuing systems.
MessageQ MQSeries Connection solves the integration problem by allowing messages to be passed between MessageQ and MQSeries message queuing systems. For example, suppose two banks merge and need to integrate their information systems. Management decides to consolidate all account information on IBM systems that use MQSeries for message exchange. In addition, management wants its customers to continue using their current ATM system. The ATM system receives requests for account information and dispatches the request to the server system using MessageQ messages. Instead of rewriting either application, management decides to use MessageQ MQSeries Connection to forward requests and responses between the two different message queuing systems.
MessageQ MQSeries Connection provides a set of programming services that allow message exchange between the MessageQ and MQSeries message queuing systems. Application developers can write their applications using either message queuing system. MessageQ MQSeries Connection makes sure that messages are properly passed between the two message queuing systems, and that the message header information is in the proper format for the target application.
For example, suppose Application A is the ATM application that uses MessageQ for message exchange. It is designed to receive requests for account inquiries, send them to Application B and return account information to bank customers. Application B is an account lookup application that uses MQSeries for message exchange. Figure 1-2 shows how account inquiries are exchanged between the two messaging systems.
The Need for Integrated Message Queuing
How MessageQ MQSeries Connection Works
Figure 1-2 MessageQ MQSeries Connection Overview
The use of message queuing for application development allows software developers to concentrate on the business needs of application development, with no regard for the underlying network and communications programming requirements. MessageQ MQSeries Connection eases the integration of mixed environments by allowing applications developed to use either the MessageQ or the MQSeries message queuing systems to exchange information without the need to recode the component applications.
The part of MessageQ MQSeries Connection that provides communication services between MessageQ and MQSeries applications is the Queue Message Bridge (QMB). These communication services include:
As shown in Figure 1-2, the QMB creates a relationship between MQSeries and MessageQ queues in order to be able to forward messages between them. This relationship is based on the use of two QMB specific entities referred to as the Local Service Queue and Remote Service Queue:
In the banking application described in the How MessageQ MQSeries Connection Works topic, the LSQs and RSQs are as follows:
The QMB uses the terms local and remote to reference its own view of the processing environment. The LSQ is owned and maintained by a QMB. The RSQ is owned and maintained by the partner messaging system and application service program. Message delivery between the LSQ and RSQ is asynchronous.
A requesting application, as defined in either MessageQ or MQSeries, formats and sends a message to LSQ. The LSQ is under the control of a QMB program. The QMB program then maps and forwards the message to the associated RSQ on behalf of the requesting application.
If the local messaging system is MessageQ, the LSQ is a multireader queue and has the message flow direction of MessageQ to MQSeries. If the local messaging system is MQSeries, the LSQ is a shared queue and has the message flow direction of MQSeries to MessageQ.
The RSQ may be of any supported queue type, and reside anywhere in the messaging system, that is accessible from the MessageQ group or MQSeries Message Queue Manager of the designated QMB process.
The QMB relies on an LSQ to RSQ relationship to know where to forward messages. This relationship is established in the QMB queue configuration file. For more information on this file, see the Configuring the Queue Message Bridge topic.
The QMB has the following components:
Queue Message Bridge Components
Figure 1-3 shows the architecture of the QMB.
The QMB has two components to allow messages to flow in two different directions. Messages that flow from MessageQ applications to MQSeries applications require that a QMBDM process be running. Conversely, messages that flow from MQSeries applications to MessageQ applications require that a QMBMD process be running.
Bidirectional message exchange requires two instances of the QMB. The first instance sends the message from the local messaging system to the remote messaging system. The second instance sends a message from the remote messaging system to the local messaging system. You must have both the QMBDM and QMBMD processes running in order to have messages forwarded from an LSQ to RSQ.
You may invoke multiple instances of the QMB to allow load balancing and tuning considerations. The actual number of QMB processes required to drive a specific application varies depending on the characteristics of the application design and overall topology.
A QMB process owns and maintains the LSQ. LSQs can be shared by multiple QMB processes to allow MessageQ MQSeries Connection a level of scalability and tuning. An LSQ must exist for each application wishing to send a message to a remote application. An LSQ must also exist for reply message processing.
Figure 1-4 shows the message direction for a message sent to a MessageQ LSQ. The message is forwarded by the QMB to its associated MQSeries RSQ.
Figure 1-5 shows the message direction for a message sent to an MQSeries LSQ. The message is forwarded by the QMB to its associated MessageQ RSQ.
Figure 1-3 Queue Message Bridge Architecture
Message Flow
Figure 1-4 Message Forwarding to MQSeries
Figure 1-5 Message Forwarding to MessageQ
