Supporting Service Versioning

MDE to the Rescue

an Santiago, Juan M. Vara, Jenifer Verde, Valeria de Castro and Esperanza Marcos

Kybele Research Group, Rey Juan Carlos University, Avd. Tulip

an S/N, M

ostoles, Madrid, Spain

Keywords:

Service Orientation, Model-Driven Engineering, Traceability.

Abstract:

In the ﬁeld of Service-Oriented Architecture (SOA), evolution is a key issue given the non-trivial nature of

updating widely distributed and heterogeneous systems. In particular, the evolution of a service is expressed

through the creation and decommissioning of different service versions during its lifetime. These versions

must be aligned with each other in such a way as to allow a service developer to track the various modiﬁcations

introduced over time and whether the resulting service version is compatible with existing consumers. Having

all this in mind, this work aims at deﬁne a plan to provide a complete framework to support service evolution

by means of Model-Driven Engineering techniques.

1 INTRODUCTION

Evolution is inherent to software systems because

of the rapid improvement of technologies and busi-

ness logic. In the ﬁeld of Service-Oriented Architec-

ture (SOA), evolution is a key issue given the non-

trivial nature of updating widely distributed and het-

erogeneous systems (Papazoglou and van den Heuvel,

2007). To alleviate the inherent complexity of evolv-

ing service-based systems, this paper takes a step

further a proposal to deal with service evolution

using Model-Driven Engineering (MDE) techniques

(Schmidt, 2006).

Formally speaking, service evolution is the disci-

plined approach of managing service changes and is

deﬁned as the continuous process of development of a

service through a series of consistent and unambigu-

ous changes (Andrikopoulos et al., 2012). The evolu-

tion of a service is expressed through the creation and

decommissioning of different service versions during

its lifetime. These versions must be aligned with each

other in such a way as to allow a service developer to

track the various modiﬁcations introduced over time

and their effects on the original service.

To control service development, a developer needs

to know why a change was made, what its implica-

tions are, and whether the resulting service version is

compatible with existing consumers. A service ver-

sion is compatible if it does not render its consumers

inoperable, i.e., it does not break them in the sense

that consumers are still able to use the same type of

data they used as inputs and get back the same type of

data they got as outputs.

This way, our proposal aims at providing a model-

driven technological framework to support service

evolution at interface level. To that end, in previous

works (Vara et al., 2012) we presented a DSL toolkit

for modelling the structural part of Abstract Service

Descriptions (ASD) and a reasoning mechanism that

assesses whether two versions of a service are com-

patible with respect to its consumers. Such work

served to provide a proof of concept of the possible

synergy between MDE and Service Orientation. As

well, it served to lay the foundation for future work.

This paper is the ﬁrst stage of such work: it deﬁnes

the following steps to progress in the building of the

service evolution framework.

To that end, the rest of this work is structured as

follows: Section 2 presents the building of techno-

logical bridges to move from WSDL descriptions to

ASDs; Section 3 introduces the materialization of the

textual reports about service versions compatibility

into trace models; Section 4 deﬁnes a model-driven

process to support contracts generation and ﬁnally,

Section 5 concludes by highlighting the main contri-

bution of this paper.

2 FROM WSDL DOCUMENTS TO

ASD MODELS

In (Andrikopoulos et al., 2012) present a rigorous for-

212

Santiago I., M. Vara J., Verde J., de Castro V. and Marcos E..

Supporting Service Versioning - MDE to the Rescue.

DOI: 10.5220/0004523402120217

In Proceedings of the 8th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE-2013), pages 212-217

ISBN: 978-989-8565-62-4

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

mal framework based on type safety criteria and al-

gorithms which controls and delimits the evolution of

services. The framework extends and applies theo-

ries and methods of controlling evolution from object-

oriented programming languages like subtyping and

co- and contra-variance of input and output (Meyer,

1997).

Based on these principles a reasoning mechanism

is presented that allows deciding when a change to

the service interface leads to a compatible version of

the service for the consumers. More speciﬁcally, the

framework is based on a technology-agnostic notation

for the representation of service interfaces in the form

of Abstract Service Descriptions (ASDs).

In order to provide tooling support for such frame-

work, a DSL toolkit to model ASDs was introduced in

previous works (Vara et al., 2012). Nevertheless, de-

spite there are different initiatives for services repre-

sentation, most of existing services use WSDL (W3C,

2001) to provide a standard description of their inter-

face. Therefore, to widen the scope of the approach

the ﬁrst task to address is the building of technologi-

cal bridges to extract the information gathered in any

existing WSDL document to express it in terms of the

