What is the MessageQ Client?
The MessageQ Client is a client implementation of the MessageQ Application Programming Interface (API). It provides message queuing support for distributed network applications using a MessageQ Server to provide reliable message queuing for distributed multi-platform network applications. The MessageQ Client is referred to as a "light-weight" implementation of MessageQ because it requires fewer system resources (disk space and memory) and less configuration and management than a MessageQ Server.
The MessageQ Client is connected to the message queuing bus through a network connection with a Client Library Server (CLS) on a remote MessageQ Server. The CLS acts as a remote agent to perform message queuing operations on behalf of the MessageQ Client. The CLS runs as a background server to handle multiple MessageQ Client connections. The 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.
MessageQ Clients are available for Windows 95, Windows NT, Windows 3.1, most popular UNIX systems, OpenVMS (MessageQ V4.0A), and MVS (MessageQ V3.2B) systems.
See Figure 1-1 for a diagram of the MessageQ Client and Server components.
Figure 1-1 MessageQ Client and Server Components
The 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 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 sessions. To provide robust network connections, a backup CLS can be configured for automatic failover if the primary CLS becomes unavailable. The MessageQ Client can also automatically reconnect to the CLS following a network failure.
When the connection to the CLS is unavailable, the MessageQ Client provides recoverable messaging using a local store-and-forward (SAF) journal to store recoverable messages. When the connection to the CLS is re-established, all messages in the SAF journal are sent before new messages are processed.
The MessageQ Client 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. Example programs in C and Visual Basic demonstrate the use of various features of the MessageQ API. On Windows systems, the MessageQ Client Custom Controls offer additional support for Visual Basic developers by providing a simple yet powerful means for integrating MessageQ software into Windows applications.
Benefits of Using the MessageQ Client
The MessageQ Client provides the following benefits:
The MessageQ Client provides message queuing capabilities for MessageQ applications using fewer system resources (shared memory and semaphores) and running fewer processes than a MessageQ Server. Therefore, the MessageQ Client enables distributed MessageQ applications to run on smaller, less powerful systems than the systems required to run a MessageQ Server.
Run-time configuration of the 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 MessageQ Client makes it unnecessary to install and configure a MessageQ Server on each system in the network. Instead, a distributed MessageQ environment can consist of a single system running a MessageQ UNIX or Windows NT Server and one or more systems running MessageQ Clients.
For example, suppose a small business has 10 networked workstations that need to run a MessageQ application. Prior to MessageQ Version 4.0, it would be necessary to install, configure, and manage a message queuing group on each workstation. Now, by using the MessageQ Client, a MessageQ Server need only be installed and configured on a single workstation. Installing the MessageQ Client on the remaining nine workstations provides message queuing support for all other 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 MessageQ Client consists mainly of identifying the MessageQ Server that provides full message queuing support. The MessageQ Client can be reconfigured quickly and easily and multiple clients can share the same configuration settings to further reduce system management overhead.
The 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 MessageQ Client enhances the portability of applications enabling them to be ported to a different operating system and network environment supported by MessageQ with no change to the application code.
The MessageQ Client for UNIX provides an archive library supporting MessageQ enabled applications. The MessageQ Client is available for many platforms including Digital UNIX (Alpha), AIX, HP-UX, and Solaris. Figure 1-2 shows the MessageQ Client for UNIX architecture.
Figure 1-2 MessageQ Client for UNIX Architecture
The 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 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 MessageQ Client optionally stores messages in a local journal file for later retransmission.
The Client Library Server
The Client Library Server (CLS) is a MessageQ application that runs as a background server. The CLS performs all communication with the 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 is 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.
A separate CLS process is created to support each remote client.
A single CLS process supports multiple clients using asynchronous message queuing operations.
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 set by the command-line arguments used to start the CLS.
MessageQ Client applications attempt to connect to the CLS when they initiate an attach queue operation. The MessageQ Client uses configuration information in the Registry (on Windows NT and Windows 95) or the dmq.ini configuration file (on Windows 3.1, UNIX, and OpenVMS) to identify the location of the CLS. 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 MessageQ Client and CLS Work Together
The MessageQ Client uses a request/response protocol to communicate with a Client Library Server (CLS) running on a MessageQ server system. The MessageQ Client is called a light-weight client connection to the MessageQ message queuing bus because it relies on a MessageQ Server for the following:
Figure 1-3 shows the relationship of the MessageQ Client and CLS to the MessageQ message queuing bus.
Figure 1-3 MessageQ Client and CLS Architecture
All 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
Figure 1-4 How Client Application Requests are Processed
Copyright © 2000 BEA Systems, Inc. All rights reserved.