Network topologies for interoperation using a IBM MQ link

These examples show a range of network topologies, from simple to complex, that enable WebSphere® Application Server to interoperate with IBM MQ using a IBM MQ link.

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.

Single WebSphere Application Server application server connected to a single IBM MQ queue manager

In this basic scenario, a IBM MQ link connects a single WebSphere Application Server application server to a IBM MQ queue manager. The WebSphere Application Server messaging engine that connects to IBM MQ by using the IBM MQ link is called the gateway messaging engine. The IBM MQ queue manager or queue-sharing group to which the IBM MQ link connects is called the gateway queue manager.

Figure 1. Single application server connected to a gateway queue manager
A WebSphere Application Server application server contains a gateway messaging engine, which connects to a gateway queue manager.

IBM MQ links always use TCP/IP connections, even if the IBM 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 IBM MQ is the messaging provider.

The IBM MQ link consists of one or two message channels to send messages to IBM MQ, receive messages from IBM 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 IBM MQ applications. You can also configure a publish/subscribe bridge on the IBM MQ link for publish/subscribe messaging between WebSphere Application Server applications and IBM MQ applications. For more details about the IBM MQ link and its message channels, see Message exchange through a IBM MQ link.

WebSphere Application Server cell connected to a IBM MQ network

A single IBM MQ link can connect an entire WebSphere Application Server service integration bus, representing multiple application servers, to multiple IBM MQ queue managers. The messages that are exchanged between the two networks all pass through the IBM MQ link, which connects a single gateway messaging engine in WebSphere Application Server, and a single gateway queue manager in IBM 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.

Figure 2. Multiple application servers connected to multiple queue managers
A WebSphere Application Server cell contains multiple application servers, which are connected to the application server in the cell that contains the gateway messaging engine. The gateway messaging engine is linked to the gateway queue manager in the IBM MQ network, which in turn is connected to further queue managers.
With this topology, interoperation ceases if any of the following conditions occurs:
  • The WebSphere Application Server application server that contains the gateway messaging engine fails.
  • The host on which that WebSphere Application Server application server is running fails.
  • The IBM MQ gateway queue manager fails.
  • The host on which the IBM MQ gateway queue manager is running fails.
In these situations, none of the application servers in the WebSphere Application Server cell can communicate with any of the queue managers in IBM MQ. In the event of a failure, messages are queued as follows:
  • If the gateway messaging engine in WebSphere Application Server fails or can no longer communicate with IBM MQ, messages that were already queued in the gateway messaging engine, which has store and forward capability, are stored there and are sent when interoperation is restored.
  • If the gateway messaging engine in WebSphere Application Server fails, messages that were queued in the messaging engines of other application servers are stored in those messaging engines and are sent when the gateway messaging engine is in operation.
  • If the gateway queue manager in IBM MQ fails or can no longer communicate with WebSphere Application Server, messages that were already queued in the gateway queue manager are sent when interoperation is restored.
  • If the gateway queue manager in IBM MQ fails, messages that were queued in other queue managers are sent when the gateway queue manager is in operation.

You can improve the robustness of this topology and introduce greater availability by setting up high availability frameworks in WebSphere Application Server and IBM MQ.

High availability for a WebSphere Application Server cell connected to a IBM MQ network

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 IBM 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 IBM MQ link to the gateway queue manager. Similarly, the gateway queue manager is part of a IBM MQ high-availability cluster.

Figure 3. High availability for multiple application servers connected to multiple queue managers
A WebSphere Application Server cell contains multiple application servers, which are connected to the application server in the cell that contains the gateway messaging engine. The application server that contains the gateway messaging engine is part of a WebSphere Application Server cluster along with another application server that contains a failover gateway messaging engine. The IBM MQ network contains a high-availability cluster which has multiple gateway queue managers. In the event of a failure of the gateway messaging engine, the application servers in the WebSphere Application Server cell connect to the failover gateway messaging engine, which links to the gateway queue manager in the same way as the original gateway messaging engine.

For WebSphere Application Server and IBM MQ to interoperate in this network topology, you must add support for changes of IP address. The IBM 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 IBM 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.

