The MessageQ Client, Version 4.0 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, most popular UNIX systems, OpenVMS, OS/2, Digital OpenVMS, and IBM MVS 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 or DECnet 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 running the 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 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 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, Visual Basic, and PowerBuilder 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.
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, Windows NT, OpenVMS, or OS/2 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. Under previous versions of MessageQ, it would be necessary to install, configure, and manage a message queuing group on each workstation. Now, however, by using the MessageQ Client, a MessageQ Server need be installed and configured only 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 Windows provides a reentrant 32-bit Dynamic Link Library (DLL) supporting multiple MessageQ-enabled Windows applications. Both Intel (Windows NT and Windows 95) and Alpha (Windows NT) DLLs are provided. Figure 1-2 shows the MessageQ Client for Windows 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 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 MessageQ Client optionally stores messages in a local journal file for later retransmission.
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 are isolated from other clients.
The CLS supports multiple client connections using the following techniques:
Architectural Overview
Figure 1-2 MessageQ Client for Windows Architecture
The Client Library Server
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.
MessageQ Client applications attempt to connect to the CLS when they initiate an attach queue operation. The MessageQ Client uses configuration information in the 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.
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:
dmq.ini configuration file or the Windows Registry 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.
How the MessageQ Client and CLS Work Together
Figure 1-3 shows the relationship of the MessageQ Client and CLS to the MessageQ message queuing bus.
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-3 MessageQ Client and CLS Architecture
