MQ MESSAGE FORMATS

Message formats

In this section, we introduce rgw MQ and Java Message Service (JMS) message

formats.

MQ messages must contain a message descriptor (MQMD) header. The MQMD

contains the control information that accompanies the application data when a

message travels between the sending and receiving applications. The MQMD

has several fields, including the following fields:

_ MsgId

The MsgId is the identifier of the message that is sent to the queue. The

application can supply a message identifier, or it can prompt the queue

manager to generate a unique one.

_ CorrelId

The correlation identifier is normally used to provide an application with some

means of matching a response with the request message. Usually the correlId

of the reply is equal to the MsgId of the request message.

_ ReplyToQ

In this field, you enter the name of the queue that is set by the sending

application. The response is put into this queue.

MQ messages can contain other types of headers, including MQRFH2, which

carries JMS-specific data that is associated with the message content. The

MQRFH2 Version 2 is an extensible header and can also carry additional

information that is not directly associated with JMS.

JMS message format

JMS messages contain a header, the properties, and body as shown in

Figure 4-2. Only the header is required. The properties and the body are

optional.

A JMS message header contains values that both clients and providers use to

identify and route messages. The header has several fields, including the

following fields:

_ JMSMessageID

The JMSMessageID is the identifier of the message that is sent to the queue

or topic.

_ JMSCorrelationID

The correlation identifier is normally used to provide an application with some

means of matching a response with the request message. Usually the

correlation ID of the reply is equal to the message ID of the request message.

_ JMSDestination

This field represents the queue or the topic to which the message is sent.

_ JMSReplyTo

This field contains the name of the queue where the response should be put.

It is set by the sending application.

JMS properties are used to support application-defined property values.

Properties provide an efficient mechanism to filter application-defined messages

by using message selectors.

JMS defines several message body types that cover the majority of messaging

styles that are currently in use. See Table 4-1 on page 55.

We also discuss imports, exports, and bindings. SCA applications use imports

with messaging bindings to send messages to messaging clients. These

applications use exports with messaging bindings to receive messages from

messaging clients.

We discuss the following SCA artifacts and their relationship to a JMS client:

_ Business objects

_ Interfaces

_ Imports, exports and their bindings

Business objects

Service Data Objects (SDOs) define the data flowing between SCA components.

WebSphere Process Server uses business objects, which are enhanced SDOs to

pass data between SCA components.

If the message that is used by the client is in XML format, the XML schema that

defines it is used as the business object. If this schema exists, it can be imported

into the business integration module. The imported XML schema appears under

Data Types in the module. If this schema does not already exist, a business

object can be created with attributes that mirror the XML format that is used by

the client.

Data bindings handle the transformation of data passed in native format from a

messaging system or enterprise information system (EIS) to an SDO in an SCA

application.

Interfaces

An interface represents the input and output of a messaging client application.

That is, the interface represents the interaction with the client.

An interface has operations that describe the messaging client application

operations. An operation can be a one-way operation, sending a message and

not expecting a response, or a request-response operation, sending a message

and expecting a returning message.

Imports, exports and bindings

A business object represents the message, and an interface represents the

interaction of the input and output of the messaging client.

But how is the data transferred between the client and these SCA artifacts?

Business objects and interfaces are found in a module, which is similar to a

project container. Imports and exports define a module’s external interfaces or

access points. The messaging client interacts with the business objects and

interfaces of an SCA application through the import and export components.

Import components identify services outside of a module that can be called from

within the module. When a message is put on a destination queue by the SCA

application, the associated messaging client processes the event.

With export components, SCA components can listen to requests from external

clients. When a message is put on a destination, the associated SCA export

processes the event invoking the targeted SCA component.

Binding information is required for import and export components to define the

transport to be used for sending messages. The available messaging bindings

include JMS, MQ, and MQ JMS bindings.

Data binding

To convert data that is external to WebSphere Process Server to and from data

objects, some transport bindings require a data binding to be specified. The data

binding translates between the data provided by the transport binding as part of

a message and a data object.

4.1.3 MQ binding

IBM WebSphere MQ is a popular middleware set of products that provide a

well-known set of messaging communications between applications, which can

themselves be on many dissimilar systems. An MQ binding provides a way to

communicate directly with WebSphere MQ using both exports (incoming) and

imports (outgoing). An MQ binding communicates with WebSphere MQ using

native MQ messages.

An MQ binding is new for WebSphere Process Server 6.0.2, and is designed to

provide a direct replacement for the WebSphere MQ Link functionality that is still

available as part of the WebSphere Application Server platform. It is more

straightforward to configure and is generally recommended over MQ Link. An MQ

binding also provides a convenient way to communicate with WebSphere

Message Broker via WebSphere MQ.

In the binding settings, receive and send destination names are specified. These

