Towards a MaaS Service for Cloud Service Interoperability

Nour El Houda Bouzerzour

1,2 a

and Yahya Slimani

1,3

LISI Laboratory of Computer Science for Industrial Systems, Carthage University, Tunis, Tunisia

ENSI, La Manouba University, Manouba, Tunisia

ISAMM, La Manouba University, Manouba, Tunisia

Keywords:

Cloud Computing, Cloud Service Description, Service Interoperability, Transformation Rules, ATL, WSDL.

Abstract:

Cloud computing is an emerging computing paradigm, which provides high service availabality, high scala-

bility as well as low usage costs. This has encouraged enterprises and individual users to embrace cloud tech-

nology. However, the lack of service interoperability (also known as the vendor lock-in) issue still persists.

The vendor lock-in is caused by the cloud service providers who aim to prevent the clients from switching to

other clouds or providers. The solutions to overcome the vendor lock-in addressed a speciﬁc cloud actor or a

speciﬁc cloud model, which makes them not generic. Thus, we present in this paper, our Cloud Interoperabil-

ity Pivot Model (CIPiMo). CIPiMo is a Model-as-a-Service, which standardizes the cloud service description

languages by transforming them into a Generic Cloud Service Description model (GCSD) to make them in-

teroperable. We rely on MDE techniques to achieve a Model-to-Model transformation. Therefore, we deﬁne

mappings between the source description languages (OWL-S and WSDL) and the target language (GCSD).

Furthermore, we illustrate our proposed meta-models for each language and we implement our transforma-

tions using ATL with OCL. Eventually, we use a static analyzer (AnATLyzer IDE) to validate the correctness

of our transformations. We provide use cases to demonstrate the applicability of our approach.

1 INTRODUCTION

Cloud computing has known a huge spread and

popularity among providers and clients. The reason

being that cloud computing offers an on-demand

access to a pool of shared computing resources (Liu

et al., 2011) with high availability and scalability, as

well as in a ”pay-as-you-go” fashion. Despite the

numerous advantages of cloud computing, providers

and clients are still hesitant to adopt it because of

its prominent obstacles. The security and privacy

concerns, the service recovery from disastrous

situations and the SLA management are among these

obstacles. However, the most prominent issue is the

lack of cloud service interoperability. The latter is

deﬁned as the ability of heterogeneous systems to

communicate, whether they are deployed on the same

cloud or on multiple clouds (Opara-Martins et al.,

2014). The cloud providers, who offer proprietary

services and decline standardization, are causing the

service interoperability issue. This is also known as

the vendor lock-in, where the providers prevent the

clients from switching from one provider to another

https://orcid.org/0000-0002-8785-6631

or from one cloud to another in interconnected cloud

environments (Opara-Martins et al., 2014). The

solutions that were proposed in the literature (such

as brokers, standards and semantic approaches)

either target a single cloud actor (client or provider),

they are speciﬁc to a certain technology, or they

do not address all the cloud models (SaaS, PaaS,

IaaS). Therefore, these approaches are not generic

(Bouzerzour et al., 2020b). Other solutions such

as RESTful APIs and gRPC are widely adopted

to enable systems’ interoperability. However, they

are still faced with issues. The semantic REST

APIs are not adopted or recognized by commonly

used tools (Cheron et al., 2019). Furthermore, the

communication between two cloud systems using

different protocols (e.g: REST HTTP protocol and

MQTT (Message Queuing Telemetry Transport)

protocol) requires a protocol adapter to happen.

Eventually, The use of RESTful APIs does not solve

the semantic inconsistencies, which are created by

adopting heterogeneous cloud systems’ descriptions

(Baudoin et al., 2014).

Therefore, in this paper, we propose a cloud service

interoperability approach based on the standardiza-

Bouzerzour, N. and Slimani, Y.

Towards a MaaS Service for Cloud Service Interoperability.

DOI: 10.5220/0010911400003119

In Proceedings of the 10th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2022), pages 72-83

ISBN: 978-989-758-550-0; ISSN: 2184-4348

tion of cloud service descriptions. Thus, we deﬁne

the following research hypothesis:

RH1: the heterogeneity of cloud service descriptions

is among the reasons causing the vendor-lock-in,

RH2: standardizing service descriptions will allow

their interoperability.

To enable the standardization of cloud service de-

scriptions, the authors of (Ghazouani and Slimani,

2017) proposed a Generic Cloud Service Description

