Advantages provided by a WebSphere MQ server over a WebSphere MQ link

You can configure a service integration queue-type destination to add messages directly onto a WebSphere® MQ queue or to retrieve messages directly from that queue or both. Service integration does this (for WebSphere MQ for z/OS®) by communicating directly with the WebSphere MQ queue manager or queue sharing group where the queue is located.

Service integration communicates directly with a WebSphere MQ network using either of the following methods:

Before considering other details, be aware that WebSphere MQ link can be used to connect to any supported version or release of WebSphere MQ, on any platform, but with WebSphere Application Server Version 6.1, you can only define destinations on a WebSphere MQ server using WebSphere MQ for z/OS Version 6 or later.

Sending messages to WebSphere MQ

Using a WebSphere MQ link, you define a WebSphere MQ queue as a service integration remote or alias destination. When a service integration application sends a message to that destination, service integration transmits that message to the WebSphere MQ network over the WebSphere MQ link. Alternatively, you can configure a service integration queue-type destination to add messages directly onto a WebSphere MQ queue. When a service integration application sends a message to that destination, service integration establishes a connection to the WebSphere MQ queue manager or queue sharing group where the queue is located and requests WebSphere MQ to place the message directly on the queue.

There are the following important consequences:
  1. With foreign or alias destinations, all messages to the WebSphere MQ network travel over the same connection (WebSphere MQ link). With destinations defined on a WebSphere MQ server, each applications uses its own connection to send messages. In general, sharing the same network connection uses the network more efficiently.
  2. With foreign or alias destinations, all messages to the WebSphere MQ network travel over the TCP/IP network. With destinations defined on a WebSphere MQ server, service integration can use a call interface ("bindings mode"). In general, using a call interface is more efficient than using a TCP/IP network connection.
  3. With foreign or alias destinations, service integration uses "store and forward" messaging. When the WebSphere MQ network is temporarily unavailable, service integration stores messages in the service integration bus for later transmission to WebSphere MQ when WebSphere MQ becomes available. For some applications, this can be an advantage because the application can proceed while the WebSphere MQ network is temporarily unavailable.
  4. With foreign or alias destinations, depending on the configuration of your service integration bus and the WebSphere MQ network, the message might need to pass through several intermediate messaging engines or queue managers before it arrives at the queue. For example, service integration might need to pass the message from the application server where the messaging engine for the application is running, to a different application server where the gateway messaging engine is running. Then the gateway queue manager might need to pass the message to a different queue manager where the queue is located.
  5. With destinations defined on a WebSphere MQ server, service integration passes the message directly from the application server where the messaging engine for the application is running to the WebSphere MQ queue manager where the queue is located. Depending on your particular configuration, this can give better performance.
  6. With destinations defined on a WebSphere MQ server, service integration uses WebSphere MQ to put the messages directly on the WebSphere MQ queue. When the WebSphere MQ queue manager or queue sharing group is temporarily unavailable, this fails. For some applications, this can be an advantage because the application needs to "know" that the message has been delivered before it can proceed.

Receiving messages from WebSphere MQ

Using a WebSphere MQ link, you define a WebSphere MQ queue as a service integration remote or alias destination. A service integration application cannot receive messages from that destination. Instead, the WebSphere MQ network must be configured or reconfigured to route messages over the WebSphere MQ link to a destination within the service integration bus.

In contrast, a service integration destination defined on a WebSphere MQ server is within the service integration bus, so a service integration application can both send messages to that destination and receive messages from it.

Mediating a destination

Defining a service integration destination on a WebSphere MQ server allows the destination to be mediated in a number of different ways including, for example, using a message broker flow to act as a mediation on a service integration destination. This is discussed in WebSphere MQ server and mediated exchange scenarios.

Exploiting WebSphere MQ for z/OS shared queues

WebSphere MQ for z/OS queue sharing groups provide significant benefits through the use of shared queues. Multiple applications can send messages to and receive messages from the same shared queue using different queue managers in the same queue sharing group. This gives the following advantages:
  • The different applications (or different instances of the same application) compete to process messages on the same queue. An instance which is able to process messages more quickly -- perhaps because the instance is running on a more powerful or less heavily loaded processor -- automatically processes a higher proportion of the messages on the queue, giving better utilization of the available resources and better overall response times. This is called "pull workload balancing".
  • If one queue manager in a queue sharing group fails, applications can connect to a different queue manager and continue using the same shared queue. This provides superior availability for your applications. A special feature of queue sharing groups, called "peer level recovery", handles the cases where an application receives a message from a shared queue but the queue manager fails before processing of the message is complete. Provided that the application is transactional, another queue manager in the same queue sharing group can return the message to the shared queue so that it can be processed without waiting for the failed queue manager to recover. Peer level recovery further enhances the availability of your applications.
  • Queue sharing groups also allow service integration (or WebSphere MQ applications) to connect to the queue sharing group using a single network address for the collection of queue managers in the queue sharing group. The connection is automatically redirected to a suitable queue manager in the queue sharing group, based on which queue managers are available, and which is able to provide the best response time. This feature enhances both the availability and the performance of your application.

You can provide these benefits to your service integration applications by defining service integration destinations on shared queues owned by a WebSphere MQ server that is a queue sharing group. The first of the following two diagrams shows a service integration messaging engine connecting to one queue manager (QM1) in a queue sharing group. The connection allows a service integration application to consume messages from a shared queue. Other service integration applications on the same or a different application server can use different connections (to the same or different queue managers -- QM2 or QM3 -- in the same queue sharing group) to consume messages from the same shared queue.

The second diagram shows that when a queue manager (QM1) in the queue sharing group is temporarily unavailable, service integration can connect to a different queue manager (QM2), allowing applications to continue processing messages from the queue.


A service integration messaging engine is pulling messages from a queue manager QM1 which is part of a queue sharing group on a WebSphere MQ network.

Queue manager QM1 becomes unavailable and fails over to queue manager QM2 in the same queue sharing group. The messaging engine is still able to pull messages without interruption.



Related concepts
Learning about interoperating with WebSphere MQ using a WebSphere MQ server
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 12:02:36 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-zos&topic=cjfp0012_
File name: cjfp0012_.html