BEA Logo BEA MessageQ Release 5.0

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy


   MessageQ Doc Home   |   MQSeries Connection User's Guide   |   Previous Topic   |   Next Topic   |   Contents   |   Index

Introduction to BEA MessageQ MQSeries Connection


To help you understand the BEA MessageQ MQSeries Connection product and the software technology behind it, this chapter discusses the following topics:

Message Queuing

Message queuing is a method of information exchange used by two or more cooperating processes, which directs messages to a memory- or disk-based queue as an intermediate storage point. Message queuing applications are generally designed so that messages flow in a request/reply fashion. After the messaging system accepts a 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, if it cannot do so, to take the appropriate action.

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.

BEA MessageQ is the BEA Systems, Inc. implementation of a message queuing system. MQSeries is the IBM implementation of a message queuing system. BEA MessageQ MQSeries Connection provides a set of programming services that allow message exchange between the BEA MessageQ and IBM MQSeries message queuing systems.

Message Queuing Interfaces

Most messaging systems provide a message queuing interface that allows 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 the development of a truly heterogeneous application environment.

Both the BEA MessageQ and IBM 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:

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 BEA MessageQ systems, the API is called the PAMS API. For more information, see the BEA MessageQ Programmer's Guide. On IBM MQSeries systems, the API is called the message queuing interface (MQI). For more information, see the MQSeries Application Programming Reference.

The BEA MessageQ Product

BEA 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. BEA MessageQ software offers a common mechanism for message exchange, called the BEA MessageQ message queuing bus, that provides an interprocess communications highway for all applications to send and receive messages.

After the application attaches to the BEA MessageQ message queuing bus, it can send and receive messages from applications running on any supported platform. BEA MessageQ software runs on most UNIX systems, OpenVMS, and Windows NT. All platforms use a common BEA MessageQ API.

BEA MessageQ software uses a client/server architecture to implement distributed communications. A client is a software module that requests services of a server. A server is a software module that responds to the client's request by providing the specified services.

Each BEA MessageQ environment requires a message server, a message routing system that distributes messages among remote nodes. A BEA MessageQ client can exchange messages with other applications on the message queuing bus (whether local or remote) through a message server.

For a complete explanation on how to install, configure, and use the BEA MessageQ product, see the BEA MessageQ documentation for your BEA MessageQ server product.

The IBM MQSeries 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 same kinds of messages; communication protocols are hidden from the applications.

Message-driven processing requires applications to be designed as discrete functional modules. Each module must be an application program with well-defined input and output parameters. An application program's input and output parameters can be shared with other application programs by being included in messages sent to queues.

Using the appropriate IBM 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 you can with other types of application.

IBM MQSeries implements a common application programming interface, called the message queuing interface (MQI), across all supported platforms.

For more information on IBM MQSeries, refer to the IBM MQSeries documentation for the platform that you are using.

How Message Queuing Systems Work

Message queuing systems enable applications to communicate without "talking" 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, based on a simple request/reply paradigm, sends messages.

Figure 1-1 Typical Message Queuing System

The request/reply interaction shown here works as follows:

The Need for Integrated Message Queuing

Typically, message queuing systems do not allow applications to send messages to queues that are written using a different message queuing system. For example, BEA MessageQ applications cannot place messages on IBM MQSeries queues and vice versa. This lack of interoperability among message queuing systems can be a problem for businesses that merge and want to integrate information systems based on different message queuing systems.

BEA MessageQ MQSeries Connection solves the integration problem by allowing messages to be passed between BEA MessageQ and IBM 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 IBM 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 requests to the server system using BEA MessageQ messages. Instead of rewriting either application, management decides to use BEA MessageQ MQSeries Connection to forward requests and responses between the two different message queuing systems.

How BEA MessageQ MQSeries Connection Works

BEA MessageQ MQSeries Connection provides a set of programming services that allow message exchange between the BEA MessageQ and IBM MQSeries V5.0 message queuing systems. Table 1-1 shows which versions of these messaging systems are supported by Versions 4.0A and 5.0 of the BEA MessageQ MQSeries Connection product.

Table 1-1 BEA MessageQ MQSeries Connection Interoperability