model (GCSD). The GCSD describes cloud services

in a standardized and comprehensive manner (from

multiple aspects), which was demonstrated by

use case scenarios that describe different services

from different delivery models (SaaS, PaaS, IaaS)

(Ghazouani and Slimani, 2017). Therefore, we

rely on an MDE model-to-model transformation

technique to transform heterogeneous description

languages to the GCSD to make them standardized

and interoperable. MDE is a software engineering

approach, which uses human and machine-readable

models. MDE considers models as ﬁrst class entities

to express speciﬁcations of systems at different levels

of abstraction. The model’s elements, the relations

between them and their constraints are described

by a meta-model (Bezivin et al., 2005). We rely on

MDE because it is expected to gain more growth in

the software industry, as it was stated and approved

by various high quality research and studies that

MDE is indeed able to provide effective and helpful

solutions to improve the software development

process (Brambilla et al., 2017).

Figure 1: Our proposed interoperability model CIPiMo

(Bouzerzour et al., 2020a).

In this paper, we present an overview of our in-

teroperability model, which we name CIPiMo (Cloud

service Interoperability Pivot Model). Furthermore,

we implement, validate, and we test our MaaS pivot

model by providing use cases for different description

languages.

The rest of this paper is organized as follows: In Sec-

tion 2, we present our MaaS pivot model CIPiMo.

Whereas is Section 3, we present the mappings of the

source description languages to the GCSD as well as

their meta-models. In Section 4 we implement our

transformation rules, and we discuss the results. Sec-

tion 5 discusses the static validation of our transfor-

mations using AnATLyzer. In Section 6, we present

the related works and in Section 7 we conclude this

paper.

2 CLOUD SERVICE

INTEROPERABILITY PIVOT

MODEL (CIPiMo)

CIPiMo is an MDE-based MaaS (Model as a Ser-

vice) service (aka. Modeling as a Service), which

enables cloud service interoperability by transform-

ing heterogeneous service descriptions into a GCSD.

MaaS is a SaaS variant (Software as a Service), which

allows users to deploy and execute model-driven and

modeling services over the Internet, and it provides

an interface for the client to communicate with the

services. Among the main contributions of MaaS

is enabling interoperability between tools and sys-

tems by bridging the gaps between their speciﬁca-

tions (Bruneliere et al., 2010). Thus, CIPiMo aims to

overcome the vendor lock-in by promoting: (i) client-

centric interoperability, which allows enterprises or

end-users to adopt a multi-cloud strategy to inter-

operate their services, which are deployed on dif-

ferent providers or clouds, and it encourages enter-

prises to migrate their legacy systems to the cloud

(Bouzerzour et al., 2020b); and (ii) provider-centric

interoperability, which enables cloud federations be-

tween SME (Small and Medium Enterprises) service

providers to gain more computing power and scal-

ability, or hybrid cloud strategy for bursting the re-

sources at peak moments (Bouzerzour et al., 2020b).

This transformation mediator maps the concepts and

elements of source languages to the GCSD concepts.

Then, it applies a set of transformation rules to trans-

form the source language into the generic descrip-

tion. Hence, the service descriptions will be uni-

ﬁed and interoperable. We chose a transformation

through a pivot rather than a direct transformation

from a source language to a target language because

it requires fewer transformations, especially if the

number of languages to be transformed is substan-

tial (Boukhari et al., 2012). Figure 1 presents an

overview of CIPiMo: in the cloud environment, ser-

vice providers describe their services using different

CSD languages (such as OWL-S and WSDL), which

will be transformed using CIPiMo by applying the

transformations corresponding to the proposed map-

Towards a MaaS Service for Cloud Service Interoperability

pings for each language. Then, the resulting descrip-

tions will be standardized and ready to be published.

The mapping phase is achieved by the manual ex-

traction of different elements and their corresponding

deﬁnitions from the corresponding speciﬁcation doc-

ument of each language. Then, we align the source

element with its equivalent target element.

To demonstrate the functionality of our proposed

pivot model we provide use cases, which transform

WSDL and OWL-S service descriptions to the GCSD.

We fully recognize that WSDL and OWL-S were

not originally created for describing cloud services.

However, both of these languages were used by re-

searchers, who considered cloud services as web ser-

vices, to describe cloud services (Ghazouani and Sli-

mani, 2017). In (Zhou et al., 2011), the authors used

WSDL-S for semantically describing services for

