The primary function of a mediation flow is to operate on a message between endpoints, where a service requestor and a service provider are those endpoints. However, this presents a problem. The first point is that a message can take on many different forms because the protocol used to send a message, whether JMS or Web services, can vary. Also, each message is different depending upon the interface and operation associated with the message and whether this is the request side or response side of the interaction between the requestor and provider.
The next point to understand is that within the mediation flow, mediation primitives are used to operate on the message. Mediation primitives examine and update the message contents and therefore must understand what is contained in the message. The solution is to provide mediation primitives with some kind of a common representation of a message, and that is what a Service Message Object does. SMOs provide a common representation of a message that accounts for differing protocols and differing interfaces, operations, and parameters that the message represents. SMOs are built using Service Data Object (SDO) technology. SDO uses a schema that describes the basic structure of an SMO which is composed of three major sections.
The body of the message represents the specific interface, operation, and parameters relevant to this message. The headers section of the message represents information about the protocol over which the message was sent. The context section represents data that is important to the internal logic of the flow itself. Each of these major sections of the SMO is examined in more detail in subsequent slides. The data within an SMO is accessed using SDO, specifically the SDO DataObject, which enables access using XPath, the generic DataObject APIs, and some SMO-specific APIs that are aware of the SMO schema.
The service requestor and service provider interact with the bus through the bindings for the exports and imports of the mediation service module. The data representing the message depends on the binding used for exports and imports. If the primitives in the mediation flow component had to support the data representation for all the various bindings, it would be difficult to implement primitives. For this reason, the first thing the runtime does is that it converts the binding-specific data into common data structure, called Service Message Objects (SMO).
The SMO interface extends the DataObject interface, which is defined by the Service Data Object (SDO), similar to other business objects used in WebSphere Process Server. SMO includes the message headers, message data (payload) and context information and provides an interface to access and modify the SMO data, including headers, payload, and context information. In addition, the SDO data can be accessed using the XPath reference mechanism. The mediation module input contains binding-specific data representation. The mediation module output import binding dictates the data representation that must be sent to the output message. As a result, there is a lack of consistency in data representation and if the mediation flow primitives had to handle all the different data representation, it would become a huge challenge. To solve this problem, the data from binding-specific interaction is converted to a common data structure called the Service Message Object (SMO).
If the mediation primitives in a message flow require a temporary area to save data for other primitives down the message flow or need data set in the request flow to be available during the response flow, context information is used as a scratch pad.
There are two types of context information:
Transient context, as the name suggests, is temporary and available only on the specific request flow or the response flow but is not carried from the request to the response flow, and is therefore stored in memory.
Correlation context is the second type of context data that is available for the duration of the complete request/response flow. Data set in the request flow is available for all the primitives in the response flow. Any primitive can modify the context information and downstream primitives in the message flow will have access to that information.
The context data are represented as data objects and the structure is inserted in the SMO structure at the start of the mediation flow.
The next point to understand is that within the mediation flow, mediation primitives are used to operate on the message. Mediation primitives examine and update the message contents and therefore must understand what is contained in the message. The solution is to provide mediation primitives with some kind of a common representation of a message, and that is what a Service Message Object does. SMOs provide a common representation of a message that accounts for differing protocols and differing interfaces, operations, and parameters that the message represents. SMOs are built using Service Data Object (SDO) technology. SDO uses a schema that describes the basic structure of an SMO which is composed of three major sections.
The body of the message represents the specific interface, operation, and parameters relevant to this message. The headers section of the message represents information about the protocol over which the message was sent. The context section represents data that is important to the internal logic of the flow itself. Each of these major sections of the SMO is examined in more detail in subsequent slides. The data within an SMO is accessed using SDO, specifically the SDO DataObject, which enables access using XPath, the generic DataObject APIs, and some SMO-specific APIs that are aware of the SMO schema.
The service requestor and service provider interact with the bus through the bindings for the exports and imports of the mediation service module. The data representing the message depends on the binding used for exports and imports. If the primitives in the mediation flow component had to support the data representation for all the various bindings, it would be difficult to implement primitives. For this reason, the first thing the runtime does is that it converts the binding-specific data into common data structure, called Service Message Objects (SMO).
The SMO interface extends the DataObject interface, which is defined by the Service Data Object (SDO), similar to other business objects used in WebSphere Process Server. SMO includes the message headers, message data (payload) and context information and provides an interface to access and modify the SMO data, including headers, payload, and context information. In addition, the SDO data can be accessed using the XPath reference mechanism. The mediation module input contains binding-specific data representation. The mediation module output import binding dictates the data representation that must be sent to the output message. As a result, there is a lack of consistency in data representation and if the mediation flow primitives had to handle all the different data representation, it would become a huge challenge. To solve this problem, the data from binding-specific interaction is converted to a common data structure called the Service Message Object (SMO).
If the mediation primitives in a message flow require a temporary area to save data for other primitives down the message flow or need data set in the request flow to be available during the response flow, context information is used as a scratch pad.
There are two types of context information:
Transient context, as the name suggests, is temporary and available only on the specific request flow or the response flow but is not carried from the request to the response flow, and is therefore stored in memory.
Correlation context is the second type of context data that is available for the duration of the complete request/response flow. Data set in the request flow is available for all the primitives in the response flow. Any primitive can modify the context information and downstream primitives in the message flow will have access to that information.
The context data are represented as data objects and the structure is inserted in the SMO structure at the start of the mediation flow.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.