22 - service message objects

8/3/2019 22 - Service Message Objects

1/26

Copyright IBM Corporation 2006

Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 4.0.3

Service message objects


2/26


Unit objectives

After completing this unit, you should be able to:

Describe the role of service message objects within

mediations

Describe the structure of service message objects Describe the various nodes involved in a message flow

Explain the different approaches to manipulating the service

message objects structure


3/26


What is a service message object (SMO)?

Mediation flows operate on messages between endpoints There is variability between different messages

Protocol over which the message is sent (such as JMS or SOAP) Interface, operation, input types and output types

Mediation primitives need to be able to operate on the messages A common representation of the message is needed to enable this

Service message objects provide the common

representation of a message SMO uses Service Data Object (SDO) to represent messages All SMOs have the same basic structure as defined by the schema

Three major sections:

Body Headers Context

All information in the SMO is accessed as an SDO DataObject Using XPath

Using the generic DataObject APIs Using SMO specific APIs which are aware of the SMO schema


4/26 Copyright IBM Corporation 2006

Mediation flow

SMO

SMO

SMO

SMO

SMO

SMO


5/26


6/26 Copyright IBM Corporation 2006

SMO structure body

The body contains the payload of the message Payload is the application data flowing in the message

It identifies the operation and either its inputs, outputs or faults

Operation is defined in WSDL using the Interface editor

Inputs, outputs, and faults can be simple types or XSD defined types XSD defined types are created using the Business Object editor

Operation Definition

Business Object Definitions

Body inSMO


7/26


SMO structure headers

The headers include: SMOHeader

Information about the message

(message identifier, SMO version).

An SMO header is always present.

JMSHeader Used when there is a JMS import or export binding.

SOAPHeader Used when there is a web services import or export

binding.

SOAPFaultInfo Contains information about SOAP faults.

properties[ ] Arbitrary list of name value pairs

(for example, JMS user properties).


8/26


SMO structure context

The context includes the correlation and transient context

Both of these are: Used to pass application data between mediation primitives

An XSD defined data object (for example, defined with Business Object

Editor) Specified on the mediation flows Input node properties

Correlation context maintains data across a request/response flow

Transient context maintains data only during one direction (request or

response) However, same data object definition used for both the request and response

Context in SMOBusiness Object Definition

Specified as TransientContext in Input Nodes

Properties

No Correlation

Context Specified


9/26


SMO structure context failinfo

The context also includes the failInfo Contains failure information.

Added to the SMO when a Fail terminal flow occurs.

The information provided includes: failureString (describes the failure).

origin (mediation primitive in which failure occurred).

invocationPath (the flow taken through the mediation).

predecessor (previous failure).

Path taken through flow

Failing Primitive Error Message


10/26


Message types

Message type defines the content of the SMObody.

Message type is determinedby: Interface Operation Message category

Specifies if the operations Input(s),Output(s) or Fault(s) are to be included

Naming convention applied to message types: Input RequestMsg Output ResponseMsg

Fault _Msg

- additional qualifier sometimes generated


11/26


Message type for nodes are defined: By Interface and References on the Mediation Flow Component

These define the service requestor and service provider interfaces

And by the operation connections on the Mediation Flow

Mediation flow definition defining the nodes

Service RequestorInterface

Service ProvidersInterfaces

getCustomerInformationOperation Connection

setCustomerInformationOperation Connection

Service RequestorInterface

and all of its definedoperations

Service ProvidersInterfaces and allof their defined

operations


12/26


Mediation flow definition request flow nodes

Input node RequestMsg Starting point of the request flow receiving the service request A flow can have only one input node

Callout node RequestMsg End point of the request flow sending the request to the service provider There is one callout node for each target operation

Input response node ResponseMsg Enables mediation flow to reply to requestor without calling a service provider

Input fault node _Msg End point of the request flow returning a WSDL fault message to the requestor There is one input terminal on the fault node for each fault defined for the

operation

Input Node

Callout Nodes

Input ResponseNode

Input FaultNode

RequestFlow

Terminals DefineMessage Type


13/26


Mediation flow definition response flow nodes

Callout response node ResponseMsg

Starting point of the response flow receiving the response from the service provider

There is one callout response node for each target operation

Callout fault node _Msg

Starting point of the response flow receiving a WSDL fault message from the provider

There is one output terminal on the callout fault node for each fault defined for the operation

Input response node ResponseMsg End point of the response flow returning a response to the original requestor

A flow can have only one input response node

Input fault node _Msg

End point of the response flow returning a WSDL fault message to the original requestor

There is one input terminal on the input fault node for each fault defined for the source operation

CalloutResponse Nodes

Input ResponseNode

Input FaultNode

ResponseFlow

Terminals DefineMessage Type

CalloutFault Nodes


14/26


Mediation flow definition connecting the nodes

Mediation flows are defined by: Adding mediation primitives to the flow for message processing