SaaS discovery. Whereas, in (Goscinski and Brock,

2010), a WSDL ﬁle extension was proposed to take

into consideration cloud characteristics. OWL-S was

used in (Martino et al., 2014) to semantically describe

Microsoft Azure API functional and non functional

properties and it was also used in (Karim et al., 2014)

to deﬁne cloud services and their Quality of Service

(QoS). Moreover, the available cloud service descrip-

tion and modeling approaches that were presented in

the literature (such as (Bergmayr et al., 2014) (Perez

and Rumpe, 2014) (Andrikopoulos et al., 2014)) ad-

dressed the description of the deployment, the con-

ﬁguration, and the provisioning of the cloud service

rather than the description of the service properties

and functionality. Furthermore, the majority of the

cloud description and modeling languages lack for-

mal documentation or speciﬁcation documents to de-

ﬁne in details their constructs and elements. Unlike

that, WSDL and OWL-S are thoroughly documented

in their speciﬁcation documents (Christensen et al.,

2001) (Martin et al., 2004). Moreover, many legacy

systems were based upon these languages and they

provide all the basic required concepts to describe a

service and to demonstrate our proposal. Therefore,

in the aim of demonstrating the genericity of our pivot

model, we chose to run our interoperability model on

WSDL (which is a syntactic language) and on OWL-

S (which a semantic language), respectively, to unify

their description and make them interoperable.

3 PROPOSED MAPPING RULES

In this section we present the mappings from WSDL

and OWL-S to the GCSD. Furthermore, we illustrate

our proposed exhaustive meta-models for each lan-

guage. To model the description languages meta-

models we use Eclipse Modeling Framework (EMF)

ECORE meta-model as the de-facto standard model-

ing framework in the industry.

3.1 Mapping WSDL to GCSD

WSDL (Web Services Description Language) (Chris-

tensen et al., 2001) is an XML format to describe web

services as collections of network endpoints operat-

ing on messages. To deﬁne network services, WSDL

1.1 uses, mainly, six elements, which are Types, Mes-

sage, PortType, Binding, Port; and Service. However,

WSDL only describes services from a technical as-

pect. Figure 2 depicts, our proposed WSDL meta-

model, which illustrates all WSDL elements required

to describe a service and the relations between them.

Table 1 depicts the proposed mapping from WSDL to

GCSD.

As depicted in Table 1, the WSDL operation el-

ement, which describes the operations that are per-

formed by the service, is transformed into the Func-

tion concept in the GCSD, which in its turn de-

scribes a course of actions to be performed by the

service. Each message part element is trans-

formed into a Parameter instance as they both

describe the parameters required by the opera-

tion/Function. The input and output are

also mapped to Parameter concept because they

deﬁne the abstract messages formats. PortType de-

scribes a set of abstract operations and it describes

the abstract message that is involved in the operation.

Therefore, it is mapped to the abstract class Inter-

face. Binding, which deﬁnes a concrete protocol

for the operations deﬁned in a portType is mapped to

Protocol. The operation name and the part

name are mapped to the concept Description,

which attaches typed textual descriptions to the other

concepts (in this case, names are Description objects

of type name). Import location, port lo-

cation, and definition targetNameSpace

are all mapped to Artifact URI, which represents

a link to a resource that can be located using a URI.

We do not deﬁne mappings for message because

it provides an abstract deﬁnition of the data being

transmitted by its parts; it is presented as an argument,

which is mapped to a method invocation. Therefore,

the mapping of the different part elements of the

enclosing message implies the mapping of the mes-

sage element.

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

Table 1: Mapping WSDL elements and OWL-S classes into the GCSD concepts.

WSDL elements Description GCSD concepts

deﬁnition It is the root element of all WSDL documents. It de-

ﬁnes the name of the web service.

- GCSDservice (root con-

cept)

service A service groups a set of related ports together ServiceModule Service

part It deﬁnes the parameters of the web service function. FunctionalModule Parameter

operation It is a transmission primitive that an endpoint can sup-

port.

Function

input It speciﬁes the abstract message format for an opera-

tion.

Parameter

output It speciﬁes the abstract message format for an opera-

tion.

Parameter

fault It speciﬁes the abstract message format for any error

messages that may be output as the result of the oper-

ation.

Fault

portType It is a set of abstract operations. TechnicalModule Interface

binding It speciﬁes the concrete protocol and data format

