Step 5. Deriving the PSM of the integration solution

In Step 5 (cf. Figure 7-134), the service PIM of the Mediator is transformed into a platform-specific model in terms of WS-BPEL.

PIM PIM

In Chapter 5, we presented the abstract architecture of the Mediator. To recap, it consists of two main components: a Control Flow Manager and a Data Flow Manager. The Control Flow Manager is responsible for sending and receiving messages in a particular order as well as for querying and updating the state of the Mediator. The Data Flow Manager in turn, is responsible for

Figure 7-132 Step 5. Deriving the PSM of the integration solution

managing the state of the Mediator and for performing the necessary data transformations and constraint checking.

For this case, we have selected WS-BPEL engine to implement the Control Flow Manager. Therefore, the behavior PIM of the Mediator has been mapped to a WS-BPEL specification. The Data Flow Manager has been implemented as separate Web Service. The reason for that is to provide an interpreter for the mapping DSL and execute the data transformations at run-time.

To derive the Control Flow Manager we adopt and extend the approach described in (Dirgahayu, 2007). In this approach, the transformation is divided into three successive transformation steps: (T₁) pattern recognition, (T2) activity replacement, and (T3) model realization (see Figure 7-135).

T2a

In the first step (T₁), control flow patterns from service the PIM of the Mediator are recognised and then transformed to the pattern-oriented service model in terms of Common Behavioral Patterns Language (CBPL). Each CBPL pattern represents a control flow that is common to most execution languages, i.e., sequence, concurrence, selection, and iteration (cf. Figure 7-136).

A sequence contains one or more activities to be executed in succession. A concurrence contains two or more activities that can be executed independently, i.e., in parallel. Iteration contains one or more activities to be executed repeatedly as long as a condition holds. Selection contains one or more cases to be selected. Case contains an activity to be executed when its condition holds.

In the second step (T₂), all data transformations and constraint evaluation activities from the pattern-oriented service model are replaced with operations to interact with the Data Flow Manager. This step results in a control-flow service model that represents the Control Flow Manager in CBPL.

In the last step (T3), the control-flow service model is mapped onto a service PSM in terms of WS-BPEL. Note, that a service PSM contains

Figure 7-135 Transforming the service PIM of the Mediator to a

information that is not present in the service PIM. Examples of such information are the XML namespaces of the exchanged messages or the WSDL port types and operations of the services to be integrated. To provide the required platform-specific information we annotate the elements of the service PIM. This information is maintained during the first and second step and is used in the third step. In the following, we present the mapping rules from a service model in CBPL to a WS-BPEL description.

Sequence maps to bpel:sequence

<sequence>

<a />

<b />

</sequence>

Iteration maps to bpel:while

<while>

<condition>

Condition A </condition>

<a />

</while>

Concurrence maps to bpel:flow

<flow>

<a />

<b />

</flow>

selection maps to bpel:if

<if>

<condition>

Condition A </condition>

<a />

<elseif>

<condition>

Condition B </condition>

<b />

</elseif>

</if>

In some cases, the behavior of the mediator may need to be restructured to enable mapping onto CBPL patterns. Figure 7-137 gives examples of such a restructuring.

The excerpt of the abstract WS-BPEL behavior of the Mediator is shown below

<sequence>

<receive ...

operation="receivePurchaseOrderRequest"

inputVariable="M1"/>

<invoke ...

operation="updateState"

inputVariable="М1"/>

<mappingName>por2search</mappingName>

<mappingParameter>M1</mappingParameter>

</requestМ3>

-->

<invoke ...

operation="retrieveState"

inputVariable="requestМ3"

outputVariable="М3"/>

operation="updateState"

inputVariable="М4"/>

At run-time, the Web service, implementing the Data Flow Manager, receives data in XML format from the Control Flow Manager (operation updateState).

Figure 7-137 Behavior restructuring

First, it transforms the data from XML to OWL and uses them to infer new state information, perform transformations and evaluate constraints. When requested (operation retrieveState), the Web service transforms back the data from OWL to XML and sends it to the Control Flow Manager for further use.

7.3 Scenario 2

To show that our integration method is able to cope with changes in the integration requirements, we present a second case defined in Scenario 2 of SWSC.

Moon decides to integrate also its Production Management (PM) system. The Mediator can use the PM to order products to be scheduled for production, when they are not available from SM system. (cf. Figure 7-138).

In addition to Scenario 1, if the SM system reports that an item is not available, the PM system will be used to check whether that item can be produced. This is done by sending a message (M13) to the PM system to which this system responds synchronously by sending a message (M14) containing the price and the availability date. If the price and the availability date meet the expectations of the customer Blue (as specified in message M1) the item will be ordered by sending a message (M₁₅) to the PM system and be confirmed synchronously (M₁₆).

Moon PM Customer object (M4)

CustomerId (M₅)

Confirmation (M₈)

OrderId (M₉)

Line item confirmation (M₁₀) OrderId, ArticleId, Qty (M₇)

OrderId (M₆)

ArticleId, Qty (M₁₃)

Date, Price (M₁₄)

ArticleId, Qty (M15)

Date, Price (M₁₆)

In the remainder of this section, we apply each step of our integration method to solve the integration problem presented above. For that purpose, we apply the steps of our integration method again using concrete technologies, i.e., WSDL and WS-BPEL (for modeling the service PSMs) and COSMO in conjunction with OWL (for modeling the service PIMs).