Service message objects (SMOs) provide 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 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 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 runtime to mediate between services.
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.
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.
The SMO provides an interface to access and modify message headers, message payloads, message attachments, and message context.
The runtime operates on messages that are in flight between interaction endpoints. The runtime creates SMO objects, which a mediation flow uses to process a message.
When you create 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. The runtime 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 will take the dynamic endpoint.