speciﬁcations for the operations and messages deﬁned

by a particular portType.

Protocol

soap:binding: trans-

port

It indicates the SOAP transport that the binding cor-

responds to.

AccessProﬁle

operation:name It is an operation name, which is not required to be

unique.

FoundationModule Description: value

types It is a data type deﬁnitions used to describe the mes-

sages exchanged.

TypeReference

import: location It associates a namespace with a document location. Artifact:URI

port: location It is an address for a binding and it deﬁnes a single

communication endpoint.

Artifact: URI

Figure 2: Our proposed WSDL meta-model.

3.2 Mapping OWL-S to GCSD

OWL-S (Martin et al., 2004) is an ontology for web

service description, which is based on three sub-

ontologies: (i) serviceProﬁle, (ii) serviceModel; and,

(iii) Grounding. However, it lacks the business aspect

of the service. Our proposed OWL-S meta-model

is depicted in Figure 3. Whereas, the mappings of

OWL-S classes to GCSD concepts were detailed in

(Bouzerzour et al., 2020a).

Towards a MaaS Service for Cloud Service Interoperability

Figure 3: Our proposed OWL-S meta-model.

We also deﬁne a meta-model for the GCSD. Given

that the GCSD is based on Uniﬁed Service Descrip-

tion Language (USDL) (Barros and Oberle, 2012),

it has nine concepts to represent USDL’s modules.

Furthermore, each concept regroups sub-concepts.

Therefore, we do not include it the GCSD meta-model

in this paper for space reasons.

4 IMPLEMENTING

TRANSFORMATION RULES

We rely on Atlas Transformation Language (ATL)

(Jouault et al., 2008) to implement the transforma-

tion rules. ATL is a domain-speciﬁc language for uni-

directional Model-to-Model (M2M) transformations,

which provides declarative and imperative constructs.

Moreover, ATL is built upon Object Constraint Lan-

guage (OCL) (Cabot and Gogolla, 2012), which is an

OMG standard and a typed declarative language.

Therefore, in this section we present our imple-

mentation using ATL and we deﬁne OCL invariants

for WSDL and OWL-S. However, we do not deﬁne

any constraints for the GCSD, as it is based on USDL,

which does not specify any constraint to allow open-

ness and genericity. Otherwise, specifying constraints

for speciﬁc types will result in enlarging USDL core

model with the complex and overlapping constraints

(Barros and Oberle, 2012). To implement our trans-

formations we use ATL toolkit (Version 4.2.0) on

top of Eclipse IDE (Version: 2020-12 (4.16.0)). We

also use ATLauncher (Guana, 2015) to programmati-

cally launch our transformations. ATLauncher is stan-

dalone Java class that runs ATL M2M transforma-

tions outside the Eclipse to promote the integration

of MDE tools with other software engineering solu-

tions. Therefore, using ATLauncher, our transforma-

tions will be integrated into a JAVA application, which

will be offered as a MaaS service to allow cloud ser-

vice interoperability.

4.1 Transformation Rules from WSDL

to GCSD

Figure 4 depicts the implemented transformation

rules from WSDL to GCSD and Figure 5 presents the

OCL constraints that we implemented for our trans-

formation.

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

Figure 4: WSDL transformation rules.

Figure 5: OCL constraints for WSDL transformation.

As it is shown in Figure 4, rule deﬁni-

tion2GCSDservice transforms the WSDL defini-

tion, which is the root element of the service de-

scription to GCSDservice concept with the deﬁ-

nition name represented by the GCSDservice name

and the targetNamespaces is represented by the

Artifact concept’ attribute URI. The constraint

states that a deﬁnition may have an optional but

unique name. Next, rule import2Artifact transforms

the import element to the Artifact concept,

which provides a URI property to locate a resource.

The rule part2Parameter depicts the transformation of

the WSDL part class and its type to Parame-

ter concept and TypeReference concept, which

represents the parameter type using unitSymbol

property. The part name is transformed to the De-

scription concept’s value attribute. Then, the

rule Operation2Function transforms WSDL oper-

ation to Function concept. The operation’s

input, output and fault properties are de-

scribed by the GCSD relations inputs, out-

puts, and faults, respectively; and the opera-

tion name is described by the value property of the

Description concept.

For the concrete description of WSDL services,

the rule service2Service transforms of the service

class and the service name to the GCSD Ser-

vice concept and the property serviceName re-

spectively. The rule soapbinding2Protocol transforms