BEA MessageQ MQSeries Connections Version

Works with...

BEA MessageQ Version

IBM MQSeries Version







Application developers can write their applications using either message queuing system. BEA 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 BEA MessageQ for message exchange. It is designed to receive requests for account inquiries, send these requests to Application B, and return account information to bank customers. Application B is an account lookup application that uses IBM MQSeries V5.0 for message exchange. Figure 1-2 shows how account inquiries are exchanged between the two messaging systems.

Figure 1-2 BEA MessageQ MQSeries Connection Overview

  1. Application A places an account inquiry message on Queue_1, a BEA MessageQ queue.

  2. The part of BEA MessageQ MQSeries Connection called the Queue Message Bridge reads the message on Queue_1. It maps the message header data into IBM MQSeries format and forwards the message to Queue_2, an IBM MQSeries queue.

  3. Application B reads the message on Queue_2, looks up the requested account information, and places the account information in a reply message. The message is placed on Queue_3, an IBM MQSeries queue.

  4. The part of BEA MessageQ MQSeries Connection called the Queue Message Bridge reads the message on Queue_3. It maps the message header data into BEA MessageQ format and forwards the message to Queue_4, a BEA MessageQ queue.

  5. Application A reads the message on Queue_4 and displays the account information to the customer.

The LSQ (Local Service Queue) and RSQ (Remote Service Queue) designations are defined in Communication Services Between BEA MessageQ and IBM MQSeries.

The use of message queuing for application development allows software developers to concentrate on the business needs of application development, without having to worry about the underlying network and communications programming requirements. BEA MessageQ MQSeries Connection eases the integration of mixed environments by allowing applications based on the BEA MessageQ and IBM MQSeries message queuing systems to exchange information without any new code.

Communication Services Between BEA MessageQ and IBM MQSeries

The part of BEA MessageQ MQSeries Connection that provides communication services between BEA MessageQ and IBM MQSeries applications is the Queue Message Bridge (QMB). The QMB provides the following:

As shown earlier in Figure 1-2, the QMB creates a relationship between IBM MQSeries and BEA 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 (LSQ) and Remote Service Queue (RSQ):

In the banking application described earlier in the How BEA MessageQ MQSeries Connection Works section, the LSQs and RSQs are used 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 BEA MessageQ or IBM MQSeries, formats and sends a message to an LSQ. The LSQ is under the control of a QMB server. The QMB server then maps and forwards the message to the associated RSQ on behalf of the requesting application.

If the local messaging system is BEA MessageQ, the LSQ is a multireader queue and directs messages from a BEA MessageQ application to an IBM MQSeries application. If the local messaging system is IBM MQSeries, the LSQ is a shared queue and directs messages from an IBM MQSeries application to a BEA MessageQ application.

The RSQ may be of any supported queue type, and reside anywhere in the messaging system that is accessible from the BEA MessageQ group or IBM 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 Configuring the Queue Message Bridge in Configuring BEA MessageQ MQSeries Connection.

Queue Message Bridge Components

The QMB consists of two processes:

Figure 1-3 shows the architecture of the QMB.

Figure 1-3 Queue Message Bridge Architecture

BEA MessageQ to IBM MQSeries messages flow through the QMBDM server and IBM MQSeries to BEA MessageQ messages flow through the QMBMD server.

You may invoke multiple instances of the QMB to allow load balancing and tuning. The actual number of QMB processes required to drive a specific application varies, depending on the application design and overall topology.

Message Flow

A QMB process owns and maintains the LSQ. LSQs can be shared by multiple QMB processes to make BEA MessageQ MQSeries Connection scalable and tunable. An LSQ must exist for each application from which messages will be sent to a remote application. An LSQ must also exist for reply message processing.

Figure 1-4 shows how a QMB forwards a message from a BEA MessageQ LSQ to its associated IBM MQSeries RSQ.

Figure 1-4 Forwarding a Message to MQSeries

Figure 1-5 shows how a QMB forwards a message from an IBM MQSeries LSQ to its associated BEA MessageQ RSQ.

Figure 1-5 Forwarding a Message to BEA MessageQ