DSL already introduced for ASD modeling. As a re-

sult, the level of abstraction at which reasoning about

the interface of any given set of services is made can

be raised.

The process to extract ASD models from WSDL

ﬁles is brieﬂy illustrated in Figure 1.

• The starting point is one or more WSDL les de-

scribing different versions of the same service,

namely S

and S

. Being XML les, they conform

to the WSDL XML Schema (WSDL.xsd).

• In order to bring them to a model-engineering

context, a TCS (Jouault et al., 2006) text-to-model

transformation (XML2Ecore) is used to inject such

les into two XML models, which conform to the

XML metamodel (XML.ecore). The objects of

these models are basically XML elements and

attributes. This way this transformation allows

moving from grammarware to modelware (Wim-

mer and Kramler, 2006).

• Next, we map the XML models to WSDL

models conforming to the WSDL metamodel

(WSDL.ecore). To do so we use an ATL

(Jouault et al., 2008) model-to-model transforma-

tion (XML2WSDL).

• Another model-to-model transformation (WSDL2-

ASD) extracts the structural and non-functional in-

formation of the WSDL models to produce two

ASD models that conforms to the ASD meta-

model (ASD.ecore). Such models provide high-

level descriptions of the services interfaces, which

abstract completely of any technological detail.

It is worth mentioning that the development of

the inverse transformation chain will be addressed as

well. Thus, a WSDL document could be derived from

an ASD model. To that end, note that when moving

from WSDL to ASD all the non-structural data is lost.

Figure 2 shows the solution that will be adopted in or-

der to solve this issue.

To support the extraction of complete WSDL ﬁles,

such data will be collected into partial WSDL mod-

els. Then, the different reasoning will be performed

over the ASD by means of the MDE processing tech-

niques needed. Once the ASD desired is obtained, it

will be merged with the partial WSDL model (con-

taining the non-structural information). As a result

a WSDL model that can be directly serialized into a

WSDL document will be obtained.

3 TRACKING SERVICE

VERSIONS COMPATIBILITY

As mentioned before, a ﬁrst version of the service ver-

sion comparer was introduced in previous works. In

particular, the Service Representation Modeler (SR-

Mod

) provides a textual report on the compatibility

of two given versions of the same service. Such as-

sessment is based on evaluating if sub-typing relation-

ships hold between the elements of both versions.

Next movement on the development of the MDE

framework to support service evolution is to extend

the use of MDE technologies to improve the han-

dling of the comparison process output. More specif-

ically, version comparison results will be expressed

in the shape of traces model (Santiago et al., 2012)

that relates the ASD models representing each ver-

sion of the service. This way, each element of the

trace model would inform of the level of compatibil-

ity between two given elements of the service versions

compared, together with a short description of the is-

sues related to the compatibility assessment. The use

of trace models to represent the output of compatibil-

ity assessment results in two main advantages:

• On the one hand, being persisted as models, such

results could be later processed by means of any

other MDE technique, such as model merging or

model checking (Bernstein, 2003).

• On the other hand, the nature of the informa-

tion gathered from the assessment process is em-

inently relational. It consist mainly of statements

http://srmod.wordpress.com/

SupportingServiceVersioning-MDEtotheRescue

213

Figure 1: From WSDL ﬁles to ASD models.

such as foo element (from S

) is (non-)compatible

with bar element (from S

). Hence, the use of

proper tooling could ease the understanding and

comprehension of this information whose nature

is mainly relational.

All in all, iTrace

will be used to collect the output

of SRMod into a trace model. The iTrace framework

was devised to support the management and analy-

sis of traceability information in MDE projects. Note

that from a high-level point of view, a trace object

is nothing but the materialization of the relationship

between two or more artifacts. Therefore, traces can

be used to collect information about the relationship

(whether they are compatible or incompatible) be-

tween two or more objects of two given ASD models.

Broadly speaking, distinguish two types of traces will

be distinguished: Compatible and Incompatible.

Figure 3 illustrates the idea by showing a simplis-

tic scenario. The comparison of two given ASDs,

namely S

and S

produces a trace model that in-

forms of the compatibility relationships between the

elements of S

and S

. For instance, the trace model

shows that there is no equivalent element for A

; both B

and C

do have an equivalent and com-

patible object in S

, namely B

and C

; and ﬁnally,

though D

is equivalent to D

, they are not compat-

ible. Moreover, incompatible trace objects will con-

tain low-level information on the reasons that resulted

in the non-compatible relationship between the refer-

enced objects.

http://www.kybele.etsii.urjc.es/itracetool/

4 SERVICE CONTRACTS

The next step in demonstrating the suitability of MDE

