Step 5. Deriving the PSM of the Integration Solution

For that reason, we use the necessary conditions identified in Section 5.1.

First, we check whether all defined interactions between the mediator and the systems to be integrated can establish results. Next, we verify whether the integrated behavior of the mediator and the systems to be integrated can be performed. The verification method is omitted here and explained in detail in Section 5.3.

5.2.5 Step 5. Deriving the PSM of the Integration Solution

In this final step (cf. Figure 5-102), the platform-independent service model of the mediator is transformed into a platform-specific model in terms of some implementation technology.

PIM PIM

1 1

3

2 4 2

3 PIM

PSM PSM PSM

5

In our approach, we do not assume a particular execution platform. For example, the platform-specific service model of the mediator can be transformed to a WS-BPEL specification, EJB, or .Net application. In this section, we only present an abstract architecture of possible execution platforms (cf. Figure 5-103).

Figure 5-101 Step 4. Verification of the integration solution

Figure 5-102 Step 5. Deriving the PSM of the integration solution

Mediator

Data Flow Manager

Inbound message

Outbound message

Control Flow Manager Message receiver

Message sender

State manager

Coordinator

Reasoner

Data

Model Data

transformer

Constraint checker

The architecture of the Mediator consists of two main components – Control Flow Manager and 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 managing the state of the Mediator and for performing the necessary data transformations and constraint checking.

The Control Flow Manager consists of three subcomponents – Message receiver, Message sender and Coordinator. The Message receiver is responsible for receiving all inbound messages and the Message sender for sending all outbound messages. The Coordinator executes the behavior specified in the behavior al model of the Mediator, i.e., based on the current state it activates and deactivates the Message receiver and Message sender. When a message is received, the Coordinator interacts with the Data Flow Manager to update the state of the Mediator. When a message is to be sent, the Coordinator interacts with the Data Flow Manager to obtain the data required to construct the outbound message.

To derive the Control Flow Manager we use the approach described in (Dirgahayu, 2007). The proposed approach is divided into three steps:

pattern recognition, pattern realization and activity transformation (cf. Figure 5-104).

Figure 5-103 Abstract

architecture of the Mediator

To decouple the pattern recognition and pattern realization (and this way provide support for building reusable transformations), the authors define Common Behavior al Patterns Language (CBPL). Each CBPL pattern is represented as sequence, concurrence, selection and iteration (cf. Figure 5-105).

A sequence contains one or more activities to be executed in succession. A concurrence contains two or more activities that can be executed independently. An iteration contains an activity to be executed repeatedly as long as its condition holds. A selection contains one or more cases to be selected. A case contains an activity to be executed when its condition holds.

The basic CBPL patterns are illustrated in Figure 5-105.

a b

The Data Flow Manager consists of two components – State manager and Reasoner. The State manager is responsible for updating the state of the Mediator (after receiving a message) and for querying that state (before sending a message or when checking a constraint). In some cases, data in the received message may have to be transformed before updating the state.

For that purpose the State manager uses the Data transformer component.

Likewise, in some cases the State manager uses the Data transformer to construct new messages. The Data transformer is in fact the component that implements the mapping relations specified in the information model of the mediator. Similar to Data transformer, the Constraint checker queries the state of the mediator and provides an answer whether a constraint holds or not.

To take full advantage of the formal specification of the information model of the Mediator the Data Flow Manager may contain a Reasoner component. The Reasoner uses the formal knowledge specified in the information model of the Mediator in conjunction with the facts about the current state of the Mediator to infer new state information, i.e., it makes all implicit knowledge about the state more explicit. In addition, the Reasoner can

Figure 5-104

be used by the Data transformer and the Constraint checker as an intelligent query engine and constraint solver.

A platform-specific service model contains information that is not present in the platform-independent service model. Examples of such information are the XML namespaces of the exchanged messages or the types of the service operation (e.g., in case of WS-BPEL - invoke, receive or reply). To provide the required platform-specific information we annotate the elements of the platform-specific service model.

M₂(customerName)

System A System B

M₁

M₂ M₃ M₁(name, address)

M₃(customerAddress)

First, we define a Mediator behavior that matches the receiving of M₁ and sending of M₂ and M₃. In addition, we add the relation between M₁ and M₂.

Mediator M M₁

M₂ M₃

M₃(customerAddress) M₂(customerName)

System A System B

M₁(name, address)

Suppose that the information model contains the mappings

∀x:∃name(M₁, x) ∧ ∀y:∃customerName(M₂, y) → y = x

∀x:∃address(M₁, x) ∧ ∀y:∃customerAddress(M3, y) → y = x

Analyzing the mappings, we discover that we need information from M₁ to construct M2 and M3. Therefore, we add message-splitting behavior to the Mediator (cf. Figure 5-108)

Figure 5-106 Example of two systems to be integrated

Figure 5-107 Defining a mediator that matches the send and received messages by the systems to be integrated

Mediator M M₁

M₁ M₂

M₃(customerAddress) M₂(customerName)

System A System B

M₁(name, address)

In some cases, the information mappings are not sufficient to define the complete behavior of the Mediator. For example, different messages could provide the same type of information used to produce another message. In such cases the designer of the Mediator has to decide which input message to use. In some other cases, the behavior model of the Mediator can define custom processing logic. For example, the Mediator could wait for a message from some system for a certain period of time. If it does not receive such a message, it has to send a timeout message to another system. Such a custom processing logic has to be defined manually.

5.3 Method for Formal Verification of System