In Step 3 (cf. Figure 7-124), we design the information and behavior models of the Mediator.
PIM PIM
1 1
3
2 4 2
3 PIM
PSM PSM PSM
5
The information model of the Mediator is constructed from the union of the information models of Blue and Moon. In addition, the information model of the Mediator contains new classes to represent status information of the Mediator (e.g., the set of order line items that have been confirmed so far) as well as the mapping relations among the classes and properties from the information models of Blue and Moon.
The construction of the behavior model of the Mediator requires the definition of (i) the mapping relations among the classes and properties from the information models of Blue and Moon, (ii) the services provided and requested by the Mediator and (iii) the composition of these services by relating their operations.
To define the mappings among the classes and properties from the information models of Blue and Moon we use the approach presented in (Haase, 2005).
An OWL mapping system MS is a triple (S, T, M), where S is the source information model, T is the target information model, and M is the mapping between S and T, i.e., a set of assertions Qs → Qt, where Qs and
Qt are conjunctive queries over S and T, respectively, with the same set of distinguished variables x. Thus, a mapping is equivalent to an axiom:
∀x: Qs(x, ys) → Qt(x, yt)
The correspondence between classes and properties from the information models of Blue and Moon are expressed as a function of subsumption, e.g.,
Qs ⊆ Qt. Using an OWL reasoner, such as Racer36and Pellet37, allows us to check the information model of the Mediator for consistency.
36 Racer Systems, Racer Reasoner, http://www.racer-systems.com/
Figure 7-124 Step 3. Solving integration problem at PIM level
To facilitate the use of the mapping approach described above, we have defined a Domain-Specific Mapping Language (mapping DSL). The mapping DSL provides a means for defining the mapping relations between the information models of Blue and Moon and for deriving automatically the information model of the Mediator in OWL (used in the verification step to check necessary condition 1) and the Java classes that implement the data transformation (used at runtime to transform the exchanged messages between Blue and Moon). The metamodel of the mapping DSL is presented in Figure 7-125.
A Transformation consists of one or more Mappings. A Mapping defines an assertion Qs → Qt where Qs is defined as conjunction of Bindings in a number of Source domains and Qt is defined in a Binding in the Target domain. In addition, a Mapping may contain zero or more expressions which bind variables by invoking other Mappings or custom functions.
Transformation
Mapping
Domain
Target Source
Binding Expression mappings
1..*
expressions
bindings domains
0..*
0..*
0..*
Figure 7-126 illustrates the mappings between the class Pip3A4PurchaseOrderRequest from the information model of Blue and the classes SearchCustomer, Order and LineItem from the information model of Moon. Note, that the mappings are discovered automatically using the UDEF information added in Step 2.
37 http://clarkparsia.com/pellet/
Figure 7-125 The metamodel of the mapping DSL
Pip3A4PurchaseOrderRequest
Using the mapping DSL we formally define these mappings:
transformation Blue2Moon { mapping POR2Search {
source por:Pip3A4PurchaseOrderRequest { fromRole(?por, ?role)
PartnerRoleDescription(?role, ?partnerRole) PartnerDescription(?partnerRole, ?partner) BusinessDescription(?partner, ?business) BusinessName(?business, ?businesName) }
target search:SearchCustomer { searchString(?search, ?businesName) }
}
mapping POR2NewOrder {
Source por:Pip3A4PurchaseOrderRequest { fromRole(?por, ?role)
PartnerRoleDescription(?role, ?partnerRole) ContactInformation(?partnerRole, ?contact)
PhysicalLocation(?shipTo, ?location)
mapping POR2NewLineItem {
Source por:Pip3A4PurchaseOrderRequest { purchaseOrder(?por, ?order)
ProductLineItem(?order, ?lineItem) ProductIdentification(?lineItem, ?id)
GlobalProductIdentifier(?id, ?globalProductId) OrderQuantity(?order,?orderQty)
RequiredQuantity(?orderQty, ?requredQty) ProductQuantity(?requredQty, ?quantity) }
Target item: lineItem {
articleId(?item, ?globalProductId) quantity(?item, ?quantity)
} } }
The Mediator provides one service that must match the service requested by Blue. The service provided by the Mediator can initially be defined by
“mirroring” the service requested by Blue. The mirroring of a service is obtained by changing each operation call into an operation execution, and vice versa, while keeping the same parameters. In addition, the relations among the operations and the parameter constraints may (initially) be retained.
Likewise, the services that are requested by the Mediator can be obtained by mirroring the services that are provided by Moon.
The design of the Mediator behavior can now be approached as the search for a composition of the requested services that conforms to the provided service. The structure of this composition is defined by the (causal) relations among the operations. We do this by inspecting the mapping relations in the information model of the Mediator. For instance, the elements of M3 are related to the elements of M2 by mapping relation POR2Search, i.e., the information required to construct M3 is provided in
M1. Therefore, we use the message splitting pattern (see Chapter 5, p.23) . Similarly, the elements of M5 are related to the ones of M1 by mapping relation POR2NewOrder. In addition, M5 contains the orderId (provided by M4) i.e., the information required to construct M5 is provided in messages M1 and M4. Therefore, we instantiate the message aggregation pattern (see Chapter 5, p.23).
The information mappings are not sufficient to define the complete behavior of the Mediator. Although the search for a customer (M3) in CRM system gives information (M4) such as AddressInfo or ContactInfo, still the information that is provided in M1 should be used instead. Such hidden assumptions have to be made explicit in the behavior model of the Mediator.
The complete behavior model of the Mediator is presented in Figure 7-128.
Figure 7-127
Moon’s SM
In this step, we provided evidence for the validity of Claim 2, i.e., COSMO provides all required concepts to model platform-independent integration solutions.