This topic describes the concept of point-to-point messaging
with WebSphere® MQ.
The WebSphere MQ link,
defined on a messaging engine in the service integration bus, describes
the attributes required to connect to, and send or receive messages
to or from, a WebSphere MQ
queue manager that acts as a gateway to other queue managers.
Point-to-point messaging might be:
- A request from WebSphere Application Server to WebSphere MQ, optionally followed
by a WebSphere MQ reply.
- A request from a WebSphere MQ
network, optionally followed by a WebSphere Application Server reply.
The following figure shows the flow of point-to-point messages
across the WebSphere MQ
link. In this example, a service integration bus in WebSphere Application
Server, is connected to a foreign bus that represents a WebSphere
MQ network. The service integration bus contains a gateway messaging
engine with a WebSphere MQ link, which has an MQLinkSender and an
MQLinkReceiver. The foreign bus contains a gateway queue manager that
has WebSphere MQ channels: Receiver and Sender. Two channel connections
are shown; one runs from the MQLinkSender on the WebSphere MQ link
to the Receiver in the foreign bus that represents WebSphere MQ, and
the other runs from the Sender in the foreign bus to the MQLinkReceiver
on the WebSphere MQ link.
Figure 1. Exchanging messages between WebSphere MQ link sender and
receiver channels, and a gateway queue manager with receiver and sender
channels.
See Request-reply across the WebSphere MQ link for
more information about these reply messages transmitted across the WebSphere MQ link.
Point-to-point messaging may also include:
The following figure shows how messages can be exchanged between
applications and messaging engines that are on the same bus, and between
the WebSphere MQ link
and queue managers connected to the gateway queue manager in the WebSphere MQ network. In this
example, a service integration bus in WebSphere Application Server
is connected to a foreign bus that represents a WebSphere MQ network.
The service integration bus contains a gateway messaging engine that
has a WebSphere MQ link. Messaging engine 2 and Messaging engine 3
are on the same bus and connect to the gateway messaging engine. Messaging
engine 2 and Messaging engine 3 each connect to a JMS application
outside the bus. The foreign bus contains a gateway queue manager
with WebSphere MQ channels. Queue manager 2 and Queue manager 3 are
in the foreign bus and connect to the gateway queue manager. There
is a two-way connection between the WebSphere MQ link on the service
integration bus, and the WebSphere MQ channels on the gateway queue
manager in the WebSphere MQ network.
Figure 2. Exchanging messages
between messaging engines on a bus that has a WebSphere MQ link that is connected to
a gateway queue manager on a foreign bus.
There are a number of differences between WebSphere Application Server messaging
technology and WebSphere MQ
messaging technology:
- A WebSphere MQ message
has two fields that can be set to request a reply: ReplyToQ and ReplyToQMGR.
When
a message on a WebSphere MQ
queue is processed by an application, the application copies these
two fields into the ObjectName and ObjectQMName fields of the object
descriptor specified on an MQOPEN call, and subsequently puts a reply
to the target reply-to queue.
The reply-to queue may be a predefined
queue or a dynamically created temporary or permanent queue. If it
is a dynamic queue, then it may have a unique name that is generated
by WebSphere MQ.
WebSphere Application Server messaging
technology has the same concept of a temporary queue for replies and
will generate a queue name of up to 48 characters to comply with the
queue-name length limitation for WebSphere MQ.
- In WebSphere Application Server messaging
technology, a programmer can set a single reply location, which automatically
generates a reply path for that message. The reply message goes through
the reply path (reverse routing path) in reverse. If there are transformations
to be performed, retracing the reverse routing path ensures they happen
in the correct (reverse) order. To make it possible for replies from WebSphere MQ to follow a reverse
routing path, the WebSphere MQ
link overcomes the WebSphere MQ
limitation of only two reply-to fields by putting the extra reverse
routing path information in the sib folder of the MQRFH2 header.
- A
destination context field called _MQRFH2Allowed can be configured
on an alias or foreign destination to indicate that an MQRFH2 header
is added to messages that are produced using alias or foreign destinations.
For more information about setting the destination context, see Specifying whether messages are forwarded to WebSphere MQ as JMS messages. The MQRFH2 header
contains fields unique to WebSphere Application Server. For details
of the additional fields see Mapping of additional MQRFH2 header fields in service integration.
- You can use alias destinations to overcome the differences in
allowable name length between WebSphere MQ
queues and WebSphere Application Server destination
names.
- The WebSphere MQ link
communicates with WebSphere MQ
using the WebSphere MQ
formats and protocols, and supports without change, today's WebSphere MQ queue managers.
- WebSphere MQ channel
or conversion exits (for example, for data conversion) are not supported
by the WebSphere MQ link.
- Messages sent from a WebSphere Application Server to a WebSphere MQ network may have
properties of the message set to indicate the delivery options. However,
if the message does not have these properties set, the sending bus
will use the defaults associated with the foreign bus (that is, the WebSphere MQ queue manager
that is the gateway to the WebSphere MQ
network). The defaults offer the most protection. You can reduce these
values if you wish.