Service message objects

Service message objects (SMOs) provide an abstraction layer for processing and manipulating messages exchanged between services.

SMO model

Mediation primitives process messages as SMOs. SMOs are enhanced Service Data Objects (SDOs), and the SMO model is a pattern for using SDO DataObjects to represent messages. The SMO contains a representation of the following groups of data:

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.
The body of the message: the message payload. The message payload is the application data exchanged between service endpoints.
Message attachments.
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 IBM® Integration Designer.

SMO content

All SMOs have the same basic structure. The structure consists of a root data object called a ServiceMessageObject, which contains other data objects representing the header, body, attachments, and context data. The precise structure of the headers, body, and context depends on how you define the mediation flow at integration development. The mediation flow is used at run time to mediate between services.

The SMO headers contain information that originates from a specific export or import binding (a binding specifies the message format and protocol details). 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 are:

Web services message headers.
Service Component Architecture (SCA) message headers.
Java Message Service (JMS) message headers.
WebSphere MQ message headers.
WebSphere Adapters message headers.

Typically, the structure of the SMO body, which holds the application data, is determined by the Web Services Description Language (WSDL) message that you specify when you configure a mediation flow.

If a SOAP message has attachments, they are stored or referred to in SMO attachments elements.

Referenced attachments, which are defined in a WSDL port type as parts within an input or output message and which have a binary type, do not have their data stored in the SMO; instead, the path to the message body element that holds the data is contained in the bodyPath element.
Unreferenced attachments, which are not defined in a WSDL port type, have their data placed in the data element in the SMO, and have no bodyPath element.

In either case, the attachments element also holds the contentID and contentType for each attachment.

Note: You can only send or receive SOAP attachments if the module binding is one of the following types: web service binding SOAP 1.1/HTTP using JAX-WS, web service binding SOAP 1.2/HTTP using JAX-WS, or SCA binding.

SMO context objects are either user-defined or system-defined. You can use user-defined context objects to store a property that mediation primitives can use later in the flow. You define the structure of a user-defined context object in a business object, and use the business object in the input node of the request flow. The correlation context, transient context and shared context are user-defined context objects.

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

The SMO provides an interface to access and modify message headers, message payloads, message attachments, and message context.

How the runtime environment uses the SMO

The runtime environment operates on messages that are in flight between interaction endpoints. The runtime environment creates SMO objects, which a mediation flow uses to process a message.

When you create mediation flows, IBM Integration Designer specifies the type of message body for each terminal (input, output or fail) and, optionally, the type of context information. The runtime environment uses this information to convert messages into SMO objects of the specified type.

To provide dynamic routing, the interaction endpoints can be looked up using WebSphere Service Registry and Repository (WSRR), or a database. The result of the WSRR query, or database lookup, can be stored at a particular location in the SMO, from where the runtime environment will take the dynamic endpoint.