WebSphere MQ topologies

You can use WebSphere® MQ to create flexible connection topologies from the different connectivity options.

If you already have a WebSphere MQ solution, you do not need to change your existing WebSphere MQ topology to work with IBM® Integration Bus; the products integrate automatically.

Your WebSphere MQ applications exchange messages and other data by communicating with message flows that are running in the integration node. You can connect your applications to the integration node by using one of the supported communication methods. If your applications are written to use WebSphere MQ, the requirement for the channels or client connections are determined by the types of nodes that you include in your message flows. These resources are application-specific, and you must create these resources yourself. You might need some or all of the following resources:

  • A queue manager that is associated with the integration node. For some capabilities, you might also need to define queues for the queue manager; see IBM Integration Bus features requiring supplementary products. On z/OS® only, the queue manager is mandatory when you create an integration node, and the required queues are created for you.
  • Defined TCP/IP listener connections on the queue manager that is associated with the integration node.

For more information about creating resources, see Intercommunication in the WebSphere MQ Version 7.5 product documentation online.

Local and client connections

A local connection is a connection to a local queue manager that uses server bindings. A client connection connects to remote queue managers. You can use local connections, client connections, or a combination of local and client connections to your queue managers. On z/OS, only local connections are supported.

When you configure a connection from an MQ node to a WebSphere MQ queue manager, you can optionally configure the connection to use a security identity for authentication, SSL for confidentiality, or both. The security identity, which passes user name and password security credentials to the queue manager, can be used on connections to local or remote queue managers. For connections to remote queue managers, you can choose whether to use the SSL protocol to provide confidentiality on the client connection. IBM Integration Bus supports a subset of the SSL functionality that is supported by WebSphere MQ. For more information, see Connecting to a secured WebSphere MQ queue manager.

For globally coordinated transactions on distributed systems, you must designate a local queue manager as the transaction manager by associating it with the integration node. Other queue managers can only participate as locally-coordinated in that message flow. For more information, see Configuring MQ nodes for transactions.

There are some extra considerations if you use a remote queue manager: for example, you might want to set up security for connecting over the network. For more information, see Administration security overview.

Connection management

If a connection is lost between an integration server and queue manager, the integration server automatically attempts to reconnect to the queue manager. All resources and transports that do not require access to that connection continue to run. In a non-transactional message flow, MQInput, MQOutput, MQGet, and MQReply nodes automatically attempt to reconnect once. If the node still cannot connect, then normal exception processing occurs.

If a connection to a queue manager is lost, and that connection is enlisted in a transaction, automatic reconnection is delayed until the inflight transaction is complete. Other queue managers that are required, but are not part of the transaction, reconnect automatically without delay. A completed transaction can include the following cases:
  • The unavailable MQ resource was not required and was not used, because exception handling was defined in the message flow, so the inflight transaction was successful and committed.
  • The unavailable MQ resource was required, and the message flow cannot succeed without it, so the inflight transaction was rolled back.

To learn more about using WebSphere MQ in transactions, see Configuring MQ nodes for transactions.

Node policy

Connection details for MQ nodes can be managed by MQEndpoint policies. You can generate an MQEndpoint policy from a configured MQ node, or create it using the methods that are described in MQEndpoint policy.

WebSphere MQ topologies

You can have almost any topology configuration to connect between IBM Integration Bus and WebSphere MQ by using combinations of multiple local and client connections. The following diagrams provide examples of these basic topologies.

Scenario 1

This scenario uses multiple queue managers to a single integration node.

Diagram showing an example topology of an integration node, named IBNODE1, with a local connection to QMGR1 and QMGR2 (memory). IBNODE1 also has a client connection to QMGR3.

In this diagram, multiple queue managers are connected to a single integration node, IBNODE1. For example, the message flow might contain an MQInput and MQOutput node, which both share QMGR1 to process the messages. QMGR3 is available to IBNODE1 by a TCP/IP client connection.

Table 1. Strengths and weaknesses of scenario 1:
Strengths Weaknesses
  • The integration node can connect to a queue manager, both local and remote, without changing an existing WebSphere MQ topology
  • Failover: there is a single point of failure (IBNODE1). To mitigate this risk, you can add more integration nodes

Scenario 2

This scenario uses multiple integration nodes to a single queue manager.

Diagram showing an example topology where two integration nodes that are named IBNODE1 and IBNODE2 have client connections to QMGR1, and act as failovers for QMGR1. IBNODE3 has a local connection to QMGR1.

In this diagram, integration node IBNODE1 and IBNODE2 have client connections to the QMGR1 queue manager. The integration nodes are configured as a failover as part of a high availability WebSphere MQ solution, handling the messaging processing and saved states for QMGR1. To learn more about high availability configurations, see Configuring integration nodes for high availability.

Table 2. Strengths and weaknesses of scenario 2:
Strengths Weaknesses
  • The integration node can connect to a queue manager, both local and remote, without changing an existing WebSphere MQ topology
  • High availability WebSphere MQ-based solution
  • Failover: there is a single point of failure (QMGR1). To mitigate this risk, you can add more queue managers

Scenario 3

This scenario uses a single integration node to a single queue manager.

Diagram showing an example topology of an integration node, named IBNODE1, with a local connection to QMGR1. An integration node that is named IBNODE 2 has a client connection to QMGR2.

In this diagram, the relationship between integration node and queue managers is 1:1. A 1:1 locally connected configuration was the only option that was available before the release of IBM Integration Bus Version 10.0.

Table 3. Strengths and weaknesses of scenario 3:
Strengths Weaknesses
  • High level of control of connection behavior between IBM Integration Bus and WebSphere MQ
  • Inflexible topology, requiring more manual effort to control connection behavior and maintain solution

For more information about queue manager architecture, see Designing a WebSphere MQ architecture in the WebSphere MQ Version 7.5 product documentation online