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 ESB operates on messages that are in flight between interaction endpoints. Within WebSphere ESB, mediation flows process messages as SMOs.
WebSphere ESB 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 ESB. 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 ESB uses this information to convert messages into SMO objects of the specified type.