the binding transport to the Protocol concept

identifier. Eventually, the PortType2Interface

rule transforms WSDL portType and port ele-

ments to Interface concept, the port binding

is transformed to Interface’s implementation-

Towards a MaaS Service for Cloud Service Interoperability

Figure 6: WSDL description of StockQuoteService service.

Figure 7: StockQuoteService service description in GCSD.

Specification and the portType name is trans-

formed to the implementationTypeId property,

which references the service interface.

To test our transformation, we apply our trans-

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

Figure 8: OCL constraints for OWLS- transformation.

formation rules on WSDL ”StockQuote” service in-

stance, which is illustrated in ﬁgure 6. After ap-

plying our transformation, we get the following de-

scription in GCSD (XMI ﬁle) (as shown in Figure 7).

As depicted in Figure 7, the GCSDService is the

main concept, which is located in the URI (described

by the Artifact). The second Artifact URI de-

scribes the WSDL schema nameSpace. Two Param-

eters are described, with their names (described by

Description), their type (described by TypeR-

eference), the type xsd schema URI (described

by Artifact). One Function is described with

its inputs and outputs and name (described by De-

scription). A Service is described with its

name and an Interface is also described with its

implementationSpeciﬁcation and its URI (described

by Artifact).

4.2 Transformation Rules from OWL-S

to GCSD

Figure 8 presents the OCL constraints that we imple-

mented for our transformation, and Figure 9 depicts

the implemented transformation rules from OWLS to

GCSD.

The rule service2GCSDservice transforms OWL-

S service and Profile classes into Service

and ContactProfile concepts to describe the

service’s name and general information. The rule

Process2Function transforms OWL-S Process (of

type AtomicProcess) and Participant (of type

TheClient) into Interaction, Function and

Consumer concepts, respectively. The hasPar-

ticipant property is transformed into invovle-

dRoles to describe the participant interacting with

the process and it also speciﬁes the roleDescrip-

tion for the Consumer concept. Whereas,

the hasInputs, hasOutput, ProcessPre-

condition, and ProcessResult properties

are transformaed into input, outputs, pre-

conditions, and postconditions, respec-

tively. The Paramter2Parameter rule transforms

OWL-S Parameter and its type (described by Pa-

rameterType attribute) into GCSD Parameter

and TypeReference (which describes the type us-

ing unitSymbol attribute) concepts.

The precondition2precondition rule transforms OWL-

S Condition and Expression into Condi-

tion concept, the OWL-S condition’s expression

(described by expr property) is transformed into

the conditionExpression property. The OWL-

S condition’s expression body (expressionBody

attribute) and expression language (expression-

Language attribute) are transformed into GCSD

Expression value and languageID, respectively.

The rule result2postcondition transforms the OWL-

S Result into GCSD Condition and the re-

sultID attribute into Description’s value attribute.

The rule grounding2Interface transforms OWL-S

grounding into Interface concept and the

grounding wsdlDocument attribute is transformed

into implementationTypeId attribute. The rule

theServer2provider transforms OWL-S participant of

type theServer into GCSD Provider. Even-

tually, the rule CompositeProcess2Phase transforms

OWL-S Process of type CompositeProcess into

GCSD Phase and the Process name is transformed

into Description’s value attribute.

We apply our transformation rules on OWL-S ”Con-

goBuyService” service instance, as shown in Fig-

ure 10. The resulting description in GCSD is de-

picted in Figure 11. The GCSDservice describes

the OWL-S service and its name. The capabili-

ties describe the Process achieved by the OWL-S

service. ContactProfile provides the contact in-

formation (described by Description). The In-

teraction describes the participants involved in

the atomicProcess and the Process is described by

the Function and its inputs, outputs, preconditions,

and postconditions. Consumer describes the partic-

ipants and their types (client or provider). Two Pa-

rameters are described with their types and names

(described by TypeReference and Descrip-

tion) and one Condition is described alongside

its Expression body and language. The Inter-

face describes the WSDL document for the ground-

ing using the implementationTypeId. OWL-

S CompositeProcess is composed of subprocesses

(atomic and composite) and it is constructed using

control constructs and references to processes called

PERFORMs. Therefore, the transformation of OWL-

S CompositeProcess requires deﬁning UML activity

for describing the control constructs, UML sequence

diagram for describing the compositions, and OCL

to specify the pre- / post-conditions required for the

