Service message objects

Service message objects (SMOs) are enhanced Service Data Objects (SDOs). SMO provides an abstraction layer for processing and manipulating messages exchanged between services.

SMO model

The SMO model is a pattern for using SDO DataObjects to represent messages. The SMO contains a representation of the following groups of data:
  • The business payload of the message. The payload is the application data exchanged between service endpoints.
  • Header information associated with the message. For example, Java Message Service (JMS) headers if a message has been conveyed using the JMS API, or MQ headers if the messages has come from WebSphere MQ.
  • Context information (data other than the message payload).

All of this information is accessed as SDO DataObjects, and there is a schema declaration that specifies the overall structure of the SMO. The schema is generated by the WebSphere Integration Developer.

All SMOs have the same basic structure. The structure consists of a root data object called a ServiceMessageObject, which contains other data objects representing header, body and context data. The SMO body contains the message payload. The headers contain information that originates from a specific import or export binding. For example, a JMS Binding.

SMO provides an interface to access and modify message headers and message payloads. SMO can represent the logical content of many different types of message.

Figure 1. Overview of SMO structure. The headers, context and body of a ServiceMessageObjectThe headers, context and body of a ServiceMessageObject

WebSphere Process Server and SMO

WebSphere Process Server operates on messages that are in flight between interaction endpoints. Within WebSphere Process Server, mediation flows process messages as SMOs.

To provide dynamic routing, the interaction endpoints can be looked up using Websphere Service Registry and Repository (WSRR): the result of the WSRR query is stored in the SMO.

Messages can come from a number of sources, so the SMO has to be able carry different kinds of message header. The kinds of message headers handled by WebSphere Process Server are:
  • Web Services message headers.
  • Service Component Architecture (SCA) message headers.
  • Java Message Service (JMS) message headers.
  • WebSphere Adapter message headers.
  • WebSphere MQ message headers

WebSphere Process Server SMO runtime

WebSphere Process Server creates SMO objects, which are then available to mediation flows.

Some of the SMO objects created by the runtime are implemented by classes supplied by the runtime. For example, the ServiceMessageObject class is supplied by WebSphere Process Server. Some of the SMO header classes are also supplied by the runtime. Other SMO objects created by the runtime are implemented by classes created by a developer.

When creating mediation flows, WebSphere Integration Developer specifies the type of message body for each terminal (input, output or fail) and, optionally, the type of context information. WebSphere Process Server uses this information to convert messages into SMO objects of the specified type.

MQ header data in the SMO

The SMO structure stores MQ header information at /headers/MQHeader. This contains three elements:
  • md, which represents the message's MQ message descriptor (MQMD)
  • control, which contains format information relating to the message body
  • header, which optionally repeats, and represents header structures contained within the WebSphere MQ message
The md elements contains all the fields from the MQMD definition (see the WebSphere MQ documentation), except for certain control fields which carry no useful data (such as StrucId and Version) and message format fields (Encoding, CodedCharSetId and Format).

The control element carries the Encoding, CodedCharSetId and Format fields, which describe the message body. If the WebSphere MQ message contains any message headers (for example, MQRFH2), the Encoding, CodedCharSetId and Format fields that describe the header are carried within the header element.

A header element represents a message header, such as an MQRFH2. Each header is one of the following:
  • A header explicitly modelled in the SMO: an RFH version 1 or 2
  • A header following the standard MQ header structure, but not explicitly modeled. These have MQ format identifiers beginning MQH. These headers are represented as unstructured binary data in the SMO.
  • A header handled by a user-supplied MQ header data binding.

The header element contains Encoding, CodedCharSetId and Format fields, which describe the header. The Format field, in particular, must be set correctly (for example, MQHRF2 for an MQRFH2 header); and the CodedCharSetId and Encoding fields are important for opaque data. When rendered as a WebSphere MQ message, this format information is written into the previous MQ header (or into the MQMD if there is no previous header).

Header subelements

The header element also contains subelements (rfh and rfh2) for each of the modeled headers; a subelement (opaque) for unmodeled standard MQ headers; and a subelement (value) for user-supplied MQ headers. Precisely one of these four elements must be set: it is an error to have more than one of these set in any header element. The value subelement stores the structure used by the user-supplied header data binding; the other three elements (rfh, rfh2 and opaque) are described in the following sections.

RFH headers

A WebSphere MQ RFH header contains a string of name-value pairs, where each name and value is simply a text string. This is represented, in SMO, as a repeating property element, containing a name and a value element.

RFH2 headers

A WebSphere MQ RFH2 header contains zero or more named folders, each of which contains a sequence of properties and groups. A property has a name, optional type and value (all represented as string). A group has a name and itself contains a sequence of properties and groups. The SMO representation of an RFH2 header also contains a NameValueCCSID element, which determines the CCSID used to encode the folders in the WebSphere MQ message.

Unmodeled standard WebSphere MQ headers

The opaque element represents any WebSphere MQ header of the standard structure. Fields common to all such headers (StrucId, Version and Flags) are represented as elements. There is also a data element which contains the unmodeled portion of the header as hexBinary data. When using the opaque element, it is usually important to keep the correct Encoding and CodedCharSetId values associated with the header to avoid data corruption.

Types for WebSphere MQ header information

The WebSphere MQ header fields are defined using the same set of types used by WebSphere MQ itself. MQLONG fields are represented as int; MQBYTEnn fields as hexBinary data limited to nn in length; and MQCHARnn fields as string data limited to nn characters in length.


Last updated: Thu 26 Oct 2006 10:30:05

(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)