Network topologies for interoperation using an IBM MQ server connection and IBM MQ for z/OS shared queues

These examples show simple and complex topologies that enable WebSphere Application Server to interoperate with IBM MQ using an IBM MQ server connection, and a topology for using IBM MQ server connections with IBM MQ for z/OS shared queues to create a highly available messaging system.

Queue-type destinations with IBM MQ server connections

With a regular queue-type destination in the service integration bus, the queue itself is in a bus member within WAS. The bus member can be an application server or possibly a cluster of application servers. One or more messaging engines in the bus member manage the queue. The messaging engines can put messages onto the queue, get messages from the queue and, if necessary, maintain disk copies of the messages. When an application connects to the service integration bus, it might connect to a messaging engine that is not where the queue is located. In that case, the messaging engine where the application connects communicates with and uses the messaging engine where the queue is located.

With an IBM MQ server connection we can configure a service integration bus queue-type destination, so that the queue itself is in an IBM MQ queue manager or queue-sharing group. In this case, the queue manager or queue-sharing group is included in the service integration bus as a bus member. Service integration messaging engines in the bus communicate with and use an IBM MQ queue manager to access the queue.

An IBM MQ server connection allows applications to perform both get and put operations, unlike an IBM MQ link connection which only allows applications to perform put operations.

An IBM MQ server connection can use either a "bindings" connection (call attach) or a "client" connection (a TCP/IP connection). A "bindings" connection can only be used when the application server and the queue manager or queue sharing group are running on the same host or in the same logical partition (LPAR). If the application server and the queue manager or queue sharing group are running on different hosts, then a "client" connection must be used.

Single WAS application server connected to a single IBM MQ queue manager or queue sharing group

This basic scenario uses a service integration bus with a single messaging engine. The bus includes a queue-type destination configured to use an IBM MQ shared queue. A single application connects to the service integration bus and accesses the queue-type destination.

When the application sends a message to the destination, the messaging engine communicates with the IBM MQ queue manager and uses it to add the message to the shared queue. When the application receives a message from the destination, the messaging engine communicates with the IBM MQ queue manager and uses it to get the message from the shared queue.

When an application is communicating with IBM MQ over an IBM MQ server connection, it is only aware that it is communicating with a local service integration messaging engine. The messaging engine communicates with IBM MQ on behalf of the application. The IBM MQ queue manager regards the service integration messaging engine as an IBM MQ client.

In the following figure, the connecting line labeled A shows the queue manager appearing to the service integration messaging engine as a member of its local bus. The connecting line labeled B shows the service integration messaging engine appearing to the queue manager as another queue manager.

Figure 1. Single application running within WAS and connecting to IBM MQ using an IBM MQ server connection.

Multiple applications running in separate application servers connected to an IBM MQ queue manager

With an IBM MQ server connection, service integration messaging engines dynamically make individual connections to IBM MQ queue managers as and when they are required. There are no gateway messaging engines or gateway queue managers as there are when an IBM MQ link is used.

The following figure shows two applications running within separate application servers connecting to an IBM MQ queue manager over a WebSphere Q server connection. The service integration bus includes two messaging engines and one queue manager.

Figure 2. Two applications running within separate application servers connecting to an IBM MQ queue manager over an IBM MQ server connection

Use IBM MQ for z/OS shared queues with an IBM MQ server connection

IBM MQ server connections enable WAS applications to perform get operations (to receive messages from IBM MQ queues). We can, therefore, gain benefits using an IBM MQ server to connect to an IBM MQ for z/OS queue sharing group. An IBM MQ link can connect WAS applications to a queue sharing group, but the applications cannot realize the full benefits of shared queues because they cannot consume messages from them, as aIBM MQ link only enables applications to perform put operations.

IBM MQ for z/OS queue sharing groups provide significant benefits through the use of shared queues. Multiple applications can send messages to and receive messages from the same shared queue using different queue managers in the same queue sharing group. This gives the following advantages:

• The different applications (or different instances of the same application) compete to process messages on the same queue. An instance which is able to process messages more quickly, perhaps because the instance is running on a more powerful or less heavily loaded processor, automatically processes a higher proportion of the messages on the queue, giving better utilization of the available resources and better overall response times. This is called "pull workload balancing".

• If one queue manager in a queue sharing group fails, applications can connect to a different queue manager and continue using the same shared queue. This provides superior availability for the applications. A special feature of queue sharing groups, called "peer level recovery", handles the cases where an application receives a message from a shared queue but the queue manager fails before processing of the message is complete. Provided that the application is transactional, another queue manager in the same queue sharing group can return the message to the shared queue so that it can be processed without waiting for the failed queue manager to recover. Peer level recovery further enhances the availability of the applications.

• Queue sharing groups also enable service integration to connect to the queue sharing group using a single network address for the collection of queue managers in the queue sharing group. The connection is automatically redirected to a suitable queue manager in the queue sharing group, based on which queue managers are available, and which is able to provide the best response time. This feature enhances both the availability and the performance of the application.

We can provide these benefits to your service integration applications by defining service integration destinations on shared queues owned by an IBM MQ server that is in a queue sharing group. The following figure shows a service integration messaging engine connecting to one queue manager (QM1) in a queue sharing group. The connection enables a service integration application to consume messages from a shared queue. Other service integration applications on the same or a different application server can use different connections (to the same or different queue managers, QM2 or QM3, in the same queue sharing group) to consume messages from the same shared queue.

Figure 3. A messaging engine connecting to a queue manager to access a queue sharing group, using a WebSphere Q server connection

The following figure shows that when a queue manager (QM1) in the queue sharing group is temporarily unavailable, service integration can connect to a different queue manager (QM2), enabling applications to continue processing messages from the queue.

Figure 4. A messaging engine connecting to a second queue manager to access a queue sharing group, after the original queue manager it was using failed