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..
In addition, the XML data handler makes the following assumptions about an
XML document:
- The XML document is well formed.
- The XML document is compliant with SAX parser requirements. Note
that the default parser used by the XML data handler requires that an XML
document include an XML declaration.
- The structure of an XML document must match the structure of its
corresponding business object. In addition, the order of the elements
in the document must match the order of the attributes in the business
object.
-
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.
