WebSphere

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 WebSphere Integration Developer.

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 runtime 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 unreferenced attachments, they are stored in SMO attachments elements. Unreferenced attachments are MIME parts included in a SOAP/HTTP message, the attachments are not defined in the WSDL portType.
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 ServiceMessageObject contains context (occurs once), headers (occurs once), body (occurs zero or one times), and attachments (occurs zero or many times).

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

How the runtime uses the SMO

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.


concept Concept topic

Terms of use | Feedback


Timestamp icon Last updated: 20 June 2010 00:39:51 BST (DRAFT)


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.wbit.help.medprim620.doc/concepts/cwesb_sca_smo.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).
iDoc on