These examples show a range of network topologies, from simple to complex, that enable WebSphere® Application Server to interoperate with WebSphere MQ using a WebSphere MQ link.
In this basic scenario, a WebSphere MQ link connects a single WebSphere Application Server application server to a WebSphere MQ queue manager. The WebSphere Application Server messaging engine that connects to WebSphere MQ by using the WebSphere MQ link is called the gateway messaging engine. The WebSphere MQ queue manager or queue-sharing group to which the WebSphere MQ link connects is called the gateway queue manager.
WebSphere MQ links always use TCP/IP connections, even if the WebSphere MQ queue manager is running on the same host as the application server. You do not need to specify a client or bindings transport type for the connection, as you do when WebSphere MQ is the messaging provider.
The WebSphere MQ link consists of one or two message channels to send messages to WebSphere MQ, receive messages from WebSphere MQ, or both. Each message channel uses one TCP/IP connection.
The message channels support point-to-point messaging between WebSphere Application Server applications and WebSphere MQ applications. You can also configure a publish/subscribe bridge on the WebSphere MQ link for publish/subscribe messaging between WebSphere Application Server applications and WebSphere MQ applications. For more details about the WebSphere MQ link and its message channels, see Message exchange through a WebSphere MQ link.
A single WebSphere MQ link can connect an entire WebSphere Application Server service integration bus, representing multiple application servers, to multiple WebSphere MQ queue managers. The messages that are exchanged between the two networks all pass through the WebSphere MQ link, which connects a single gateway messaging engine in WebSphere Application Server, and a single gateway queue manager in WebSphere MQ. The gateway messaging engine and gateway queue manager distribute the messages, which can be point-to-point or publish/subscribe messages, to the appropriate application servers and queue managers in their respective networks.
You can improve the robustness of this topology and introduce greater availability by setting up high availability frameworks in WebSphere Application Server and WebSphere MQ.
The WebSphere Application Server high availability framework eliminates single points of failure and provides peer to peer failover for applications and processes running within WebSphere Application Server. This framework also allows integration of WebSphere Application Server into an environment that uses other high availability frameworks, such as High Availability Cluster Multi-Processing (HACMP), in order to manage non- WebSphere Application Server resources.
Both WebSphere Application Server application servers and WebSphere MQ queue managers can be arranged in clusters, so that if one fails, the others can continue running. In the network topology shown here, the WebSphere Application Server cell that contains the service integration bus now includes a WebSphere Application Server cluster which provides backup for the gateway messaging engine. If the gateway messaging engine fails, it can restart in another application server in the cluster, and it can then restart the WebSphere MQ link to the gateway queue manager. Similarly, the gateway queue manager is part of a WebSphere MQ high-availability cluster.
For WebSphere Application Server and WebSphere MQ to interoperate in this network topology, you must add support for changes of IP address. The WebSphere MQ gateway queue manager uses one IP address to reach the WebSphere Application Server gateway messaging engine, and the WebSphere Application Server gateway messaging engine uses one IP address to reach the WebSphere MQ gateway queue manager. In a high availability configuration, if the gateway messaging engine fails over to a different application server, or the gateway queue manager fails and is replaced by a failover gateway queue manager, the connection to the original IP address for the failed component is lost. You must ensure that both products are able to reinstate their connection to the component in its new location.
The gateway queue manager and the gateway messaging engine store status information that they use to prevent loss or duplication of messages when they restart communication following a failure. This means that the gateway messaging engine must always reconnect to the same gateway queue manager.
If you use WebSphere MQ for z/OS® queue sharing groups, you can configure the WebSphere MQ link to use shared channels for the connection. Shared channels provide superior availability compared to the high-availability clustering options available on other WebSphere MQ platforms, because shared channels can reconnect to a different queue manager in the same queue sharing group. Reconnecting in the same queue sharing group is typically faster than waiting to restart the same queue manager in the same or a different location.
Although the network topology described in this section can provide availability and scalability, the relationship between the workload on different queue managers and the WebSphere Application Serverapplication servers to which they are connected is complex. You can contact your IBM® representative to obtain expert advice.
In this example scenario, a business has two geographically separated WebSphere Application Server cells, and wants to connect them to the same enterprise-wide WebSphere MQ network. Each service integration bus has its own gateway messaging engine, which connects using a WebSphere MQ link to a nearby WebSphere MQ gateway queue manager.
With this network topology, WebSphere Application Server applications running in either WebSphere Application Server cell can exchange point-to-point or (with a publish/subscribe bridge) publish/subscribe messages with WebSphere MQ applications. They can also use the facilities of the enterprise-wide WebSphere MQ network to exchange messages with WebSphere Application Server applications running in the other WebSphere Application Server cell. As in the previous scenario, the business can use high availability frameworks in WebSphere Application Server and WebSphere MQ to provide increased availability and scalability.