To ensure that the connection to a failover WebSphere Application Server gateway messaging engine is reinstated, choose one of the following options:
  1. If you are using a version of IBM MQ that is earlier than Version 7.0.1, install the SupportPac MR01 for IBM MQ. This SupportPac provides the IBM MQ queue manager with a list of alternative IP addresses and ports, so that the queue manager can connect with the WebSphere Application Server gateway messaging engine after the messaging engine fails over to a different IP address and port. In WebSphere Application Server you must set a high availability policy of "One of N" for the gateway messaging engine. For more information about the IBM MQ MR01 SupportPac, see MR01: Creating a HA Link between IBM MQ and a Service Integration Bus.
  2. If you are using IBM MQ Version 7.0.1, use the connection name (CONNAME) to specify a connection list. Although typically only one machine name is required, you can provide multiple machine names to configure multiple connections with the same properties. The connections are tried in the order in which they are specified in the connection list until a connection is successfully established. If no connection is successful, the channel starts retry processing. When using this option, specify the CONNAME as a comma-separated list of names of machines for the stated TransportType, making sure that all the WebSphere Application Server cluster member IPs are listed directly in the CONNAME. For further information about using the CONNAME, see the IBM MQ information center.
    Note: IBM MQ Version 7.0.1 does not require SupportPac MR01 because this release includes the equivalent function to that provided by SupportPac MR01 for earlier releases. The ability to use the CONNAME to specify a connection list was added as part of the support for multi-instance queue managers in IBM MQ Version 7.0.1, however, it can also be used as another option to ensure that the connection to a failover WebSphere Application Server gateway messaging engine is reinstated.
  3. Use an external high availability framework, such as HACMP, to manage a resource group that contains the gateway messaging engine. When you use an external high availability framework, the IP address can be failed over to the machine that runs the application server to which the gateway messaging engine has moved. Follow this procedure to handle the IP address correctly:
    • Set a high availability policy of "No operation" for the messaging engine, so that the external high availability framework controls when and where the messaging engine runs.
    • Create resources for the messaging engine and its IP address in the resource group that is managed by the external high availability framework.
    • Consider locating the messaging engine data store in the same resource group as the resource that represents the messaging engine.
To ensure that the connection to a failover IBM MQ gateway queue manager is reinstated, choose one of the following options:
  1. Set up multi-instance queue managers in IBM MQ, as described in the IBM MQ information center. In your definition for the IBM MQ link sender channel, select Multiple Connection Names List, and specify the host names (or IP addresses) and ports for the servers where the active and standby queue managers are located. If the active gateway queue manager fails, the service integration bus uses this information to reconnect to the standby gateway queue manager.
  2. Create the IBM MQ high-availability cluster using an external high availability framework, such as HACMP, that supports IP address takeover. IP address takeover ensures that the gateway queue manager in its new location appears as the same queue manager to the service integration bus.

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 IBM MQ for z/OS® queue sharing groups, you can configure the IBM MQ link to use shared channels for the connection. Shared channels provide superior availability compared to the high-availability clustering options available on other IBM 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 Server application servers to which they are connected is complex. You can contact your IBM® representative to obtain expert advice.

Multiple WebSphere Application Server cells connected to a IBM MQ network

In this example scenario, a business has two geographically separatedWebSphere Application Server cells, and wants to connect them to the same enterprise-wide IBM MQ network. Each service integration bus has its own gateway messaging engine, which connects using a IBM MQ link to a nearby IBM MQ gateway queue manager.

Figure 4. Geographically separated application servers connected to the same IBM MQ network
Two WebSphere Application Server cells each contain multiple application servers, which are connected to the application server in each cell that contains the gateway messaging engine for the cell. The gateway messaging engines in the WebSphere Application Server cells link to separate gateway queue managers in the IBM MQ network. The gateway queue managers connect to the same set of further queue managers in the IBM MQ network.

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 IBM MQ applications. They can also use the facilities of the enterprise-wide IBM 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 IBM MQ to provide increased availability and scalability.


指出主題類型的圖示 概念主題



時間戳記圖示 前次更新: July 9, 2016 11:11
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cmm_mq_top03
檔名:cmm_mq_top03.html