correspond to destinations on a WebSphere MQ queue manager. Such details

as the queue manager name and the host name for the queue manager must

also be specified.

In this section, we show how a WebSphere MQ message maps to SCA artifacts.

That is, we show how a message maps to a business object and how input and

output from a WebSphere MQ client maps to an interface’s operations.

MQ import and data bindings

Four MQ native body data bindings, which serialize between the SDO and the

MQ message body, are supplied with WebSphere Process Server. In addition,

you can use a user-supplied data binding.

Unstructured Text Message converts an SDO to and from a string. The SDO

is expected to be a JMSTextBody type of business object.

_ Unstructured Binary Message converts an SDO to and from a string. The

SDO is expected to be a JMSBytesBody type of business object.

_ Serialized as XML serializes SDO to XML or deserializes XML to SDO. The

SDO can be of any type.

_ Serialized Java Object serializes and deserializes an SDO to and from a Java

object. The SDO can be of any type.

MQ bindings versus MQ JMS or JMS bindings: Do not be confused by the

use of the JMSTextBody and JMSBytesBody business objects with the

“Unstructured Text Message” and “Unstructured Binary Message” bindings.

The MQ native bindings have no relationship with the MQ JMS or JMS

bindings. These business objects are simply reused for this purpose because

they have the same structure, which is a single string in the case of

JMSTextBody or a single hexBinary in the case of JMSBytesBody.

WebSphere Process Server provides complete support for the MQMD, MQRFH,

and MQRFH2 headers, providing interoperability with JMS and WebSphere

Message Broker. Partial support is provided for messages with a format that

begins with MQH, for example messages with a format for the form MQHxxxxx.

These headers are exposed as binary data in SCA.

Figure 4-5 illustrates the different MQ native data bindings, the MQ message

structure (generated from the those bindings), and the recommended message

domain (parsers) to be used by WebSphere Message Broker.

JMS bindings

The JMS bindings allow inbound JMS communication (via exports) and outbound

communication (via imports). The JMS bindings in WebSphere Process Server

support “plain” JMS messages, not SOAP. WebSphere Process Server is based

on WebSphere Application Server and gives you the following options for JMS

connectivity with WebSphere Message Broker:

_ The default messaging provider

This option is included in WebSphere Application Server. The transport

mechanism for this provider is the service integration bus within WebSphere

Application Server.

JMS import data bindings

Eight JMS body data bindings , which serialize between SDO and the JMS

message body, are supplied with WebSphere Process Server. Figure 4-14 shows

the different data bindings that are provided by WebSphere Integration

Developer.

WebSphere Integration Developer offers the following data bindings:

_ Serialized Business Object using JMSObjectMessage serializes (or

deserializes) the business object whose underlying implementation is an

SDO, using the standard Java serialization mechanism, and places it in a

JMS object message. It is typically only useful when communicating with

another JMS import or export that uses the same data binding.

_ Business Object XML Using JMS TextMessage serializes the business object

to and from XML and uses a JMS text message to communicate with the JMS

client. Your wrapped data objects must be a complex type. The objects cannot

be a simple type.

_ Simple JMS TextMessage Data Binding sends the JMSTextBody business

object in a TextMessage message body to the client. The message body type

is a String.

_ Simple JMS BytesMessage Data Binding sends the JMSBytesBody business

object in a BytesMessage message body to the client. The message body

type is a byte array.

_ Simple JMS MapMessage Data Binding sends the JMSMapBody business

object in a MapMessage message body to the client. The message body type

is a set of name/value pairs that can be addressed by name. The data type of

the value is a Java primitive.

_ Simple JMS StreamMessage Data Binding sends the JMSStreamBody

business object in a StreamMessage message body to the client. The

message body type is a stream of Java primitives.

_ Simple JMS ObjectMessage Data Binding sends the JMSObjectBody

business object in an ObjectMessage message body to the client. The

message body type is a serialized Java object.

_ Simple JMS Message Data Binding does not have a message body. It can be

used to notify the JMS client of an event or to send simple data in the

message headers or properties.

Web service bindings

Web service bindings allow the call-out of SOAP-based Web services (via

imports), as well as exposing SOAP-based Web services interfaces (via exports).

Both SOAP/HTTP and SOAP/JMS are supported.

Both the HTTP and JMS transport types are presented as one binding type in

WebSphere Integration Developer. However, when you generate a Web service

binding, you are asked which transport type you want to use. SOAP/HTTP is

more common than SOAP/JMS.

Because SOAP is well-defined and maps cleanly into the SCA and SDO model,

no requirement (or facility) is necessary to provide any form of data binding,

either for imports or exports. The Web service bindings support the well-known

encoding styles: document/literal, doc-lit-wrapped, RPC-literal, and

RPC-encoded.