WAS v8.5 > WebSphere applications > Messaging resources > Interoperation with WebSphere MQ > Interoperation using a WebSphere MQ server
Network topologies for interoperation using a WebSphere MQ server connection and WebSphere MQ for z/OS shared queues
These examples show simple and complex topologies that enable WebSphere Application Server to interoperate with WebSphere MQ using a WebSphere MQ server connection, and a topology for using WebSphere MQ server connections with WebSphere MQ for z/OS shared queues to create a highly available messaging system.
- Single WAS application server connected to a single WebSphere MQ queue manager or queue sharing group
- Multiple applications running in separate application servers connected to a WebSphere MQ queue manager
- Use WebSphere MQ for z/OS shared queues with a WebSphere MQ server connection
For completeness, the topologies that this topic describes include clustered and highly available topologies. Note that, for clustering and high availability, you need to use the network deployment or z/OS version of the product.
Queue-type destinations with WebSphere MQ server connections
With a regular queue-type destination in the service integration bus, the queue itself is located 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 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 a WebSphere MQ server connection we can configure a service integration bus queue-type destination, so the queue itself is located in a WebSphere 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 a WebSphere MQ queue manager to access the queue.
A WebSphere MQ server connection allows applications to perform both get and put operations, unlike a WebSphere MQ link connection which only allows applications to perform put operations.
A WebSphere 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 WebSphere 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 a WebSphere 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 WebSphere 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 WebSphere MQ queue manager and uses it to get the message from the shared queue.
When an application is communicating with WebSphere MQ over a WebSphere MQ server connection, it is only aware that it is communicating with a local service integration messaging engine. The messaging engine communicates with WebSphere MQ on behalf of the application. The WebSphere MQ queue manager regards the service integration messaging engine as a WebSphere 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 WebSphere MQ using a WebSphere MQ server connection.
Multiple applications running in separate application servers connected to a WebSphere MQ queue manager
With a WebSphere MQ server connection, service integration messaging engines dynamically make individual connections to WebSphere MQ queue managers as and when they are required. There are no gateway messaging engines or gateway queue managers as there are when a WebSphere MQ link is used.
The following figure shows two applications running within separate application servers connecting to a WebSphere MQ queue manager over a WebSphere MQ 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 a WebSphere MQ queue
manager over a WebSphere MQ server connection
Use WebSphere MQ for z/OS shared queues with a WebSphere MQ server connection
WebSphere MQ server connections enable WAS applications to perform get operations (to receive messages from WebSphere MQ queues). We can, therefore, gain benefits using a WebSphere MQ server to connect to a WebSphere MQ for z/OS queue sharing group. A WebSphere 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 aWebSphere MQ link only enables applications to perform put operations.
WebSphere 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 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 a WebSphere 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 MQ 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 manger it was using failed