![]() |
![]() |
|
|
Introduction
This section provides an introduction to the BEA MessageQ Client and covers the following topics:
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:
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:
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:
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.
Figure 1-4 How Client Application Requests are Processed
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|