Introduction

 

This section provides an introduction to the BEA MessageQ Client and covers the following topics:

• What is the BEA MessageQ Client?

• Benefits of Using the BEA MessageQ Client

• Architectural Overview

What is the BEA MessageQ Client?

The BEA MessageQ Client is a client implementation of the BEA MessageQ Application Programming Interface (API). It provides message queuing support for distributed network applications using a BEA MessageQ Server to provide reliable message queuing for distributed multi-platform network applications. The BEA MessageQ Client is referred to as a "light-weight" implementation of BEA MessageQ because it requires fewer system resources (disk space and memory) and less configuration and management than a BEA MessageQ Server.

The BEA MessageQ Client is connected to the message queuing bus through a network connection with a Client Library Server (CLS) on a remote BEA MessageQ Server. The CLS acts as a remote agent to perform message queuing operations on behalf of the BEA MessageQ Client. The CLS runs as a background server to handle multiple BEA MessageQ Client connections. The BEA MessageQ Client establishes a network connection to the CLS when an application attaches to the message queuing bus. The CLS performs all communication with the client application until the application detaches from the message queuing bus. The network connection to the CLS is closed when the application detaches from the message queuing bus.

BEA MessageQ Clients are available for Windows 95, Windows NT, most popular UNIX systems, OpenVMS, and IBM MVS systems. See Figure 1-1 for a diagram of the BEA MessageQ Client and Server components.

Figure 1-1 BEA MessageQ Client and Server Components

The BEA MessageQ Client allows multiple applications to connect to separate queues on the message queuing bus. A separate network connection to the CLS is maintained for each BEA MessageQ Client application. The message queuing operations and network activities of each client are isolated from other clients. The total number of applications that can connect to the message queuing bus is limited by the number of TCP/IP or DECnet sessions. To provide robust network connections, a backup CLS can be configured for automatic failover if the primary CLS becomes unavailable. The BEA MessageQ Client can also automatically reconnect to the CLS following a network failure.

When running the BEA MessageQ Client on Windows systems, users can select the standard request/response protocol or the Minimum Packet Protocol (MPP) to reduce network traffic. There is no performance advantage by using MPP on high-speed local area networks, because MPP is designed for use in wireless networks or dialup connections with network speeds lower than local area networks.

When the connection to the CLS is unavailable, the BEA MessageQ Client provides recoverable messaging using a local store-and-forward (SAF) journal to store recoverable messages. When the connection to the CLS is reestablished, all messages in the SAF journal are sent before new messages are processed.

The BEA MessageQ Client for Windows supports a variety of popular application development environments and languages including C/C++, Visual Basic, PowerBuilder, and others. In addition, it includes several utility programs to monitor and test applications. The BEA MessageQ clients for UNIX and OpenVMS systems provide language bindings for C and C++. Example programs demonstrate the use of various features of the BEA MessageQ API.

Benefits of Using the BEA MessageQ Client

The BEA MessageQ Client provides the following benefits:

• Reduces system resource load

• Reduces system management overhead

• Provides network protocol independence

The BEA MessageQ Client provides message queuing capabilities for BEA MessageQ applications using fewer system resources (shared memory and semaphores) and running fewer processes than a BEA MessageQ Server. Therefore, the BEA MessageQ Client enables distributed BEA MessageQ applications to run on smaller, less powerful systems than the systems required to run a BEA MessageQ Server.

Run-time configuration of the BEA MessageQ Client is extremely simple. A minimal configuration requires only the name of the server system, the network endpoint to be used by the CLS, and the desired network transport. Running the BEA MessageQ Client makes it unnecessary to install and configure a BEA MessageQ Server on each system in the network. Instead, a distributed BEA MessageQ environment can consist of a single system running a BEA MessageQ UNIX, Windows NT, or OpenVMS Server and one or more systems running BEA MessageQ Clients.

For example, suppose a small business has 10 networked workstations that need to run a BEA MessageQ application. Under previous versions of BEA MessageQ, it would be necessary to install, configure, and manage a message queuing group on each workstation. Now, however, by using the BEA MessageQ Client, a BEA MessageQ Server need be installed and configured only on a single workstation. Installing the BEA MessageQ Client on the remaining nine workstations provides message queuing support for all other BEA MessageQ applications in the distributed network.

In this example, only one workstation needs to be sized and configured to optimize performance, reducing the burden of system management to a single machine. System management and configuration for the remaining systems is drastically simplified because managing the BEA MessageQ Client consists mainly of identifying the BEA MessageQ Server that provides full message queuing support. The BEA MessageQ Client can be reconfigured quickly and easily and multiple clients can share the same configuration settings to further reduce system management overhead.