composition (Bouzerzour et al., 2020a). Thus, this

transformation is out of the scope of this paper, and it

will be included in a future work.

Towards a MaaS Service for Cloud Service Interoperability

Figure 9: OWL-S transformation rules.

Figure 10: CongoBuy Bookselling service description in OWL-S.

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

Figure 11: CongoBuy Bookselling service description in GCSD.

4.3 Results Discussion

The whole process of implementing and testing our

proposed transformations proves the correctness of

our research hypothesis. Indeed, the heterogeneity

of service descriptions hinders the interoperability.

Offering services described using different, propri-

etary speciﬁcations promotes the vendor lock-in issue

(Opara-Martins et al., 2014). Furthermore, the pre-

liminary results that we obtained from transforming

WSDL to GCSD and OWL-S to GCSD are an evi-

dence that the uniﬁcation of service descriptions en-

ables their interoperability, combination, customiza-

tion, and composition (Nguyen et al., 2012).

5 STATIC VALIDATION OF ATL

TRANSFORMATIONS

Regardless of EMF being the de-facto standard mod-

eling framework in the industry, it is still faced with a

lack of an ofﬁcial validation and veriﬁcation tool for

EMF models with OCL constraints (Gonz

alez et al.,

2012). Only two tools were found in the literature: (i)

EMFtoCSP (Gonz

alez et al., 2012), which translates

the model and its constraints into a constraint satis-

faction problem, which is then solved by a constraint

solver. EMFtoCSP checks the strong satisﬁability, the

weak satisﬁability, the lack of constraint subsump-

tions and the lack of constraint redundancies in a

model. However, the tool, which was developed as

a research project, was not updated for several years.

Therefore, the tool stopped from running at times,

or it generated ambiguous results at other times; and

(ii) EFinder (Cuadrado and Gogolla, 2020), which

is a model ﬁnding tool that automatically searches

for models satisfying a set of the model’s OCL con-

straints. The approach enables EMF meta-model ver-

iﬁcation, veriﬁcation of model transformations, and

model synthesis. However, we did not get any results

from it. EFinder was originally running over AnAT-

Lyzer (Cuadrado et al., 2016), which is a transfor-

mation validation tool for the static analysis of ATL

model transformation. AnATLyzer is integrated with

ATL environment, and it is available as an Eclipse

plug-in, which enables the detection of typing and

rule errors, as well as a support for pre-conditions and

post-conditions. Therefore, we used AnATLyzer to

correct errors (such as unresolved bindings, uninitial-

ized features, rule conﬂicts, and others) in our trans-

formations.

Towards a MaaS Service for Cloud Service Interoperability

6 RELATED WORK

MDE-based approaches were proposed as solutions to

achieve the cloud service interoperability. In (Alipour

and Liu, 2018) the authors applied an MDE technique

to manage auto-scaling services. Their approach en-

ables the migration, deployment and conﬁguration

of services on multiple clouds. Ferry et al. pro-

posed CloudMF (cloud modeling framework) (Ferry

et al., 2013a), and they extended it in (Ferry et al.,

2014) with: (i) a provider-agnostic management so-

lution for applications that are deployed on IaaS and

PaaS; (ii) an eclipse-based editor for the textual syn-

tax alongside a web-based editor for the graphical

syntax; and (iii) remote access to models@run-time

reasoning engines. Furthermore, the authors proposed

a domain-speciﬁc modeling language (DSML) called

(CloudML) (Ferry et al., 2013b). Uni4Cloud was

proposed in (Sampaio and Mendonca, 2011) to au-

tomatically conﬁgure and deploy applications across

multiple clouds in an IaaS provider-agnostic manner.

Whereas, MODAClouds (Ardagna et al., 2012) was

proposed for service migration between clouds, and it

provides a cloud-agnostic software design, a decision

system to determine the most suitable cloud to deploy

a given component and a support for migrating legacy

software to the cloud. The approach in (Alipour and

Liu, 2018) is different from our approach because

the authors applied the transformation to transform

a CPIM (Cloud Platform Independent Model) to a

CPSM (Cloud Speciﬁc Platform Model) using EMF

model generation abilities. In (Ferry et al., 2013a)

(Sampaio and Mendonca, 2011), the authors adopted

MDE techniques to enable the management of de-

ployment, conﬁguration and provisioning of PaaS and

IaaS resources in multicloud. Whereas, in (Ardagna

et al., 2012), the authors used MDE to enable the