Mediation primitives have input, output and fault terminals

Just like nodes, specific SMO types are associated with each of the primitives

terminals Wiring a flow path to define the flow logic

Path will connect the left side nodes output terminals to right side nodes input

terminals

The path is wired using the mediation primitives input, output and fail terminals

Two terminals must be of the same SMO type to be wired together XSLT or Custom primitives can be used to modify SMO type when needed

Filter Choose target service

XSLT Modify SMO for callout

Example: Two target services, one with different interface, fault handled

XSLT Modify SMO for fault

Fail 2nd error handling fault

Callout withsame SMO type

Callout withdifferent

SMO type

Input Fault

Input

Input Response


15/26


Manipulating SMOs

Three ways to access and manipulate SMOs XPath 1.0 expressions.

Are the primary mechanism for accessing the SMO.

Used in some form by all of the mediation primitives. Identify elements to read, update an process conditional

expressions.

XSL Stylesheets Used by the XSLT mediation primitive. Normally used to modify SMO type within a flow.

Can also be used to manipulate SMO content without changing

message types.

Java code Used by the Custom Mediation primitive.

Generic DataObject APIs.

SMO APIs. Can access and update content and can also modify SMO type.


16/26


Manipulating SMOs XPath

All mediation primitives use XPath in some form.

Root property Used to specify what part of the SMO is visible to the primitive.

Values selected from a drop down, are normally: /

/body

/context

/headers

Some instances of Root are more restrictive or allow custom XPath.

Other properties using XPath. Specified using the XPath Expression Builder. Builder accessed using:

Custom XPath button

button from a table cell

Select a target expression, optionally add a condition, or override.


17/26


Manipulating SMOs XPath expression builder

Use the Schema Viewer tonavigate SMO to the desired

XPath location

Selected location will bedisplayed in the

XPath Location field

Optionally, Condition fieldcan be used to definea conditional expression

Full XPath Expression

field contains thecomplete expression

Override lets youmanually edit the

generated expression


18/26


Manipulating SMOs XPath expression builder

Value defined usingSchema Viewer

Added condition

OverrideChanged condition to

< rather than =


19/26


Manipulating SMOs XSL stylesheets

XSLT primitives process XSL stylesheets at runtime.

The XSL stylesheet can be:

Generated from a map created in the XML Mapping Editor Edited directly with the XSL Editor

Typical usage is for modification of SMO type in a flow. When Input and Callout nodes have different message types.

To reply using the Input Response node in a request flow.

To reply with a fault using the Input Fault node to report a flow error.

Used to manipulate SMO content without changing type. Use XSLT Functions (such as string manipulation or numeric

computation).

Logical processing with XSL Choose/Otherwise statements.


20/26


Manipulating SMOs XML Mapping Editor

Bottom panel shows currently defined mappings.Top panel used to define mappings.

Drag elements from source to target to define a move

Pop-up menu on target element provides additional choicesXSLT is quite powerful and therefore so is the XML Mapping

Editor.

Toolbar providesvarious

selection options

Drag/drop tocreate move

Right click,select from menu,

follow dialogsto define function

Example: Define map to transform between input and callout operations


21/26


Manipulating SMOs resulting XSL stylesheet

XML Mapping Editorand the resultingXSL stylesheet


22/26


Manipulating SMOs Java code

Using Custom mediation primitives you can write Java code to manipulateSMOs

Custom Mediation operation:

Is passed the SMO as a DataObject Return the SMO as a DataObject

Input/Output SMO types must match terminals of Custom Mediation primitive

DataObject API (commonj.sdo.DataObject) Defined by the Service Data Object (SDO) specification

Provides a dynamic loosely typed interface to access an SMO

Javadoc available from IBM developerWorks

ServiceMessageObject API Provides strongly typed interface for well defined portion of SMO

Everything except the contents of the body, transient context and correlation context

Javadoc available from the Information Center


23/26


Manipulating SMOs Java code examples

Compare DataObject API usage to SMO API usage Code to access the MessageUUID field contained in the SMOHeader

Using DataObject with full path

Using DataObject and traversing down through each property

Using the SMO strongly typed APIs

Discovery of coding errors Loosely typed DataObject errors such as misspelling a property name are not

discovered until runtime Strongly typed SMO errors are caught at compile time


24/26


SMO coding example dump SMO contents

Operation called as Custom Mediation receiving the SMO

Operation to recursively dump a DataObject Print theDataObject type

Get list ofcontained properties

Iterate throughthe properties

Print theproperty name

If property isa DataObject

recursively dump itotherwise

print the property

type and value


25/26


SMO coding example dump SMO contents

Start of Dump

End of Dump

/context

/headers

/body


26/26


Unit summary

Having completed this unit, you should be able to: Describe the role of service message objects within

mediations

Describe the structure of service message objects Describe the various nodes involved in a message flow

Explain the different approaches to manipulating the service

message objects structure

22 - service message objects

Documents