Modeling and Comparing Service Descriptions

Modeling and Comparing Service

Descriptions

Juan M. Vara, David Granada, Vasilios

Andrikopoulos, Esperanza Marcos

- 1 -

Modeling and Comparing

Service Descriptions

Juan M. Vara1, David Granada1,

Vasilios Andrikopoulos2, Esperanza Marcos1

{juanmanuel.vara, david.granada, esperanza.marcos}@urjc.es

[email protected]

1: Kybele Research Group

Dept. of Computing Languages and Systems II

University Rey Juan Carlos

Spain

2: European Research Institute in

Service Science (Eriss)

Dept. of Information Systems and Management

Tilburg University

The Netherlands

1. Introduction

In this work we have used some of the technologies developed in the context of the Eclipse

Modeling Framework (EMF) [2] to provide with a proof of concept of the synergy between

Model-Driven Engineering and Service Orientation. In particular we have used some EMF

components, like GMF and the family of Epsilon languages [5] for two specific purposes:

To develop graphical editors for modeling Operations in Service Descriptions according to

Service Descriptions metamodel sketched in [1].To implement a basic comparison between

(partial) Service descriptions to asses whether they are compatible.In addition, we have

tested the software developed in the Automotive Purchase Order Processing Scenario, which is

being developed and used as one of the scenarios validation in the S-Cube Network of

Excellence. The scenario is based on the model of Supply Chain Operations Reference model

(SCOR) that provides guidelines for the creation of Supply Chains. This scenario is an example

of how to perform activities of SCOR Level 3 based on SOA (Service-Oriented Architectures)

using the processes of a company belonging to the automobile industry called Automobile

Incorporation (aka AutoInc). AutoInc contains various business units, for example, Sales,

Logistics, Manufacturing, etc. and cooperates with other partners such as suppliers, banks,

carriers, etc. In the following we will assume that the various activities are implemented as

services [1].

2. Defining a (partial) Service Description metamodel

The first step in the development of the graphical editor consists in the definition and

implementation of the metamodel defined to model Service descriptions. Such metamodel is

partially sketched in Fig. 1.


Descriptions



- 2 -

Fig. 1. Service operations metamodel.

The metamodel elements and their relationships can be (more) formally expressed using the following notation:

Element types:

1. Operations: o := (name : string, messagePattern), where messagePattern {one-way,

notification, request-response, solicit-response}.

2. Messages: m := (name : string, role), where role {input, output, fault}.

3. InformationTypes: it := (name : string, valueType, valueRange) where valueType

{document, int, float, double, string,…} and valueRange {(min, max), N/A}.

Relationship types:

1. Operation-Message: r(o,m) := (nameo, namem, c, mul) where mul = [1, 1..*].

2. Message-InformationType: r(m, it) := (namem, nameit, a, mul) where mul = [1, 1..*].

3. InformationType-InformationType: r(iti, itj) := (namei, namej , s, mul) where mul = [0, 1..*].

To implement this metamodel we have used Emfatic, a language for representing EMF Ecore

models in textual form. This way, 0 shows the metamodel expressed in the Emfatic language.

Note also that we include some annotations that will serve to customize some features in the

GMF graphical editor that will be introduced later.


Descriptions



- 3 -

@gmf(foo="bar")

@namespace(uri="purchase", prefix="purchase")

package purchase;

@gmf.diagram(foo="bar")

class Purchase {

val Operation[*] operations;

val InfoType[*] infotypes;

}

@gmf.node(label="name", figure="rounded", label.placement="external",

color="135,206,250", border.width="4", size="200,220")

class Operation {

attr String name; attr EEnumOp messagePattern;

@gmf.compartment(foo="bar", layout="list")

val Message[+] contents;

}

@gmf.node(label="name", figure="rectangle", color="193,255,193")