design and execution of applications on multicloud.

Therefore, none of the aforementioned approaches

applied MDE M2M technique to transform an input

model to an output model based on a set of transfor-

mation rules and constraints.

7 CONCLUSION

This paper presents CIPiMo, which is a MaaS based

on MDE to enable interoperability between cloud ser-

vices described using heterogeneous CSD languages.

The model enables the interoperability between ser-

vices of different cloud models and for different target

actors. The preliminary results that we obtained from

our use case scenarios are promising, and they reveal

that our model is capable of standardizing the descrip-

tions of heterogeneous cloud services. Therefore, it

enables their interoperability. As for future work, we

will extend our model by deﬁning the transformations

for other CSD languages. Eventually, using a cloud

simulation tool (for example: CloudSim) we will test

the performance criteria of our MaaS model.

REFERENCES

Alipour, H. and Liu, Y. (2018). Model Driven Deploy-

ment of Auto-Scaling Services on Multiple Clouds. In

IEEE International Conference on Software Architec-

ture Companion (ICSA-C), pages 93–96, Seattle, WA,

USA.

Andrikopoulos, V., Reuter, A., Xiu, M., and Leymann, F.

(2014). Design support for cost-efﬁcient application

distribution in the cloud. In 2014 IEEE 7th Interna-

tional Conference on Cloud Computing, pages 697–

704, Anchorage, AK, USA. IEEE.

Ardagna, D., Nitto, E. D., Casale, G., and Petcu, D. (2012).

MODAClouds: A Model-driven Approach for the

Design and Execution of Applications on Multiple

Clouds. In Proceedings of the 4th International Work-

shop on Modeling in Software Engineering, pages 50–

56, Zurich, Switzerland.

Barros, A. and Oberle, D. (2012). Handbook of service

description. USDL and Its Methods.

Baudoin, C., Dekel, E., and Edwards, M. (2014). Interop-

erability and portability for cloud computing: a guide.

Cloud Standards Customer Council, 1(1):1–31.

Bergmayr, A., Castilla, J. T., Neubauer, P., Wimmer, M.,

and Kappel, G. (2014). Uml-based cloud applica-

tion modeling with libraries, proﬁles, and templates.

In CloudMDE 2014: 2nd International Workshop

on Model-Driven Engineering on and for the Cloud

co-located with the 17th International Conference

on Model Driven Engineering Languages and Sys-

tems (MoDELS 2014), pages 56–65, Valencia, Spain.

CEUR-WS.

Bezivin, J., Bruneliere, H., Jouault, F., and Kurtev, I.

(2005). Model engineering support for tool interoper-

ability. In Workshop in Software Model Engineering

(WiSME’2005), Montego Bay, Jamaica.

Boukhari, I., Bellatreche, L., and Jean, S. (2012). An on-

tological pivot model to interoperate heterogeneous

user requirements. In International Symposium On

Leveraging Applications of Formal Methods, Veriﬁca-

tion and Validation, page 344–358, Heraklion, Crete,

Greece.

Bouzerzour, N. E. H., Ghazouani, S., and Slimani, Y.

(2020a). Cloud interoperability based on a generic

cloud service description: Mapping owl-s to the gcsd.

In 29th IEEE International Conference on Enabling

Technologies: Infrastructure for Collaborative En-

terprises (WETICE 2020), Basque Coast - Bayonne,

France.

Bouzerzour, N. E. H., Ghazouani, S., and Slimani, Y.

(2020b). A survey on the service interoperability in

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

cloud computing: Client-centric and provider-centric

perspectives. Software: Practice and Experience,

50(7):1025–1060.

Brambilla, M., Cabot, J., Wimmer, M., and Baresi, L.

(2017). Morgan & Claypool Publishers, 2 edition.

Bruneliere, H., Cabot, J., and Jouault, F. (2010). Com-

bining model-driven engineering and cloud comput-

ing. In Modeling, Design, and Analysis for the Ser-

vice Cloud-MDA4ServiceCloud’10: Workshop’s 4th

edition, Paris, France.

Cabot, J. and Gogolla, M. (2012). Object constraint lan-

guage (ocl): a deﬁnitive guide. In International School

on Formal Methods for the Design of Computer, Com-

munication and Software Systems, pages 58–90, Berti-

noro, Italy.

Cheron, A., Bourcier, J., Barais, O., and Michel, A. (2019).

