EVALUACIÓN

For the UML statemachine diagram, [110] defines a runtime metamodel for the DMM specification of UML statemachine diagram, which is an extension of its existing metamodel. Based on this runtime metamodel, more than 90 DMM rules are defined to specify the behavior of the elements in UML statemachine diagram.

Similar to the runtime metamodel of the UML sequence diagram, the basic elements of the runtime metamodel for the UML statemachine dia-gram are the StateMachineExecution and the Marker. In this context, the StateMachineExecution is created for a StateMachine at runtime and serves as a container for the semantic elements. Additionally, the Marker element is used to control the sequence of the execution of the individual states and the transitions in the statemachine.

(a) startStatemachine() (c) createMarker()

executes

name sm:StateMachine

sme:StateMachineExecution hasStarted == false hasStarted‘:= true

:StateMachineExecution

Vertex:Vertex

enterInitialState()

contained_in marker

:Marker

(b) enterInitialState()

i iti lSt t P d St t

region subvertex

kind== ‘initial‘

sm:StateMachine :Region

initialState:PseudoState

createMarker()

Figure 4.6: (a)DMM Rule startStatemachine() to start a Statemachine (b) enterInitialState() to enter the Statemachine in its initial State (c) createMarker() to create a Marker for a particular Vertex

As an example for a DMM rule to specify the behavior of a UML statema-chine, we show the rule namely startStateMachine() in Fig.4.6(a) for the

start of a StateMachine. In the runtime model for a UML statemachine dia-gram, a StateMachineExecution is created for StateMachine element with hasStarted attribute set to false. Similar to the InteractionExecution in the UML sequence diagram runtime model, a statemachine can start only if its hasStarted attribute is set to true as shown in Fig. 4.6(a). As a result of this graph transformation, the hasStarted attribute is set to true, which means that the statemachine has started and every orthogonal Region in the statemachine is in its initial state (through the invocation of enterInitialState() in Fig. 4.6(b)). Additionally, through the invo-cation of createMarker() (Fig. 4.6(c)), a Marker is created that points to the Vertex on which this rule is invoked (the initial state in this case). As a result of the invocation of this rule, the initial states have markers and the statemachine can start.

Apart from these rules, other basic DMM rules for UML statemachine diagram include rules for firing transitions, state execution, etc.

4.4 Summary and Discussion

In this chapter, we define the linguistic semantics for RSDL. For this pur-pose, we mainly rely on existing approaches in this direction. A collective basis for these semantics for different RSDL artifacts are graph transforma-tion rules. In this directransforma-tion, the RSDL data model is formally specified as a type graph and the operation behavioral semantics based on visual contracts are specified as typed graph transformation rules. Similarly, the DMM ap-proach [64] is used for the semantic specification of service protocols, which focus the modeling languages like UML and specify their semantics through graph transformation rules typed over their runtime meta models.

83

Service Description Normalization through 5

Data Model Matching

Service description normalization is the first phase of our service discovery and composition approach and it deals with the resolution of the data model heterogeneity of the service partners. That means whenever a requester ac-cesses the service market with his request to search for possible service com-positions, its service request is automatically annotated to semantic concepts on the basis of a global ontology maintained by the OTF provider. Later, on the basis of these ontological semantics, its data model is mapped to the global data model conforming to the global ontology. Consequently, these local-global data model mappings are used to translate the service request to a common representation typed over the global data model.

Analogously, a service description normalization is also performed, when a service provider accesses the OTF service market with his offer to publish his service. Our data model heterogeneity resolution mechanism is based on our detailed work in this direction presented in [140].

In the following section, we give an overview of our service descrip-tion normalizadescrip-tion approach. Later, we lay foundadescrip-tions for our mechanism through the explanation of some important concepts. In Sec.5.3, we present our data model matching algorithm. Next, a service description normaliza-tion approach is introduced, which allows the normalizanormaliza-tion of the service description to a common representation based on the data model matching results.

5.1 Service Description Normalization Overview

An important aim of the OTF computing is that it enables the coordination among the heterogeneous service partners that function in their independent domains with their individual domain knowledge.

85

