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 call interface, or "bindings mode". This method is only
available when the application server is running in the same machine
or logical partition (LPAR) as WebSphere MQ.
- A TCP/IP communication link, or "client mode". This method
is generally less efficient than the call interface, but it is available
whether or not the application server is running in the same machine
or logical partition (LPAR) as WebSphere MQ.
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
Figure 2. Connecting to a queue sharing group when a queue
manager becomes unavailable