In WebSphere MQ configurations, the information that defines message and transmission queues is stored locally. This means that in a WebSphere MQ network the various definitions are distributed, with no central directory of this information being available for browsing. Remote messaging between WebSphere MQ applications is commonly achieved through the use of local definitions of remote queues. The application first issues an MQOPEN call using the name specified in the local definition of the remote queue. To put the message on the remote queue, the application then issues MQPUT, specifying the handle returned from the MQOPEN call. The remote queue definition supplies the name of the destination queue, the destination queue manager, and optionally, a transmission queue. In this technique the application has to know at run-time the name specified in the local queue definition.
A variation on the above avoids the use of local definitions of remote queues. The application can specify the full destination queue name, which includes the remote queue manager name as part of the MQOPEN. The application therefore has to know these two names at run-time. Again the local queue manager must be correctly configured with the local queue definition, and with a suitably named (or default) transmission queue and an associated channel that delivers to the target.
In the case where both the source and target queue managers are defined as being members of the same cluster, then the transmission queue and channel aspects of the above two scenarios can be ignored. If the target transmission queue is a cluster queue then a local definition of a remote queue is also not required. However, similarly to the previous cases described, the application must still know the name of the destination queue.
A directory service can be used to remove this application dependency on queue names (or the combination of queue and queue manager names). The mapping between application criteria and WebSphere MQ object names can be held in a directory and be updated dynamically, and independently of applications. At run-time the WebSphere MQ application wishing to send a message first queries the directory using application-based criteria, for example where: service_name = "accounts receivable", retrieves the relevant WebSphere MQ object names, and then uses these returned values in the MQOPEN call.
Another example of the use of a directory is for a company that has many small depots or offices, WebSphere MQ clients may be used to send messages to WebSphere MQ servers located in the larger offices. The clients need to know the name of the host machine, MQI channel, and queue name for each server they send messages to. Occasionally it may be necessary to move a WebSphere MQ server to another machine; every client that communicates with the server would need to know about the change. An LDAP directory service could be used to store the names of the host machines (and the channel and queue names) and the client programs could retrieve the information from the directory whenever they want to send a message to a server. In this case only the directory needs to be updated if a host name (or channel or queue name) changed.
Multiple destinations for an application message could be stored in a directory, with the one chosen being dependent on availability or load-sharing considerations.
WebSphere MQ can also use an LDAP directory to store authentication information for use with Secure Sockets Layer (SSL). WebSphere MQ classes for Java can also store information in an LDAP directory.