techniques in a SOA setting, a similar approach to the

one described below is proposed to be applied to ex-

isting work on service contracts.

According to (Andrikopoulos et al., 2012), a ser-

vice contract is an intermediary construct interposed

between service providers and consumers, expressed

also in ASD form, which can be used to represent

a technical Service Level Agreement (SLA) between

them. The use of contracts allows for greater ﬂexibil-

ity in evolving both interacting parties (i.e., providers

and consumers) in a compatible manner. Further-

more, even the contract itself can evolve under certain

conditions. The fact that the authors (re-)use the ASD

notation and the subtyping relation discussed so far

provide an ideal setting for an extension of our ongo-

ing work.

4.1 Service Contracts Generation

Figure 4 provides an overview of the approach pro-

posed to produce a service contract from two given

versions of a service.

The ﬁrst step is supported by an ATL reﬁning

transformation (ASDRefine) that produces enriched

versions of the original ASD models representing

each version of the service. Such reﬁnement con-

sists of adding annotations to the elements of the ASD

model. Each annotation states whether there is a com-

patible element in the other ASD model for the one

ENASE2013-8thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

214

Figure 2: From ASD models to WSDL models.

Figure 3: Using trace models to represent service versions

compatibility.

being annotated. Consequently, each ASD model has

to be annotated with regard to the other ASD. That is,

S1 is annotated with regard to S2 and vice versa. As

a result, the S

and S

models are obtained.

To that end, the following annotations are deﬁned

(recall that they are added to the elements of the ASD

models). They are explained from the point of view

of S

. The same applies for S

• None: there is no equivalent in S

(there is no ele-

ment owning the same name with the same type).

• Equiv: there is an equivalent in S

. Note that this

annotation refers just to the element itself. Noth-

ing is said about its nested elements of attributes.

• Super: the element is a super-type of an element

in S

. That is to say that the number of elements

nested in the annotated one is greater or equal than

the number of elements of the corresponding ele-

ment in S

. Besides, such nested elements are

more generic than those of the corresponding ele-

ment and the value of its attributes are greater or

equal than the value of the attributes of the corre-

sponding element.

• Sub: the element is a sub-type of an element in

. The conditions that must hold can be derived

from inverting those described for super-type an-

notated elements.

Next, the annotated ASDs are consumed by an-

other ATL transformation (ASD2Contract) that pro-

duces a new ASD representing the service contract.

Such contract will contain one element of every

pair of equivalent elements found in S

and S

plus

some of those elements for which no equivalent was

found. This ASD model can be seen as an interme-

diary construct in the form of a service contract in-

terposed between service providers and consumers. It

allows for greater ﬂexibility in evolving both parties

in a compatible manner as they relax some of the as-

sumptions regarding the ability of services to evolve

while preserving their compatibility (Andrikopoulos

et al., 2012).

SupportingServiceVersioning-MDEtotheRescue

215

Figure 4: Service contract generation.

4.2 Tracking Service Contracts

Generation

Finally, following the idea collected in Section 3, the

relationships between the contract and the two service

versions are planned to be collected in a trace model.

This would help decisively to get at a ﬁrst sight which

the problematic elements in the two versions being

compared are: by selecting a given element in the

contract, the user would be automatically informed of

which elements in S

and S

are compatible with the

selected element (if they exist).

To that end, four types of traces are considered.

They correspond to the four types of annotations in-

troduced in the previous section: None, Equiv, Sub

and Super. The idea is illustrated in Figure 5: in this

case, by selecting the B element in the contract (C.B),

the user would know that there are compatible ele-

ments both in S

and S