The BEA MessageQ Client performs all network operations for client applications, making it unnecessary for a client program to be concerned about the underlying network protocol. The BEA MessageQ Client enhances the portability of applications, enabling them to be ported to a different operating system and network environment supported by BEA MessageQ with no change to the application code.

Architectural Overview

The BEA MessageQ Client for OpenVMS provides a shareable image supporting multiple BEA MessageQ-enabled applications. An object library is also provided for applications that need to use static linking. The BEA MessageQ Client is available for both VAX and Alpha processors. Figure 1-2 shows the BEA MessageQ Client for OpenVMS architecture.

Figure 1-2 BEA MessageQ Client for OpenVMS Architecture

The BEA MessageQ Client allows multiple applications to connect to separate queues on the message queuing bus. A separate network connection to the CLS is created for each client application. The total number of applications that can connect to the message queuing bus is limited by the number of TCP/IP or DECnet sessions. On Windows systems, the Client DLL uses the Windows Sockets API for network services.

If the network connection to the CLS is lost or unavailable, the BEA MessageQ Client optionally stores messages in a local journal file for later retransmission.

The Client Library Server

The Client Library Server (CLS) is a BEA MessageQ application that runs as a background server. The CLS performs all communication with the BEA MessageQ Client for each client application until the application detaches from the message queuing bus. The message queuing operations and network activity of each client are isolated from other clients.

The CLS supports multiple client connections using the following techniques:

• On Windows NT Server systems, the CLS is multi-threaded.

• On UNIX Server systems, the CLS uses a separate process to handle each BEA MessageQ Client connection.

• On OpenVMS Server systems, the CLS can operate in two modes:

  Single-client mode	A separate CLS process is created to support each remote client.
  Multi-client mode	A single CLS process supports multiple clients using asynchronous message queuing operations provided by BEA MessageQ for OpenVMS systems.

When the CLS starts, it initializes a listener process (or thread) that establishes a network endpoint and waits for connections from a client application. The endpoint on which the CLS listens is determined by the command-line arguments used to start the CLS.

BEA MessageQ Client applications attempt to connect to the CLS when they initiate an attach queue operation. The BEA MessageQ Client uses configuration information in the dmq.ini configuration file. The CLS creates a server subprocess (or server thread) for each new client connection. The server subprocess terminates when the client detaches from the bus, or the network connection is closed.

The CLS can use a security file (located on the server system) to control client access to the message bus. Client access can be restricted to specific queues or CLS endpoints.

How the BEA MessageQ Client and CLS Work Together

The BEA MessageQ Client uses a request/response protocol to communicate with a Client Library Server (CLS) running on a BEA MessageQ server system. The BEA MessageQ Client is called a light-weight client connection to the BEA MessageQ message queuing bus because it relies on a BEA MessageQ Server for the following:

• Message queues for all BEA MessageQ Client applications are implemented on a remote system running a BEA MessageQ Server group.

• Message delivery to target queues is provided by the Queuing Engine, a server process that runs on a BEA MessageQ Server.

• Message routing and cross-group transport among multiple BEA MessageQ Server systems and other BEA MessageQ Client applications are provided by the BEA MessageQ Server group.

• Guaranteed message delivery is provided by the MRS capability of the BEA MessageQ Server group. The BEA MessageQ Client provides a local store-and-forward (SAF) journal for temporarily storing recoverable messages when the connection to the CLS is not available.

Figure 1-3 shows the relationship of the BEA MessageQ Client and CLS to the BEA MessageQ message queuing bus.

Figure 1-3 BEA MessageQ Client and CLS Architecture

All BEA MessageQ Client API functions supported by the CLS are processed using the following sequence of events as shown in Figure 1-4.

1. The client application makes a BEA MessageQ function call to the BEA MessageQ Client.

2. The BEA MessageQ Client verifies the function call arguments and sends them in a request to the CLS, which is waiting to receive client requests.

3. When a request arrives, the CLS makes the corresponding BEA MessageQ function call in the BEA MessageQ Server group.

4. The BEA MessageQ function completes, and returns the results to the CLS.

5. The CLS sends the return parameters and function status in a response back to the BEA MessageQ Client that initiated the request.

6. The BEA MessageQ Client function call returns to the application with the return arguments and function status.

   Figure 1-4 How Client Application Requests are Processed