Comparison matrices of semantic restful apis tech-

nologies. In International Conference on Web Engi-

neering, pages 425–440, Daejeon, Korea. Springer.

Christensen, E., Curbera, F., Meredith, G., and Weer-

awarana, S. (2001). Web services description lan-

guage (wsdl) 1.1. W3C note.

Cuadrado, J. S. and Gogolla, M. (2020). Model ﬁnding

in the emf ecosystem. Journal of Object Technology,

19(2).

Cuadrado, J. S., Guerra, E., and de Lara, J. (2016). Static

analysis of model transformations. IEEE Transactions

on Software Engineering, 43(9):868–897.

Ferry, N., Chauvel, F., Rossini, A., and Morin, B. (2013a).

Managing Multi-cloud Systems with CloudMF. In

Proceedings of the Second Nordic Symposium on

Cloud Computing & Internet Technologies, pages 38–

45, Oslo, Norway.

Ferry, N., Rossini, A., Chauvel, F., and Morin, B. (2013b).

Towards Model-Driven Provisioning, Deployment,

Monitoring, and Adaptation of Multi-cloud Systems.

In IEEE Sixth International Conference on Cloud

Computing, pages 887–894, Santa Clara, CA, USA.

Ferry, N., Song, H., Rossini, A., and Chauvel, F. (2014).

CloudMF: Applying MDE to Tame the Complexity of

Managing Multi-cloud Applications. In IEEE/ACM

7th International Conference on Utility and Cloud

Computing, pages 269–277, London, United King-

dom.

Ghazouani, S. and Slimani, Y. (2017). Towards a standard-

ized cloud service description based on usdl. Journal

of Systems and Software, 132:1–20.

Gonz

alez, C. A., B

uttner, F., Claris

o, R., and Cabot, J.

(2012). Emftocsp: A tool for the lightweight veriﬁca-

tion of emf models. In First International Workshop

on Formal Methods in Software Engineering: Rigor-

ous and Agile Approaches (FormSERA), pages 44–50,

zurich, switzerland.

Goscinski, A. and Brock, M. (2010). Toward dynamic and

attribute based publication, discovery and selection

for cloud computing. Future generation computer sys-

tems, 26(7):947–970.

Guana, V. (2015). Atlauncher.

https://github.com/guana/ATLauncher.

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.

Karim, R., Ding, C., Miri, A., and Liu, X. (2014). End-to-

end qos mapping and aggregation for selecting cloud

services. In 2014 International Conference on Collab-

oration Technologies and Systems (CTS), pages 515–

522, Minneapolis, Minnesota, USA. IEEE.

Liu, F., Tong, J., Mao, J., and Bohn., R. (2011). Nist cloud

computing reference architecture. NIST special publi-

cation.

Martin, D., Burstein, M., Hobbs, J., and Lassila, O. (2004).

Owl-s: Semantic markup for web services. W3C mem-

ber submission, 22(4).

Martino, B. D., Cretella, G., Esposito, A., and Speran-

deo, R. G. (2014). Semantic representation of cloud

services: a case study for microsoft windows azure.

In 2014 International Conference on Intelligent Net-

working and Collaborative Systems, pages 647–652,

Salerno, Italy. IEEE.

Nguyen, D., Lelli, F., Papazoglou, M., and Heuvel, H. V. D.

(2012). Blueprinting approach in support of cloud

computing. Future Internet, 4(1):322–346.

Opara-Martins, J., Sahandi, R., and Tian, F. (2014). Criti-

cal review of vendor lock-in and its impact on adop-

tion of cloud computing. In International Conference

on Information Society (i-Society 2014), pages 92–97,

London, UK.

Perez, A. N. and Rumpe, B. (2014). Modeling cloud

architectures as interactive systems. arXiv preprint

arXiv:1408.5705.

Sampaio, A. and Mendonca, N. (2011). Uni4cloud: An

Approach Based on Open Standards for Deployment

and Management of Multi-cloud Applications. In Pro-

ceedings of the 2Nd International Workshop on Soft-

ware Engineering for Cloud Computing, pages 15–21,

Waikiki, Honolulu, HI, USA.

Zhou, J., Abdullah, N. A., and Shi, Z. (2011). A hybrid p2p

approach to service discovery in the cloud. Interna-

tional Journal of Information Technology and Com-

puter Science, 3(1):1–9.

Towards a MaaS Service for Cloud Service Interoperability