Differences between a WebSphere MQ server and a WebSphere MQ link

With a WebSphere® MQ link, you define a WebSphere MQ queue manager or queue-sharing group as a foreign bus. With a WebSphere MQ server, you define a WebSphere MQ queue manager or queue-sharing group as a member of the local service integration bus, and define queue-type destinations for each relevant WebSphere MQ queue.

When a WebSphere Application Server application sends a message to one of the queue-type destinations, 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. For a queue-type destination, service integration can connect to the WebSphere MQ network using either of the following methods:
A WebSphere MQ link and a WebSphere MQ server have the following key differences:
Support in WebSphere MQ
  • With a WebSphere MQ link, you can interoperate with any supported version or release of WebSphere MQ, on any platform.
  • With a WebSphere MQ server, you can only interoperate with WebSphere MQ for z/OS® Version 6 or later, or WebSphere MQ Version 7 or later.
Sharing connections
  • With a WebSphere MQ link, all messages to the WebSphere MQ network travel over the same connection.
  • With a WebSphere MQ server, each application uses its own connection to send messages.
In general, sharing the same network connection uses the network more efficiently.
Connection mode
  • With a WebSphere MQ link, all messages to the WebSphere MQ network travel over the TCP/IP network, regardless of where WebSphere MQ is running.
  • With a WebSphere MQ server, service integration can use a call interface ("bindings mode") if WebSphere MQ is running in the same machine or logical partition (LPAR).
In general, using a call interface is more efficient than using a TCP/IP network connection.
Number of intermediaries
  • With a WebSphere MQ link, 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.
  • With 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, a lower number of intermediaries can give better performance.
Action when a WebSphere MQ queue is temporarily unavailable
  • With a WebSphere MQ link, 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.
  • With 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, "store and forward" messaging is an advantage because the application can proceed while the WebSphere MQ network is temporarily unavailable. However, other applications need to "know" that the message has been delivered before they can proceed, so they need to be notified of a queue failure.
Receiving messages from WebSphere MQ
  • With a WebSphere MQ link, you define a WebSphere MQ queue manager or queue-sharing group as a foreign bus. A WebSphere Application Server application cannot receive messages from a destination in a foreign bus. If you want messages to pass from WebSphere MQ to WebSphere Application Server applications over a WebSphere MQ link, WebSphere MQ applications must send the messages to a suitable destination in the service integration bus used by the WebSphere Application Server applications.
  • With a WebSphere MQ server, you define a WebSphere MQ queue as a queue-type destination, and a WebSphere Application Server application can both send messages to that destination and receive messages from it.
Publish/subscribe messaging
  • With a WebSphere MQ link, you can set up a publish/subscribe bridge, so that WebSphere Application Server applications and WebSphere MQ applications can publish or subscribe to selected topics that exist in both the WebSphere MQ environment and the WebSphere Application Server environment.
  • With a WebSphere MQ server, publish/subscribe messaging is not supported. A WebSphere MQ server provides connections directly to WebSphere MQ queues for point-to-point messaging, and a topic for publish/subscribe messaging cannot be represented as a WebSphere MQ server.
Mediations
  • With a WebSphere MQ link, mediations are not supported.
  • With a WebSphere MQ server, mediations are supported. You can mediate a destination in a number of different ways, for example, by using a message broker flow to act as a mediation on a service integration destination. For more information about mediation scenarios, see WebSphere MQ server and mediated exchange scenarios

Exploiting WebSphere MQ for z/OS shared queues

Because a WebSphere MQ server enables WebSphere Application Server applications to receive messages from WebSphere MQ queues, you can gain benefits by using a WebSphere MQ server to connect to a WebSphere MQ for z/OS queue sharing group. A WebSphere MQ link can connect WebSphere Application Server applications to a queue sharing group, but the applications cannot realize the full benefits of shared queues because they cannot consume messages from them.

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 by 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 by 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.

Figure 1. Connecting to a queue manager in a queue sharing group
In this figure, a service integration messaging engine is pulling messages from a queue manager QM1 which is part of a queue sharing group with two other queue managers on a WebSphere MQ network.
Figure 2. Connecting to a queue sharing group when a queue manager becomes unavailable
In this figure, the 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.
Concept topic Concept topic    

Terms of Use | Feedback

Last updatedLast updated: Sep 19, 2011 6:15:55 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-express-dist&topic=cjfp0012_
File name: cjfp0012_.html