+

Search Tips   |   Advanced Search

Interoperation with IBM MQ: Comparison of architectures

The three different ways that we can send messages between WebSphere Application Server and an IBM MQ network are compared at a high level, showing the relative advantages and disadvantages of each approach.


IBM MQ as an external messaging provider

The IBM MQ messaging provider does not use service integration. It provides JMS messaging access to IBM MQ from WAS.The IBM MQ messaging provider makes point-to-point messaging and publish/subscribe messaging available to WAS applications using the existing capabilities in the IBM MQ environment. WAS applications can interact with IBM MQ queues and topics to send, receive, publish, and subscribe to messages in the same way as any JMS application in the IBM MQ environment.

Using IBM MQ as an external messaging provider requires more IBM MQ administration, less WAS administration.

Advantages Disadvantages

  • We do not have to configure a service integration bus or messaging engines.
  • We can connect directly to IBM MQ queue managers.
  • We manage a single JMS messaging provider rather than two.
  • We can connect to queue managers in client mode or bindings mode.
  • Use point-to-point messaging and publish/subscribe messaging.

  • Interaction between WAS and IBM MQ is not seamless.
  • We cannot use service integration mediations for modifying messages, for routing, or for logging.


An IBM MQ network as a foreign bus (using IBM MQ links)

An IBM MQ link provides a server to server channel connection between a service integration bus and an IBM MQ queue manager or queue-sharing group, which acts as the gateway to the IBM MQ network.When we use an IBM MQ link, the messaging bus is seen by the IBM MQ network as a virtual queue manager, and the IBM MQ network is seen by service integration as a foreign bus. An IBM MQ link enables WAS applications to send point-to-point messages to IBM MQ queues (defined as destinations in the service integration bus), and allows IBM MQ applications to send point-to-point messages to destinations in the service integration bus (defined as remote queues in IBM MQ). We can also set up a publish/subscribe bridge so that WAS applications can subscribe to messages published by IBM MQ applications, and IBM MQ applications can subscribe to messages published by WAS applications. The link ensures that messages are converted between the formats used by WAS and those used by IBM MQ.

Using an IBM MQ network as a foreign bus (using IBM MQ links) requires more WAS administration, less IBM MQ administration.

Advantages Disadvantages

  • An IBM MQ client facility is not required on the gateway IBM MQ queue manager.
  • Each end of the link appears in natural form to the other; IBM MQ appears to service integration to be a (foreign) bus, service integration appears to IBM MQ to be a (virtual) queue manager.
  • Better performance over the link is possible when compared with IBM MQ servers or direct connection to IBM MQ as an external JMS messaging provider.
  • A managed connection from one node to another is created, but not from every application server in the cell.
  • We do not have to define individual IBM MQ queues to the service integration bus.
  • Good security support is provided. For example, we can control which users are allowed to put messages onto queues.
  • WAS and IBM MQ can exist on separate hosts.
  • Interaction between WAS and IBM MQ is seamless.
  • We can configure a publish/subscribe bridge, through which WAS applications can subscribe to messages published by IBM MQ applications, and IBM MQ applications can subscribe to messages published by WAS applications.

  • Configure a service integration bus and messaging engines.
  • We cannot connect to queue managers in bindings mode.
  • Optimum load balancing is less easy to achieve because messages have to be "pushed" from either end of the link.
  • We cannot use service integration mediations for modifying messages, routing, or logging.


An IBM MQ server (a queue manager or queue-sharing group) as a bus member

An IBM MQ server provides a direct client connection between a service integration bus and queues on an IBM MQ queue manager or (for IBM MQ for z/OS ) queue-sharing group. For interoperation with WAS v7 or later, the version of IBM MQ must be IBM MQ for z/OS v6 or later, or IBM MQ (distributed platforms) v7 or later. An IBM MQ server supports the high availability and optimum load-balancing characteristics provided by an IBM MQ for z/OS network. An IBM MQ server defines the connection and quality of service properties used for the connection, and also ensures that messages are converted between the formats used by WAS and those used by IBM MQ. An IBM MQ server only represents queues for point-to-point messaging; it does not represent topics for publish/subscribe messaging.

Using an IBM MQ server (a queue manager or queue-sharing group) as a bus member requires more WAS administration, less IBM MQ administration.

Advantages Disadvantages

  • WAS and IBM MQ can exist on separate hosts.
  • Each end of the connection appears in natural form to the other; IBM MQ queue manager appears to service integration to be a foreign bus, service integration appears to IBM MQ to be a client.
  • Close integration of applications is possible; service integration applications are able to consume messages directly from the IBM MQ network.
  • We can connect to queue managers in client mode or bindings mode.
  • We can use mediations for modifying messages, routing, or logging.
  • Good security support is provided. For example, we can control which users are allowed to put messages onto queues.
  • We can get messages from IBM MQ queues (GET).
  • Interaction between WAS and IBM MQ is seamless.
  • Queues on the IBM MQ network are automatically discovered.

  • IBM MQ Server is deprecated as of WAS v9
  • Configure a service integration bus and messaging engines.
  • The queue managers and queue-sharing groups must be accessible from all the messaging engines in the bus.
  • We cannot use the IBM MQ server for publish/subscribe messaging with IBM MQ.
  • IBM MQ for z/OS v6 or later, or IBM MQ (distributed platforms) v7 or later, is a prerequisite.
  • If we are using different nodes with IBM MQ for z/OS, depending on the number of nodes and your version of IBM MQ for z/OS, we might require the Client Attachment feature (CAF) on z/OS.
  • We must explicitly define all destinations.