Consequently, such an independence of the service partners leads to the data model heterogeneity of their service descriptions, which can make their automatic matching during service discovery and composition difficult. For instance, a simple scenario that can lead to data model heterogeneity of service partners is their use of different terminologies to define their data models, e.g., a class defined as Client in the requester data model may be defined as a class User in the provider data model. Similarly, the data model heterogeneity can also arise due to different granularity levels of the elements in the data models, e.g., a concept Address in the requester data model may correspond to two concepts Address and Coordinates in the provider data model. An important task for the OTF provider is to auto-matically resolve this data model heterogeneity of the requested and offered service descriptions in order to enable their automatic matching on the OTF service market. For instance, approaches like [65, 108, 157] come up with comprehensive mechanisms for service discovery but ignore this important aspect altogether by using same data model.

However, as discussed in Sec. 2.3.1, a recent trend in the SOC is to explicitly define ontological semantics and use them for the matching of data elements in the service descriptions. In this context, the semantic web service approaches [121,51,39,98,136] particularly emphasize and present different mechanisms to define such ontological semantics for the service descriptions.

In recent years, a considerably large number of approaches [14, 88, 31, 37, 81, 79, 100, 95, 127, 153] in the area of automatic service discovery and composition have defined mechanisms to match service descriptions while considering their ontological semantics. However, most of these approaches do not solve the problem as they are based on the assumption that a common ontology exists in the service market, which is shared by all the service partners. Conforming to this common ontology, the service partners describe their respective service descriptions and their ontological semantics, which are later used to match these service descriptions. However, according to the essence of SOC, such an assumption is not realistic and there is a requirement for approaches that deal with data model heterogeneity while allowing the service partners to conform to their respective domain knowledge, which can possibly be specified as their independent local ontologies.

As an improvement to these existing approaches, our approach allows the service partners to independently define their service descriptions in their respective domain and introduces an automatic mechanism for the OTF provider to resolve the data model heterogeneity of the service partners based on their automatically defined ontological semantics and bring them to a common representation before their matching. In this chapter, we will

OTF Provider

Automatic Service Discovery & Composition Service Description Normalization

Data Model  Matching

Visual Contract Normalization Service 

Description Data Model Mappings

…

Global Ontology +  Global Data Model

Normalized Service  Description Service 

Partner

Figure 5.1: An Overview of the Service Description Normalization Phase in the Proposed Approach

explain different steps of this approach in detail in the context of our running example.

Fig.5.1gives an overview of this mechanism. In the setting of OTF com-puting, the OTF provider maintains a global ontology that comprehensively covers the information domain under consideration and captures the domain knowledge in an extensive manner. Additionally, a conforming global data model is also defined to define the structure of data elements in the global domain. The automatic mechanism for data model heterogeneity resolution is initiated when a service requester or provider access the OTF market with its service request or offer, respectively.

In the first step of this phase, the local data model of the service partner is matched to the global data model of the OTF provider. This automatic matching mechanism, which is explained in Sec. 5.2 and Sec. 5.3 is based on the structural as well as the semantic matching of the local and global data model elements based on the ontological semantics defined through the global ontology. The result of this step are the mappings between the local and the global data models.

In the second step of this phase, the service description of the particular service partner is normalized on the basis of the local-global data model mappings. This normalization of the service description is mainly concerned with the operations in the considered service description because the data model heterogeneity of the service partners mainly complicates the matching of their operations, whose structural and behavioral descriptions are typed over the respective data models.

The operation normalization in the considered service description can be brought down to the normalization of their behavioral descriptions, i.e., the 87

visual contracts. As far as the normalization of structural descriptions, i.e., operation signatures is concerned, the input/output parameters are included in the respective VC according to the RSDL specification in Chap. 3 and hence do not need to be normalized separately. The normalization of the operation names is not relevant for our approach as our n : m operation matching mechanism mainly relies on behavioral descriptions and does not consider the operation names while matching.

For the service protocol, which describes the operation invocation se-quences in the considered service description, operation normalization suf-fices to overcome the data model heterogeneity and hence no further nor-malization is required for service protocol.

As a result of the service description normalization, the service requests and offers are typed over the global data model. Consequently, the normal-ized service request can be matched to the normalnormal-ized service offers on the service market.

In the following sections, we describe these steps of the service descrip-tion normalizadescrip-tion phase in detail.