This section describes the messaging interfaces used by the
connector framework and the integration broker to transmit messages
and the information needed to process them.
Several distinct types of messages are exchanged within the
business integration system. Essential information needed to
identify the different types of messages, as well as process and
route them correctly, is stored in the message header and the
message descriptor of each message. Message flows you create for
your business integration system use the information presented
below to recognize and correctly manage messages they are called
upon to process.
The following types of messages are passed:
- Event delivery messages are sent by the connector framework to
the WebSphere message broker to notify of an event in the source
application.
- Request messages are exchanged between the connector framework
and the WebSphere message broker to convey a request for data.
- Response messages are exchanged between the connector framework
and WebSphere message broker to reply to a request for data.
- Administrative messages are exchanged between the connector
framework and WebSphere message broker to convey administrative
commands.
Messages exchanged between the connector framework and the
integration broker are formatted by the data handler, based on:
- The WireFormat standard property in the connector's
configuration file
- The XML schema detailing the message body format
- The content of the message: a business object or an
administrative message
- The origin and destination of the message.
Each message contains three components: a message descriptor
(MQMD), a message header (MQRFH2), and a message body.
The WebSphere MQ message descriptor (MQMD) contains the message
ID and includes information needed for processing the message.
The MQRFH2 message header carries JMS-specific data that is
associated with the message content. It can also carry additional
information that is not directly associated with JMS. The message
header contains the following folders:
- The <mcd> folders contains properties that describe the
"shape" or "format" of the message. For example, the Msd property
describes the format as being Text, Bytes, Stream, Map, Object, or
"Null".
- The <jms> folder is used to transport JMS header fields,
and JMS properties that cannot be fully expressed in the MQMD. This
folder is always present in the messages implemented using JMS,
which are sent by the connector framework. However, in the business
integration system, this folder is irrelevant and is omitted by the
integration broker when sending messages to the connector
framework.
- The <usr> folder is used to transport any
application-defined properties associated with the message. This
folder is only present if the application has set some
application-defined properties. In the business integration system,
this folder is used to send return status information in a response
message. The tables below identify the types of messages that
require this folder.
The message body is formatted as specified by the XML schema
specified for the message. In order for the data handler to find
and use the correct XML schema for formatting a message, the
following three names must be the same:
- The name of the XML schema stored in the connector's
repository
- The name of the XML schema imported into the WebSphere message
broker's message repository and saved as a message set
definition.
- The value of messagetype in the message's MQRFH2 message
header.
The message formats and the settings for particular properties
for the different types of messages exchanged by the connector
framework and the WebSphere message broker are listed in Appendix A, WebSphere MQ message
formats..
The WebSphere MQ queues that need to be defined and configured
for use with the connector are described below.
Separate sets of WebSphere MQ message queues are used for
transporting business object messages and administrative messages
between the connector framework and the WebSphere message broker.
You must define queues with the following properties:
- DeliveryQueue: Delivers event delivery messages from the
connector framework to the WebSphere message broker.
- RequestQueue: Delivers request messages from the
WebSphere message broker to the connector framework.
- FaultQueue: Delivers fault messages from the connector
framework to the WebSphere message broker. The connector framework
places a message on this queue when it is unable to place the
message on the reply-to queue.
- SynchronousRequestQueue: Delivers request messages that
require a synchronous response from the connector framework to the
WebSphere message broker. This queue is necessary only if the
connector uses synchronous execution.
- SynchronousResponseQueue: Delivers response messages
from the WebSphere message broker to the connector framework sent
in reply to a synchronous request. This queue is necessary only if
the connector uses synchronous execution.
- AdminInQueue: Delivers administrative messages from the
WebSphere message broker to the connector framework.
- AdminOutQueue: Delivers administrative messages from the
connector framework to the WebSphere message broker.
During connector configuration, you specify the name of each
queue as a standard property in the connector's configuration
file.
The connector uses a single queue manager to manage all of its
interactions with queues. The standard properties in the
connector's configuration file contain the queue manager
information needed by the connector at startup. The connector uses
this information to establish a connection to the queue manager it
will use to communicate with the WebSphere message broker.
The WebSphere business integration system supports several queue
managers and queue configurations. The connector can communicate
with the queue manager in any of the following modes:
- Bindings mode: The integration broker and the connector
communicate directly with the queue manager, without using a TCP/IP
connection. The queue manager and the connector must be on the same
machine and must use the same queue manager. This is the default
mode.
- Bindings mode with remote queue definitions: If the
integration broker and the connector are installed on separate
machines, with each machine running its own queue manager, the
connector and the integration broker can still communicate with
their respective queue managers using bindings mode but remote
queue definitions are also needed.
- Client mode: Communication occurs through a client
connection that uses TCP/IP as its underlying transport. If the
queue manager and the connector are on the different machines, the
connector is limited to using client mode.
To learn more about WebSphere MQ messages see WebSphere
MQ: Using Java. To learn more about WebSphere MQ queues, see
WebSphere MQ: Intercommunication and WebSphere
MQ: Script Command (MQSC) Reference.
