WAS v8.5 > WebSphere applications > Messaging resources > Interoperation with WebSphere MQ > Interoperation using the WebSphere MQ messaging providerNetwork topologies: Interoperating using the WebSphere MQ messaging provider
There are several network topologies, clustered and not clustered, that allow WebSphere Application Server to interoperate with WebSphere MQ using WebSphere MQ as an external JMS messaging provider. For providing high availability, some topologies are more suitable than others.
For completeness, this topic describes a wide range of topologies, including 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.
In this topic "application server" refers to an application server that is running on WAS and "queue manager" refers to a queue manager that is running on WebSphere MQ.
The WAS high availability framework eliminates single points of failure and provides peer to peer failover for applications and processes running within WAS. This framework also allows integration of WAS into an environment that uses other high availability frameworks, such as High Availability Cluster Multi-Processing (HACMP™), in order to manage non-WAS resources.
The subsequent examples show the main network topologies for interoperating withWebSphere MQ using the WebSphere MQ messaging provider. Each of the four examples describes two network topologies, with varying locations for the application servers and queue managers.
- Interoperation when WAS application server is not clustered and WebSphere MQ queue manager is not clustered
- The application server and the queue manager run on different hosts
- The application server and the queue manager run on the same host
- Interoperation when WAS application servers are clustered but WebSphere MQ queue manager is not clustered
- The queue manager runs on a different host from any of the application servers
- The application servers run on several hosts, one of which hosts a queue manager
- Interoperation when WAS application servers are clustered and WebSphere MQ queue managers are clustered
- The queue managers run on different hosts from the application servers
- The queue manager runs on the same hosts as the application servers
- Connect WAS application servers to WebSphere MQ for z/OS with queue-sharing groups
- The application servers and the queue managers run in the same LPAR
- The application servers and the queue managers run in different LPARs
Subtopics
- Interoperation when WAS application server is not clustered and WebSphere MQ queue manager is not clustered
Application servers running on WAS and queue managers running on WebSphere MQ can connect to each other when neither of them are clustered. However, this setup can be vulnerable to failure.- Interoperation when WAS application servers are clustered but WebSphere MQ queue manager is not clustered
Application servers running on WAS can be clustered together and connected to queue managers running onWebSphere MQ that are not clustered. This setup provides enhanced failover protection over non-clustered topologies.- Interoperation when WAS application servers are clustered and WebSphere MQ queue managers are clustered
WebSphere MQ queue managers are usually clustered in order to distribute the message workload and because, if one queue manager fails, the others can continue running.- Connect WAS application servers to WebSphere MQ for z/OS with queue-sharing groups
On z/OS systems, an application server can connect to a queue manager that is a member of a WebSphere MQ for z/OS queue-sharing group. We can configure the connection so that it selects a specific named queue manager, or we can configure it to accept any queue manager in the queue-sharing group.