Upload
kybele-research-group
View
225
Download
5
Embed Size (px)
DESCRIPTION
In this work we have used some of the technologies developed in the context of the Eclipse Modeling Framework (EMF) to provide with a proof of concept of the synergy between Model-Driven Engineering and Service Orientation.
Citation preview
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
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.
Modeling and Comparing Service
Descriptions
Juan M. Vara, David Granada, Vasilios
Andrikopoulos, Esperanza Marcos
- 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.
Modeling and Comparing Service
Descriptions
Juan M. Vara, David Granada, Vasilios
Andrikopoulos, Esperanza Marcos
- 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.
Modeling and Comparing Service
Descriptions
Juan M. Vara, David Granada, Vasilios
Andrikopoulos, Esperanza Marcos
- 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
Modeling and Comparing Service
Descriptions
Juan M. Vara, David Granada, Vasilios
Andrikopoulos, Esperanza Marcos
- 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
Modeling and Comparing Service
Descriptions
Juan M. Vara, David Granada, Vasilios
Andrikopoulos, Esperanza Marcos
- 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:
o1 = (processOrder, request - response)
m1 = (POMessage, input)
m2 = (m2, output) //for unnamed output message
it1 = (PODocument, document, N/A)
it2 = (OrderInfo, string, N/A)
it3 = (DeliveryInfo, string, N/A)
it4 = (it4, string, N/A) //for unnamed output message
it5 = (OrderDate, date, N/A)
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])
r(it1, it5) = (PODocument, OrderDate, s, [0, 1])
Fig. 7. Receive Purchase Order service description (V2): graphical model
<?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.4"/>
<infotypes name="OrderInfo" valueType="String" valueRange="N/A"/>
<infotypes name="DeliveryInfo" valueType="String" valueRange="N/A"/>
<infotypes name="it4" valueType="String" valueRange="N/A"/>
<infotypes name="OrderDate" valueType="date" valueRange="N/A"/>
</purchase:Purchase>
Fig. 8. Receive Purchase Order service description (V2): XMI serialization
Modeling and Comparing Service
Descriptions
Juan M. Vara, David Granada, Vasilios
Andrikopoulos, Esperanza Marcos
- 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):
o1 = (processOrder, request - response)
m1 = (POMessage, input)
m2 = (m2, output) //for unnamed output message
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, [1, 1])
Fig. 9. Receive Purchase Order service description (V3): graphical model
Modeling and Comparing Service
Descriptions
Juan M. Vara, David Granada, Vasilios
Andrikopoulos, Esperanza Marcos
- 8 -
<?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"
Info2Info="//@infotypes.0"/>
<infotypes name="it4" valueType="String" valueRange="N/A"/>
</purchase:Purchase>
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.
Modeling and Comparing Service
Descriptions
Juan M. Vara, David Granada, Vasilios
Andrikopoulos, Esperanza Marcos
- 9 -
<?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="it2" valueType="String" valueRange="N/A"/>
</purchase:Purchase>
<?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.4"/>
<infotypes name="OrderInfo" valueType="String" valueRange="N/A"/>
<infotypes name="DeliveryInfoTwo" valueType="String" valueRange="N/A"/>
<infotypes name="it2" valueType="String" valueRange="N/A"/>
<infotypes name="OrderDate" valueType="date" valueRange="N/A"/>
</purchase:Purchase>
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).
Modeling and Comparing Service
Descriptions
Juan M. Vara, David Granada, Vasilios
Andrikopoulos, Esperanza Marcos
- 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.
Modeling and Comparing Service
Descriptions
Juan M. Vara, David Granada, Vasilios
Andrikopoulos, Esperanza Marcos
- 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].
Modeling and Comparing Service
Descriptions
Juan M. Vara, David Granada, Vasilios
Andrikopoulos, Esperanza Marcos
- 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.