class Message {

attr String name; attr EEnumMes role;

@gmf.link(target.decoration="arrow", style="dot", tool.description="Relationship

between Message and InfoType")

ref InfoType[+] Message2Info;

}

@gmf.node(label="name", figure="ellipse", color="255,255,153", border.color="0,0,0",

border.style="dot")

class InfoType {

attr String name; attr EEnumValueType valueType; attr String valueRange;

@gmf.link(source.decoration="square", target.decoration="square", style="dash",

tool.description="Relationship between InfoTypes")

ref InfoType[*] Info2Info;

}

enum EEnumOp {

oneway = 0;

notification = 0;

requestresponse = 0;

solicitresponse = 0;

}

enum EEnumMes {

input = 0;

output = 0;

fault = 0;

}

enum EEnumValueType {

document = 0;

int = 0;

float = 0;

double = 0;

String = 0;

date = 0;

}

Fig. 2. Service operations metamodel encoded with Emfatic.

Epsilon allows injecting the previous Emfatic specification into an Ecore metamodel. Fig. 3

shows two partial views of the resulting Ecore metamodel. On the left-hand side the default

EMF tree-like editor is used, while the right-hand side shows the whole metamodel depicted in

an Ecore class diagram using the Ecore diagrammer. Notice that the annotations are brought

along with the different abstractions included in the metamodel. For instance, the Message class

includes a gmf.node annotation that allows setting the geometric shape that will represent

message objects in any diagram, as well as its background color and label.


Descriptions



- 4 -

GMF annotations

Fig. 3. Service operations Ecore metamodel.

The Eugenia component of Epsilon helps on generating a series of models form this

metamodel. Such model will be used taken as source for a code generation step that results in

the JAVA source code that implements both a tree-like editor and a diagrammer to edit models

conforming to the just-defined metamodel.

To automate this process we have developed the KybeleGMFgen plug-in, that groups

together ten different steps (like the creation of the ecore, genmodel, gmftool, gmfgraph,

gmfmap, etc. models from the Emfatic specification of the metamodel).

3. Modeling Service descriptions

In this section we show how the editor generated is used to model three different versions of the

very same Service (Receive Purchase Order). Such service contains one Operation that handles

two different Messages (processOrder and m2) and uses a set of types. Each version diverges

from the others in the signature of the operations provided. In particular, the messages used by

such operations differ from one version to the others. In the following we will show how the

services are modeled and how we asses whether such differences make them compatible or

incompatible from the point of view or a user of the Service.

The diagrammer provides with a palette including widgets to create the types of objects

considered in the previous metamodel, i.e. Operations, Messages and InfoTypes, plus the

widgets to model the allowed relationships between such objects (see Fig. 4).

Fig. 4. Palette of the graphical editor for Service Descriptions

The first version of the considered service is formally described above:

o1 = (processOrder, request - response)

m1 = (POMessage, input)

m2 = (m2, output) //for unnamed output message


Descriptions



- 5 -

it1 = (PODocument, document, N/A)

it2 = (OrderInfo, string, N/A)

it3 = (DeliveryInfo, string, N/A)

it4 = (it4, string, N/A) //for unnamed output message

r(o1, m1) = (processOrder, POMessage, c, [1, 1])

r(o1, m2) = (processOrder, m2, c, [1, 1])

r(m1, it1) = (POMessage, PODocument, a, [1, 1])

r(m2, it4) = (m2, it4, a, [1, 1])

r(it1, it2) = (PODocument, OrderInfo, s, [1, 1])

r(it1, it3) = (PODocument, DeliveryInfo, s, [0, 1])

The graphical representation of the Service description is depicted in Fig. 5, along with some

screen captures showing the properties’ editor for each object.

Fig. 5. Receive Purchase Order service description (V1): graphical model

Finally, such model is serialized into the XMI [6] file showed in Fig. 6 above:

<?xml version="1.0" encoding="UTF-8"?>

<purchase:Purchase xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"

xmlns:purchase="purchase">

<operations name="processOrder" messagePattern="requestresponse">

<contents name="POMessage" Message2Info="//@infotypes.0"/>

<contents name="m2" role="output" Message2Info="//@infotypes.3"/>

</operations>

<infotypes name="PODocument" valueRange="N/A" Info2Info="//@infotypes.1

//@infotypes.2"/>

<infotypes name="OrderInfo" valueType="String" valueRange="N/A"/>

<infotypes name="DeliveryInfo" valueType="String" valueRange="N/A"/>

<infotypes name="it4" valueType="String" valueRange="N/A"/>

</purchase:Purchase>

Fig. 6. Receive Purchase Order service description (V1): XMI serialization 1

The second version of the Receive Purchase Order Service adds a new InfoType object (to model

the date of the purchase order) and a new relationship (the one that relates a given purchase


Descriptions



- 6 -

order with its date of expedition). In the following we describe formally such service, that is

illustrated in Fig. 7 and serialized in Fig. 8:








it5 = (OrderDate, date, N/A)




r(m2, it4) = (m2, it4, a, [1, 1])



r(it1, it5) = (PODocument, OrderDate, s, [0, 1])








</operations>


//@infotypes.2 //@infotypes.4"/>




<infotypes name="OrderDate" valueType="date" valueRange="N/A"/>


Fig. 8. Receive Purchase Order service description (V2): XMI serialization


Descriptions



- 7 -

Finally, the only difference between the third version of the service and the first one is in the

cardinality of the relationship that holds between the it1 and it3 objects. Like we did for the two

previous versions, in the following we introduce the formal specification of the service, next to its

graphical representation (Fig. 9) and XMI serialization (Fig. 10):











r(m2, it4) = (m2, it4, a, [1, 1])





Descriptions



- 8 -







</operations>


//@infotypes.2"/>


<infotypes name="DeliveryInfo" valueType="String" valueRange="N/A"

Info2Info="//@infotypes.0"/>



Fig. 10. Receive Purchase Order service description (V3): XMI serialization

4. Comparing Service descriptions

In the following we present a first implementation of the comparison between two Service

versions to assess whether they are compatible. To that end we use the different versions of the

same service that we have modeled in the previous section.

According to [1], we can summarize Service versions compatibility as: two Service

versions are compatible if one is composed by the same elements (or a subtype of them) that

compose the other. In other words, two Service versions are compatible if (sub)typing

relationships hold between their elements. The sufficient conditions for subtyping between the

components of a Service description are summarized as follows:

1. o o’ name = name’ messagePattern = messagePattern’ (we only accept

equality).

2. m m’ name = name’ role = role’ (as above).

3. it it’ name = name’ valueType valueType’ valueRange

valueRange’ where int float double string (everything else is not valid) and

the value ranges are compared as subsets (if applicable).

4. r(o, m) r’(o,m) o o’ m m’ mul mul’.

5. r(m, it) r’(m, it) m m’ it it’ mul mul’.

6. r(iti, itj) r’(iti, itj) iti it’i itj it’j mul mul’.

7. For all relationships, it holds that r(s, t) [0, 0] mul, or equivalently, if the

relationship is optional (it has a multiplicity of [0, 1..*]).

The only difference between the two first versions of the service to compare is that the new one

(V2) contains two new Infotype objects: orderDate and DeliveryInfoTwo. To illustrate these

differences, Fig. 11 shows tow different views of the two versions of the Receive Purchase Order

service. The first version is shown in the upper side while the second version is shown on the

lower side. Besides, pictures on the left-hand are screen captures from the EMF tree-like editors

whereas right-hand side shows the XMI serialization of such models.


Descriptions



- 9 -







</operations>


//@infotypes.2"/>











</operations>

<infotypes name="PODocument" valueRange="N/A" Info2Info="//@infotypes.1 //@infotypes.2

//@infotypes.4"/>


<infotypes name="DeliveryInfoTwo" valueType="String" valueRange="N/A"/>


<infotypes name="OrderDate" valueType="date" valueRange="N/A"/>


Fig. 11. Different views of two versions of the Receive Purchase Order service description:

EMF tree-like editor and XMI serialization

To implement the comparison we translate the formal specification of conditions presented at

the beginning of this section into a fully operative Epsilon program. For instance, Fig. 12 shows

an excerpt of the source code implementing the comparison. In particular, the code devoted to

compare Operation objects. It checks that two given operations own the same name and that

their attributes are equal as well.

rule ComparisonSimple

match l : useCase1!Purchase

with r : useCase2!Purchase {

compare {

'COMPARISON BETWEEN useCase1.model AND useCase2.model: '.println();

'ELEMENT TYPES'.println();

-- Operation Comparison (name and messagePattern)

for(o1:useCase1!Operation in l.operations){

var compatibleO=false;

var existeO=r.operations.exists(n|n.name=o1.name);

if((existeO) and

(r.operations.selectOne(n|n.name=o1.name).messagePattern==o1.messagePattern)){

compatibleO=true;

}

o1.name.print('[Operation]: ');

' with '.print();

o1.messagePattern.name.print('[messagePattern]: ');

' -> EXIST?:'.print();

compatibleO.println(' ');

}

'RELATIONSHIP TYPES'.println();

return l = r;

}

}

Fig. 12. Excerpt from the Service versions comparison program

When the comparison program is run, the following results are obtained: (for the time being

such results are displayed in a structured way in the Eclipse console, though we are currently

working to dump them to an XML file).


Descriptions



- 10 -

Fig. 13. Comparison process output

The results are shredded into two big groups that inform, respectively of the compatibility at

objects and relationships level between the two given version of the service. In turn, each group

is divided to show separately the results related with each type of object (respectively

relationship). For each object found on one version (respectively relationship), we check if the

other service version contains an object whose properties fulfill the requirements to state that

we can replace one by the other without lessening service compatibility.

For instance, given that V1 contains a processOrder operation, V2 has to contain another

operation object so-called processOrder and whose messagePattern property equals the one of

the V1 processOrder operation. The positive matching regarding this issue is reported in the thid

line of the console output shown in Fig. 13. Look at the rest of the output to see how negative

matchings are reported.

5. Conclusions and Future Work

This report has introduced a first step in the road towards application of MDE technologies to

address Service Science issues. We have shown how existing frameworks can be used to

deploy new tools that help on the specification and analysis of exiting services. In particular, we

have implemented a metamodel for Service descriptions modeling plus a couple of editors to

elaborate models conforming to such metamodel. Besides, we have implemented a rough

service versions comparer to asses whether two versions of a service are compatible according

to the formal description of service compatibility described in [1].

Moreover, this work opens several directions for further research and future work:

First of all, we might work on the improvement of the software developed with regards to

efficiency and support new ways of control and verification of (meta)data. In particular,

model validators, model injectors and model extractors could be developed, that, along with

the metamodel and editors presented would provide with DSL toolkit for Service

descriptions modeling.

Another improvement would be to use MDE technologies to handle the result of the

comparison process. For instance, such results could be expressed in a model conforming

to a simple metamodel, like the one shown in Fig. 14. Such metamodel allows modeling two

different types of compatibilities (between Objects and Relationships). This way, each

element in the model would inform of the level of compatibility between two given elements

from the service versions compared, next to a short description of the issues related to the

compatibility assessment.


Descriptions



- 11 -

Fig. 14. A simple Metamodel for service versions comparison

Finally, another improvement could be to express such model as a weaving model, i.e. a

model intended to express to develop relationships or links between the elements of two

given models. In this case such links would be the responsible of reporting about the

compatibility of a pair of objects from the two versions of the service description [3].


Descriptions



- 12 -

Software requirements

For the correct operation of the developed editor the following requirements have to be fulfilled:

Java 1.5+

Eclipse Platform Galileo v. 3.5.1

EMF (Eclipse Modeling Framework) v. 2.5.0

GMF (Graphical Modeling Framework) v.2.2.0

Eclipse Epsilon v. 0.8.8

The previous components can be found in the Eclipse Modeling Tools package, that bundles

together the afore-mentioned technologies into a unique Eclipse distribution.

References

1. Andrikopoulos, V., Reasoning on Service Description Evolution, January 2010. 2. Budinsky, F., Merks, E., & Steinberg, D. (2008). Eclipse Modeling Framework 2.0 (2nd Edition):

Addison-Wesley Professional. 3. Didonet Del Fabro, M. (2007). Metadata management using model weaving and model

transformation. University of Nantes. 4. Eclipse Epsilon Official Web-Site: http://www.eclipse.org/gmt/epsilon/ 5. Kolovos, D., Paige, R., & Polack, F. (2006). Eclipse Development Tools for Epsilon, Eclipse Summit

Europe, Eclipse Modeling Symposium. Esslingen, Germany.

6. OMG - XML Metadata Interchange (XMI) specification V2.1.1. OMG Document - formal/2007-12-01.

http://www.eclipse.org/gmt/epsilon/

Date post:	30-Mar-2016
Category:	Documents
Upload:	kybele-research-group
View:	218 times
Download:	5 times

Modeling and Comparing Service Descriptions

Documents