Service message objects (SMOs) are enhanced Service Data Objects (SDOs). SMO provides an abstraction layer for processing and manipulating messages exchanged between services.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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)