(namely, S

and S

By contrast, the selection of A would show that there

is no equivalent element in S

In addition, ﬁlters can be deﬁned over the trace

model (TrC) to show just compatible, non-compatible

or whichever selection of elements. In other words,

the traces model relating S

, S

and C can be ﬁltered

applying MDE-techniques, such as merging or trans-

formation (Bernstein, 2003), to produce ad-hoc trace

models. Those models might contain just those traces

referring to the compatible or incompatible elements

of S

, S

and C.

Note that the trace model (TrC) relating the con-

tract and the service versions would be automatically

produced by the transformation that generates the

contract. That is, the ASD2Contract transformation

shown in Figure 4 consumes S

1→2

and S

2→1

and pro-

Figure 5: Tracking service contract generation.

duces the C contract model and the TrC trace model.

To that end, the ATL transformation is enriched

with the necessary machinery to support the produc-

tion of trace models (Jouault, 2005). The maturity

reached by some MDE tools allows the implemen-

tation of this kind of model-based implementations

(Volter, 2011).

Furthermore, the contract and the trace model

could be used to produce new versions of the ser-

vice that ensure compatibility by fulﬁlling the con-

tract since the contract deﬁnes the requirements that a

service version has to meet to be compatible regard-

ing the consumers.

5 CONCLUSIONS

This work sets the following steps to take in order

to provide a complete framework to support service

evolution by means of MDE techniques. In particu-

lar, it deﬁnes three main directions for future work:

the development of technological bridges to move be-

tween WSDL ﬁles to Abstract Service Descriptions;

the modeling of the output of service versions com-

patibility assessment as trace models; and the genera-

tion and tracking of service contracts (in the sense of

Server Level Agreements).

The underlying basis of the proposal is a theoreti-

cal framework that allows the formal deﬁnition of the

conditions under which the evolution of service in-

terfaces respects service compatibility. Such frame-

work depends on formal models for the representa-

tion of service interfaces that draw from a common

ENASE2013-8thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

216

metamodel. In this context, the application of MDE

techniques results ideal to provide with a prototype

supporting the theoretical framework.

All in all, this paper is another stage in a research

line initiated in previous works that demonstrates the

synergy between MDE and SOA by discussing how

a service-based theoretical framework can be imple-

mented by means of MDE techniques and tools. The

premise is that almost any SE problem can be ex-

pressed in terms of MDE since almost every software

artifact could be abstracted as a model. Once there,

one can beneﬁt from the advantages brought by MDE

in the form of less costly, rapid software development

by leveraging the level of automation in the develop-

ment process.

ACKNOWLEDGEMENTS

This research has been carried out in the frame-

work of the MASAI project (TIN-2011-22617) and

the Technical Support Staff Subprogram (MICCINN-

PTA-2009), which are partially ﬁnanced by the Span-

ish Ministry of Science and Innovation.

REFERENCES

Andrikopoulos, V., Benbernou, S., and Papazoglou, M.

(2012). On the evolution of services. Software En-

gineering, IEEE Transactions on, 38(3):609–628.

Bernstein, P. (2003). Applying model management to clas-

sical meta data problems. In First Biennial Confer-

ence on Innovative Data Systems Research, pages 1–

10, Asilomar, CA, USA.

Jouault, F. (2005). Loosely coupled traceability for atl. In

Proceedings of the Traceability Workshop of the First

European Conference on Model Driven Architecture

- Foundations and Applications (ECMDA-FA 2005),

volume 91, pages 29–37, Nuremberg, Germany.

Jouault, F., Allilaire, F., B

ezivin, J., and Kurtev, I. (2008).

ATL: A model transformation tool. Science of Com-

puter Programming, 72(1-2):31–39.

Jouault, F., B

ezivin, J., and Kurtev, I. (2006). TCS: a DSL

for the speciﬁcation of textual concrete syntaxes in

model engineering. In Proceedings of the 5th inter-

national conference on Generative programming and

component engineering, GPCE ’06, pages 249–254,

New York, NY, USA. ACM.

Meyer, B. (1997). Object-oriented software construction

(2nd ed.). Prentice-Hall, Inc., Upper Saddle River,

NJ, USA.

Papazoglou, M. and van den Heuvel, W.-J. (2007). Ser-

vice oriented architectures: approaches, technologies

and research issues. The VLDB Journal The Interna-

tional Journal on Very Large Data Bases, 16(3):389–

415. 10.1007/s00778-007-0044-3.

Santiago, I., Jim

enez, A., Vara, J. M., De Castro, V., Bollati,

V., and Marcos, E. (2012). Model-Driven Engineering

As a New Landscape For Traceability Management:

A Systematic Review. Information and Software Tech-

nology, 54(12):1340–1356.

Schmidt, D. C. (2006). Model-Driven Engineering. IEEE

Computer, 39(2):25–31.

Vara, J. M., Andrikopoulos, V., Papazoglou, M. P., and Mar-

cos, E. (2012). Towards model-driven engineering

support for service evolution. Journal of Universal

Computer Science, 18(17):2364–2382.

Volter, M. (2011). From Programming to Modeling - and

Back Again. Software, IEEE, 28(6):20–25.

W3C (2001). Web services description language (wsdl)

v1.1. http://www.w3.org/TR/wsdl.

Wimmer, M. and Kramler, G. (2006). Bridging grammar-

ware and modelware. In Proceedings of the 2005 in-

ternational conference on Satellite Events at the MoD-

ELS, MoDELS’05, pages 159–168, Berlin, Heidel-

berg. Springer-Verlag.

SupportingServiceVersioning-MDEtotheRescue

217