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:
- A call interface (often called "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 (sometimes called "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.
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.

