A model-driven approach for promoting Cloud PaaSPortability

Elias Adriano Nogueira da SilvaUniversity of São Paulo(USP-ICMC), São Carlos, Brazil

http://eliasadriano2010.appspot.com/

Renata P. M. FortesUniversity of São Paulo(USP-ICMC), São Carlos, Brazil

renata@icmc.usp.br

Daniel LucrédioFederal University of São Carlos(UFSCar), São Carlos, Brazil

http://www.dc.ufscar.br/ daniel

December 10, 2013

Abstract

Cloud computing has become an important re-search subject in software engineering. Amongthe many research gaps related to this new com-puting model is the lack of portability betweencloud platforms, which generates the Lock-Inproblem. The Lock-In is the difficulty in migrat-ing data and applications from a cloud platformto another. Current attempts to address this prob-lem revolve around standardization of APIs andframeworks. We propose a different path, usingmodel-driven engineering (MDE). We selectedtwo cloud platforms and built a DSL and a set ofautomated transformations that generate code foreach platform, based on a single portable model.We present the results of two studies. In a firststudy, subjects were asked to use the two versionsof the same application, each one generated for adifferent platform from a single model. The sub-jects did not notice any difference between thetwo versions in terms of functionality. In a sec-ond study, we observed that besides facilitatingcloud portability, MDE can increase productiv-ity and reusability. These results indicate thatMDE may be an alternative to standardization,not only helping to solve portability problems butalso leading to additional benefits.

Copyright c© 2013 The authors. Permission to copy ishereby granted provided the original copyright notice is re-produced in copies made.

1 Introduction

The concept of cloud computing has gained re-cent attention mainly because of the industry’sinitiative. It was only recently that the academiccommunity started to look at these technologiesmore carefully. Although still in the stage ofgaining maturity, the cloud quickly became animportant research subject in software engineer-ing. Among the research opportunities related tosoftware engineering for the cloud [3] [28], theData Lock-In problem stands out. Data Lock-Inis the difficulty of extracting data and programsfrom one platform to use in another, and is causedby the difference between platforms [3]. Thelack of portability that generates the Lock-In ishindering the cloud adoption. The developmentcommunity is afraid of creating their systems us-ing some specific technology and then start beingcharged unfair rates for its use, or even becomestuck with a technology that may turn out to beinadequate and needs to be abandoned [3].

Some efforts to address this problem can befound in the literature. Most try to establish stan-dards for developing cloud-related technologies[28]. If enough cloud service providers success-fully adhere to the standards, applications couldthen be more easily ported between them. In thiswork, however, we suggest the use of Model-Driven Engineering (MDE). With MDE, soft-ware engineers can work on a higher abstrac-tion level, in conceptual models that best capturethe essence and logic of the application. Appli-

cations can be generated by automated transfor-mations, thus freeing developers from the com-plexity required for implementation on differentplatforms [11]. By allowing developers to fo-cus most of their efforts on platform-independentdevelopment, the Lock-In problem can be effec-tively reduced, or even avoided at all. The choicefor MDE over standardization is justified by theadditional benefits brought by this approach. Thepromises of higher quality and productivity [15]could leverage cloud adoption at the same timethe Lock-In problem is addressed.

This paper presents a simple textual domain-specific language (DSL) that allows the specifi-cation of applications at a high abstraction level.We also present the results of a code generationprototype, built to support Google’s App Engine(GAE) and Microsoft Azure platforms. The pro-totype demonstrates that the developed language,despite being simple, can be used as input toa full code generation process targeting a cloudplatform. In the future, we expect to build gener-ators for other platforms from the same language,thus helping to improve the portability for otherones.

The remainder of the paper is organized asfollows: Section 2 presents concepts relatedto cloud computing. It also discusses theData Lock-In problem and some types of cloudportability identified in the literature; Section 3presents the methodology followed to developthis work. Section 4 presents the development ofthe model-driven approach for promoting cloudPaaS portability and discusses some character-istics of the cloud providers selected for thisresearch, as well as, the code generation pro-cess for each platform. Section 5 presents twostudies performed for evaluate the developed ap-proach. Section 6 presents related work. Section7 presents some concluding remarks and futurework. Finally, section 8 presents our acknowl-edgements ans simplified biographies.

2 Background

Cloud Computing has the potential to revolu-tionize the way systems are developed and mar-keted. Research related to developing applica-tions for the cloud is relatively new. Many stud-ies in the literature are results of research ef-forts that propose an appropriate formal defini-tion for this technology [28]. However, thereare still many inconsistencies on definitions andquestions about the concepts and services offered

by cloud providers, as well as its use [3].In relation to service offers, several cloud com-

puting taxonomies were suggested. Many wereconceived under a business perspective [25] andinclude terms such as Haas (Hardware as a Ser-vice), PaaS (Platform as a Service), DaaS ([De-velopment, Database, Desktop] as a Service),IaaS (Infrastructure as a Service), Baas (Busi-ness as a Service), Faas (Framework as a Ser-vice) or even the generic XaaS (Everything as aService). The definitions behind those terms arevery wide and sometimes misunderstood [3], butthere are three categories that seem to be morewell established:

(i)Software-as-a-Service - SaaS: refers to ap-plications that are delivered to customers in theform of services over the Internet [3, 18]. ASaaS normally operates over a cloud infrastruc-ture, but this is not necessary. Examples of SaaSinclude: Google Drive1, Flickr2, Picasa3, Sky-Drive4, among others.

(ii)Platform-as-a-Service - PaaS: the idea isto provide a full software development platformas a service, including an execution environment,frameworks and different useful integrable ser-vices [25, 18]. Normally, the service also in-cludes hosting, testing and a distribution channelor market. Some examples are: Google App En-gine5 and Microsoft Azure6, among others.

(iii)Infrastructure as a Service - IaaS: con-sists in delivering computational infrastructure asa service [25, 18]. The customer acquires - andpays by demand - services for processing, stor-age and other fundamental computing resources,making it possible to deploy and run any soft-ware, including operating systems and applica-tions. Some examples of IaaS include: Amazon7,GoGrid8, IBM SmartCloud9, among others.

Many technological requirements are neededfor these models to operate properly. Virtual-ization technologies, standards and interfaces al-low shared access to virtual servers. In fact, theconcept of cloud did not arise as a new technol-ogy model, but as the integration of technologiesfrom the past [6], which resulted in a new wayto use and provide computing power as a service

1Google Drive: http://drive.google.com/2Flickr: http://www.flickr.com/3Picasa: http://picasa.google.com/4SkyDrive: http://skydrive.live.com/5GAE: http://code.google.com/appengine6Windows Azure: http://www.windowsazure.

com/7Amazon:http://aws.amazon.com/pt/ec2/8GoGrid: http://www.gogrid.com/9http://www.ibm.com/cloud-computing/

through the Internet. The main ideas behind thisconcept are: to allow companies to acquire com-puting resources by demand; to enable paymentaccording to the utilization volume; and to makeit possible for a company to completely ignorethe knowledge about where these resources comefrom [3].

There is still no widely accepted academic def-inition for cloud computing [32, 6]. Vaqueroet al. [30] made a thorough study on variousdefinitions found in the literature to achieve amore complete definition. Although it is still aproposal, their definition is consistent and com-plete, and therefore is the one used in this work:“Clouds are a large pool of easily usable and ac-cessible virtualized resources (such as hardware,development platforms and/or services). Theseresources can be dynamically reconfigured to ad-just to a variable load (scale), allowing also foran optimum resource utilization. This pool of re-sources is typically exploited by a pay-per-usemodel in which guarantees are offered by theInfrastructure Provider by means of customizedSLAs” [30].

This definition, like others found in literature,cites resources in a generic way, as the elementsthat comprise the cloud infrastructure. This isthe important point regarding this study, as itsuggests a great heterogeneity in these environ-ments, in the sense that the resources used in thecloud can be of different types. The applicationsthat use its technologies must also be diverse andresponsible for different details of how to usethem. This heterogeneity and diversity increasethe complexity and make applications more diffi-cult to be reused and/or ported. In practice, someapplications needs to be highly specialized withrespect to a particular type of resource (hard-ware, platform and/or set of services), yieldingthe problem of Data Lock-In.

2.1 Data Lock-In

Data Lock-In is the difficulty developers facewhen having to extract their data and programsfrom one cloud platform to run on another [3].Such problem can be seen mostly in the PaaSscenario: in order to take advantage of a veryflexible cloud architecture, the applications haveto be specifically developed for the chosen plat-form. For example, in order to offer great elas-ticity, Google App Engine – a PaaS provider –imposes a specific programming style and has itsown way to manage data, and thus an applica-tion developed for it may not be easily ported to

a different PaaS provider, nor can its data. Evenif a developer wanted to host such application inhis/her own private cloud later, great effort wouldbe necessary to rebuild the code, redeploy it andmigrate all the data.

This occurs because there is not a standardtechnology for the development of software thatis portable between different cloud providers. Inother words, it is the lack of portability thatcauses the Lock-In. For this reason it is still toocomplicated to reuse these applications.

It is not difficult to see why the Lock-In prob-lem is hindering the adoption of the cloud model[24, 22]. The possibility of becoming “locked in”on a particular platform, not being able to choosea different one later (customer Lock-In), puts thedevelopers in a difficult position. They mostlyfear being charged abusive fees later, or havingtheir applications unavailable due to lack of ser-vice quality [3].

2.2 Types of PortabilityThe main problem caused by the lack of porta-bility is that the work committed to platform-specific tasks can not be reused in a different plat-form. Ideally, software development should bemore conceptual and less focused on repetitivetasks [17].

The ISO 9126 standard [14], developed toidentify software quality attributes, defines porta-bility in terms of how easy it is to migrate soft-ware from one environment to another. It hasthe following sub-attributes: (i) Adaptability: thesoftware’s ability to adapt to different environ-ments without the need for additional actions(settings); (ii) Capacity to be Installed: identi-fies the ease with which the system can be in-stalled into a new environment; (iii) Coexistence:measures how easily a software can coexists withother software installed in the same environment;(iv) Ability to replace: the system is easily re-placed by another.

In the context of this research, portability isa key attribute for the improvement and dis-semination of the cloud model. In this sense,we would like to highlight, from the literature[5, 23, 24, 27], four main types of portability inthe cloud scenario:

(i)Portability of virtual machines betweencloud providers: the IaaS model normally usesserver virtualization10 to provide computing re-sources to customers. Generally the virtual

10Server Virtualization is the technique of running one ormore virtual servers on one physical server [7]

machines are managed by the customers them-selves. Just migrating a virtual machine from oneprovider to another causes little impact on thesystems being virtualized, as all that is neededfor them to run is a copy of the virtual disk. TheOpen Virtualization Format (OVF11) makes thistask even easier, by providing a standard formatso that there is little effort to port a virtual ma-chine from one provider to another, as long asboth support this format.

(ii)Portability of applications in the contextof IaaS: some providers offer, instead of vir-tual machines (VM), hosting plans that supportonly a specific technology. Many have plans forhosting Java, Ruby, PHP, among others. In thiscase, users have no control over the VM, i.e.,the provider manages the entire infrastructure.Once applications are deployed, and dependingon how much configuration is needed, a big effortis necessary to change the provider, because eachprovider offers plans according to different busi-ness goals. For example, the Brazilian providerLocaweb12 offers specific plans, and the usershas the option to buy only the package accordingto the technologies they need. If a user choosesto change the provider, he must check if the des-tination provider supports the same technologiessupported by the current.

(iii)Portability of PaaS applications: usersof the PaaS service model must follow a specificprogramming style and make use of libraries andtechnologies offered by providers. The migra-tion of applications between two platforms oftenrequires a total reengineering process [28]. Thedeveloper must know the details of each platformand libraries, what makes migration difficult andcostly. This is the scenario where this paper fitsin.

(iv)Data portability between cloudproviders: similarly to the previous item,there is not a standard for using traditionaldatabase management systems (DBMS) in thecloud [3]. Therefore, data portability betweenproviders is another item to consider. In theIaaS case, the user may choose to install his/herown instance of a DBMS, and use it in a single,virtual machine. If elasticity is necessary, theuser is responsible for setting up multiple,interconnected servers and define some kind ofdistribution scheme. Another possibility is tohire a provider that supports a particular DBMS.Thus, just as with the portability of applications,before signing a contract with the provider

11OVF: http://www.dmtf.org/standards/ovf12Locaweb: http://www.locaweb.com.br

it is important to ensure that it supports theDBMS in question. Shirazi et al. [27] presenta solution based on design standards to allowdata portability among some cloud databases.However, the solution is still in the researchphase and more studies are needed.

3 MethodologyIn the introductory section of this paper, we citedthat the industry is seeking standardization as apossible solution for the Lock-In problem. Arm-brust et al. [3] have suggested standardizationpath as a possible solution. The problem withthis path is that it requires wide adoption. Somecloud providers may wish to use specific tech-nologies to create solutions that are aligned withtheir business requirements and choose not to fol-low the standard. Thus, until this initiative be-comes concrete, it is important that we study al-ternative approaches, not only to explore a dif-ferent path to portability, but to help improve thecloud model and facilitate its adoption.

In this context, we propose the use of MDEas an element that removes the link between theapplication logic and platform details. This de-cision is justified by the fact that, in additionto presenting an alternative to solve the lock-inproblem, a model-driven approach can bring ad-ditional benefits that would not be achieved sim-ply by adopting standardization. Besides porta-bility, MDE provides benefits in terms of produc-tivity, ease of communication and software main-tenance, allowing software engineers to work ina higher abstraction level [17].

To meet this goal, we used the followingmethodology:

1. Case studies were performed first, to iden-tify the main concepts of PaaS. These stud-ies involved the careful analysis of differ-ent providers’ documentation and the devel-opment of sample applications for differentplatforms;

2. Next these concepts were used to prototypea specification language that captures theessence of PaaS applications. This languageserves to support the creation of platform-independent models, which developers useto specify an application’s structure andlogic. This step involves the development ofa domain metamodel and a concrete syntax;

3. Based on the case studies and on the specifi-cation language, transformations were built

to automatically generate code for cloudplatforms; and

4. Tests were performed to verify the confor-mance between the generated code and theplatform’s requirements.

The idea was to follow an incremental model,repeating these four steps for each different plat-form to be studied. By the time of the writ-ing of this paper, only GAE’s Java-based andMicrosoft’s Windows Azure platform were in-cluded. Other platforms may be included in fu-ture iterations.

A textual concrete syntax was developed forthe specification language, using Xtext13. Weinitially restricted the language to the domain ofCRUD operations (basic database access opera-tions: Create, Retrieve, Update, Delete), whichare an important part of most applications. Al-though it is a simple domain, it encompasses thevarious concepts needed to develop applicationsfor PaaS. It also serves to exercise different waysof implementing the same conceptual model, aseven for simple CRUD operations there are sig-nificant differences in the way GAE and Azuredeal with persistence.

The developed language is completely plat-form independent, so that developers do not needto include details about the PaaS provider. De-tails of the platform were automatically intro-duced by the transformations, which were devel-oped using Xtend14.

Fig. 1 summarizes this methodology, high-lighting its steps, the work already done and thework yet to be performed.

Figure 1: Methodology used to develop anMDE approach to cloud portability. Numbers inrounded rectangles indicate the steps describedin Section 3.

13Xtext: http://www.eclipse.org/Xtext/14Xtend: http://www.eclipse.org/Xtend/

4 A Model-Driven Approachfor Cloud ApplicationsPortability

The approach is based on a common metamodelthat abstracts concepts of cloud platforms. Thismetamodel is the basis of a domain-specific lan-guage (DSL), which is used to create platform-independent models (PIMs). Portability, in thiscontext, is made possible by the combination be-tween the domain-specific language and auto-matic transformations. Together, they allow thesame model to be used to generate an applicationfor different platforms (Fig. 1). Next we discussthese two elements in more detail.

4.1 A DSL for CRUD Operations inCloud PaaS

A DSL is a small, usually declarative, language,focused on a particular problem [8]. DSLs haveexisted for a long time. Mernik, Heering, andSloane [19] cite examples of the APT languagefor numerical control, which dates from 1957-58,and the most famous BNF, or Backus-Naur Form,a language for specifying grammars, establishedin 1959. Since then, several languages have beendeveloped and used, and the literature in this areais very rich [8, 19]. A domain-specific languagecan be textual (allowing to specify programs) orvisual (allowing to specify diagrams).

To study the viability of the approach pre-sented in this paper, a DSL for the CRUD domainwas implemented. As previously discussed, thisdomain was selected because it encompasses var-ious concepts needed to develop applications forthe cloud and yet it is not excessively complex toimplement.

For CRUD operations, the DSL would haveto support basic entities, with attributes and rela-tionships. Specialization/generalization betweentypes is also very common in conceptual mod-eling, so we decided to include it, as well asproper support for different attribute and relation-ship multiplicities.

However, since the goal was to generate exe-cutable code, we had to find out if these conceptscan indeed be implemented in a cloud platform.Particularly, we wanted to know if GAE/Azurecould deal with the persistence of object-orientedentities, otherwise the DSL would have to be dif-ferent than we initially conceived. Therefore weperformed a study to identify the main character-istics of GAE and Azure.

Figure 2: DSL Metamodel.

4.2 Main Characteristics of GAEand Windows Azure

For practical reasons, we focused on the plat-forms’ support for Java. Based on the case stud-ies, to develop CRUD operations for GAE orAzure, there are three points that need special at-tention:

1. Data Persistence:

(i)GAE: There are two options for data stor-age in GAE plataform, App Engine Datas-tore (NoSQL) and Google Cloud SQL (rela-tional database). GAE’s Java Datastore al-lows the use of Java Data Objects - JDO15

and Java Persistence API - JPA16 standardsto specify entities stored in its database.These interfaces are implemented using theopen source access platform Datanucleus17.The developer needs to learn the syntax andrestrictions imposed by the platform;

(ii)Azure: Among the Windows Azure stor-age solutions18 we highlight:

15https://developers.google.com/appengine/docs/java/datastore/jdo/

16https://developers.google.com/appengine/docs/java/datastore/jpa/17Datanucleus: http://www.datanucleus.org/18More information about Windows Azure Storage is

available on its website: www.windowsazure.com

(a) Virtualized SQL Server : it is theSQL Server DBMS running on a vir-tual machine in Windows Azure envi-ronment;

(b) Blob Storage: storage through setsof non-structured bytes, such as audioand video; and

(c) Table Storage: Tables offer NoSQLcapabilities for applications that re-quire storage of large amount of un-structured data.

For this study we selected the table storagemodel. The tables are accessible from virtu-ally anywhere via REST and client APIs.

2. Controller Class: Both GAE and Azuresupport the Java Servlets technology. Theenvironments work with the concept of re-quest / response. Therefore, the model mustbe able to capture elements and generatean implementation considering such partic-ularities of these platforms; and

3. User interface: Both GAE and Azure of-fer support for Java server-generated pages(JSP - Java Server Pages). Thus, support formodeling and code generation on the inter-face should follow this model.

For the interface, business logic and applica-tion control, both platforms offer basic Java sup-port, which is enough for implementing a typi-cal web-based MVC application. For the persis-tence, we wanted to target a NoSQL database,because its efficiency, high scalability and loweroperational costs[13]. Besides, it is cheaper interms of processing and it can be managed by theplatform itself. So for intensive processing andelasticity this is normally the option of choice formost developers.

Since GAE has support for JDO and JPAeven for its NoSQL solution (App Engine Data-store), there is no problem in making the DSLan intuitive object-oriented language, with per-sistent entities and relationships, as we wanted.Other details are platform-specific implementa-tion choices that could be left to the transforma-tions. Azure’s Table Storage, on the other hand,does not have such direct support for relation-ships. So, in order to keep the DSL as intuitive aspossible, we would have to build a layer to man-age entity relationships over a simpler NoSQLdatabase. After some discussions, we decided tofollow this path, as shows the DSL metamodelthat resulted from these studies (Fig. 2).

Basically, the metamodel in Fig. 2 defines per-sistent entities, their properties, relations and dif-ferent attributes. It also defines basic applicationproperties and a division in tabs, which groupclosely related entities together in the generatedinterface.

We decided to make the DSL’s concrete syntaxtextual, due to simplicity, ease of learning andflexibility of tools used in its development. Code1 presents the main elements of the DSL’s EBNFgrammar used as input to Xtext.

Code 1: Xtext DSL Grammar1 DomainModel :2 ( a p p l i c a t i o n = A p p l i c a t i o n ) ?3 e l e m e n t s += Type∗4 ;5 A p p l i c a t i o n :6 ’ a p p l i c a t i o n ’ name=ID ’{ ’7 ’ v e r s i o n ’ v e r s i o n = INT8 ’ t i t l e ’ t i t l e = STRING9 t a b s += Tab∗

10 ’} ’11 ;12 Type :13 E n t i t y | SimpleType14 ;15 E n t i t y :16 ’ e n t i t y ’ name = ID ( ’ e x t e n d s ’17 superType = [ E n t i t y ] ) ? ’{ ’18 key=Key19 p r o p e r t i e s += P r o p e r t y ∗20 ’} ’21 ;

22 P r o p e r t y :23 ( a n n o t a t i o n s += A n n o t a t i o n ∗ ) ?24 ’ p r o p e r t y ’ name=ID ’ : ’25 t y p e = [ Type ]26 ( many ? = ’ [ ] ’ ) ?27 ( ’ l i s t ’ ’= ’ l i s t =BoolType ) ?28 ( ’ i n p u t ’ ’= ’29 i n p u t T y p e = Inpu tType30 v a l u e =STRING ) ?31 ( ’ t i t t l e ’ ’= ’ t i t t l e =STRING ) ?32 ;

According to the grammar, a model defines anapplication and a set of persistent entities (Type).An Application consists of the attributes: name,version, title and tabs. Name and version are in-formation used to generate basic platform config-urations normally needed to deploy applicationsin the cloud. The grammar also describes otherelements needed for the specification of persis-tent entities.

This DSL is obviously platform-independent,so that developers can specify the application’slogic (at least for the CRUD domain) withoutworrying about the platform. Next we describehow a set of transformations introduce most de-tails needed for code generation to succeed.

4.3 Code GenerationBased on the DSL described in the previoussection, transformations were built to producethe different software components related to theCRUD domain in the selected platforms, as listednext:

(i)GAE Transformations:

1. One JDO-annotated Java class is generatedfor each persistent entity, including its prop-erties and relationships. Single inheritanceis also supported;

2. As an alternative to JDO, one JPA-annotatedJava class is generated for each persistententity, including its properties and relation-ships. Single inheritance is also supported;

3. One VRaptor-based class is generated foreach persistent class, to serve as controllerfor responding to interface requests. VRap-tor [12] is a MVC framework based on Javathat facilitates the development of web ap-plications. Each controller class then redi-rects the request to a single, generic, non-generated data-access object, which is re-sponsible for the actual execution of CRUDcommands; and

4. Two JSPs are generated for each persistententity: one for insert/update operations, and

one for listing all instances. The JSPs useJQuery19 to provide quality responsivenessto the user.

(ii)Azure Transformations:

1. Since Azure does not implement JDO orJPA, we built a layer to manage entity re-lationships. Therefore, the transformationsproduce components that sit on the top ofthis layer. One class for each persistententity is generated, but using simple at-tributes to serve as references to related en-tities. Then, the relationship managementlayer we built resolves these references dur-ing CRUD operations;

2. As in the GAE platform, one VRaptor-based class is generated for each persistententity to serve as controllers for the applica-tion; and

3. As in the GAE platform, two JSPs are gen-erated for each persistent entity, one forinsert/update operations, and one for list-ing all instances. The JSPs here also useJQuery to provide quality responsiveness tothe user;

Code 2 shows a piece of a Xtend transfor-mation that produces code for a JDO-annotatedJava class.

Code 2: GAE JDO Transformation1 . . .2 d e f compi l e ( E n t i t y e n t i t y ) ‘ ‘ ‘3 package com . g a e a p p l i c a t i o n . model ;4 / / i m p o r t i n g l i b r a r i e s5 «FOR p r o p e r t y : e n t i t y . p r o p e r t i e s »6 « c o m p i l e I m p o r t s ( p r o p e r t y . t y p e ) »7 «ENDFOR»8 @ P e r s i s t e n c e C a p a b l e (9 d e t a c h a b l e =" t r u e " )

10 / / c l a s s name11 p u b l i c c l a s s « e n t i t y . name»12 / / i n h e r i t a n c e13 «IF e n t i t y . superType != n u l l »14 e x t e n d s « e n t i t y . superType . name»15 «ENDIF» {16 / / g e n e r a t i n g i d e n t i f i e r o f t h e c l a s s17 @PrimaryKey18 «compileKey ( e n t i t y . key ) »19 «FOR p r o p e r t y : e n t i t y . p r o p e r t i e s »20 «IF p r o p e r t y . many== t r u e »21 / / g e n e r a t i n g p r o p e r t i e s wi th22 / / l i s t o f o b j e c t s23 « c o m p i l e P r o p e r t i e s ( p r o p e r t y ) »24 «ELSE»25 / / g e n e r a t i n g s i m p l e p r o p e r t i e s26 « c o m p i l e P r o p e r t y ( p r o p e r t y ) »

19JQuery: http://jquery.com/

27 «ENDIF»28 «ENDFOR»29 / / g e n e r a t i n g g e t s and s e t s30 «compi leKeyGetsAndSets ( e n t i t y . key ) »31 «FOR p r o p e r t y : e n t i t y . p r o p e r t i e s »32 «IF p r o p e r t y . many== t r u e »33 / / i f a p r o p e r t y r e t u r n s a l i s t34 / / o f o b j e c t s35 « c o m p i l e G e t L i s t ( p r o p e r t y ) »36 « c o m p i l e S e t L i s t ( p r o p e r t y ) »37 «ELSE»38 / / i f a p r o p e r t y r e t u r n s b a s i c39 / / t y p e s o r on ly one o b j e c t40 « c o m p i l e G e t s ( p r o p e r t y ) »41 « c o m p i l e S e t s ( p r o p e r t y ) »42 «ENDIF»43 «ENDFOR»44 }45 ‘ ‘ ‘

Code 2 mixes Java code (lines 3 and 11),JDO Annotations (lines 8 and 9) and Xtend code(represented between “«” and “»” quotes) to-gether. Basically this code represents a meta-class. When executed, elements that come fromdomain models are used to fill in the informationneeded to generate a complete JDO-annotatedclass. With automated transformations such asthis, it is possible to free the developers fromrepetitive tasks such as programming an entityclass and its setter/getter functions.

5 Evaluation

The approach developed in this work aims atmaking portability between cloud platforms eas-ier by means of MDE. It also defends the ideathat MDE can bring additional benefits to cloudapplication development. This two fold objectiveled us to perform the evaluation in two parts: acase study, aiming at identifying the benefits thatMDE can bring to portability; and a controlledexperiment, to test if portability can be achievedin a satisfactory way using our approach. Theseare described next.

5.1 Case Study

This Case Study empirical strategy is the tech-nique where key factors which can affect the re-sults of a proposed approach are identified anddocumented [34]. The case studies aim to ob-serve a specific attribute or to stablish the rela-tionship between different attributes.

In our research, the goals of the case studywere: (i) to compare two applications generatedfrom the same domain model; and (ii) to evalu-ate the benefits of applying the MDE approach

in cloud development. For both goals, code anal-ysis was carried out to characterize the develop-ment process and determine the differences be-tween the code generated for the two platforms.

To illustrate how the transformations work,consider an application that should providefunctionality for registering products in an e-commerce system. A product has an id, a name,description and price. Code 3 presents an exam-ple of this entity described using the developedDSL.

Code 3: Product Domain Model.1 e n t i t y P r o d u c t {2 pk { i d : Key ( s t r a t e g y =IDENTITY ) }3 p r o p e r t y name : S t r i n g4 p r o p e r t y d e s c r i p t i o n : S t r i n g5 p r o p e r t y p r i c e : Double l i s t = f a l s e6 }

Code 4 presents a JDO-based implementationclass for the product. This class was completelygenerated by the developed transformations. Itcontains information processed from the model(Code 3) and additional platform details, such asthe annotations in lines 1, 3 an 4. transformationsprocess. To build transformations it is necessaryknowledge about platform and its set of libraryand technologies supported. But, since the trans-formations was built, the programming team onlyneeds to know the DSL simplified syntax.

Code 4: Generated product entity class for GAE1 @ P e r s i s t e n c e C a p a b l e ( d e t a c h a b l e ="true" )2 p u b l i c c l a s s P r o d u c t {3 @PrimaryKey4 @ P e r s i s t e n t ( v a l u e S t r a t e g y =5 I d G e n e r a t o r S t r a t e g y . IDENTITY )6 p r i v a t e Key i d ;7 @ P e r s i s t e n t8 p r i v a t e S t r i n g name ;9 @ P e r s i s t e n t

10 p r i v a t e S t r i n g d e s c r i p t i o n ;11 @ P e r s i s t e n t12 p r i v a t e Double p r i c e ;13

14 . . . g e t t e r s and s e t t e r s . . .15 }

From the same model it is also possible to gen-erate Windows Azure Java code. Code 5 presentsa persistent class for the Windows Azure plat-form. It is easily possible to see the differencesbetween implementations on each platform, de-spite the fact that both applications are imple-mented using the same language (in this caseJava). Theses differences occurs because of thespecific technologies adopted by the platforms.

Code 5: Generated product entity class for Win-dows Azure

1 package com . a z u r e a p p l i c a t i o n . model ;2

3 i m p o r t j a v a . u t i l . ∗ ;4 i m p o r t com . m i c r o s o f t . windowsazure .5 s e r v i c e s . t a b l e . c l i e n t .6 T a b l e S e r v i c e E n t i t y ;7

8 / / G e n e r a t e d C l a s s9 p u b l i c c l a s s P r o d u c t e x t e n d s

10 T a b l e S e r v i c e E n t i t y {11 / / a t r i b u t e s12 p r i v a t e S t r i n g name ;13 p r i v a t e S t r i n g d e s c r i p t i o n ;14 p r i v a t e Double p r i c e ;15 / / c o n s t r u c t o r s16

17 p u b l i c P r o d u c t ( ) {18 t h i s . p a r t i t i o n K e y = " P r o d u c t " ;19 }20 . . .21

22 / / . . . g e t t e r s e s e t t e r s . . .23 }

Similarly, the transformations produce codefor the other parts of the chosen domain. Fig.3 presents a generated interface for creating andupdating products in the running e-commerce ex-ample. The attributes come directly from themodel (Code 3).

Figure 3: JSP for creating / updating a product

The important thing to highlight here is thatthe elements and semantics of the domain modelwere sufficient to generate functional applica-tion for both Azure and GAE platforms. Thedeveloper does not have to worry about detailsabout how GAE and Azure deal with persistence,or how the controller works. The analysis per-formed in the generated code for the applicationsfound that the applications are the same besidesthe different details of each platform. We madesome complementary analyses by calculating thereason between the specification elements andthe generated code(REC). That metric allows todeterminate the relationship between the domainelements and the generated code. REC is calcu-lated as follows:

REC =∑

LOC(Gen. code)/∑

NEE(models)

(1)Where: LOC(Gen. Code) is the total of gen-erated code and NEE(Models) is the number ofmodel specification elements.

We performed the calculus on different ways:on each generated functionality and on completeapplication. We used two applications for thatcalculus. We found that for each line of codeof the Textual DSL on average was generated105 implementation lines of code. Off coursethis number can change for more or less depend-ing the size of the studied application. However,from that observations is possible, at least to seesome benefits on reducing repetitive codificationtasks.

5.2 Portability evaluation

In the case study described in the previous sec-tion, we observed that portability between cloudproviders can be achieved through MDE, at leastfor a specific domain and after an initial effortof building a complete infrastructure, includinga DSL and different transformations. We alsoobserved that the gains in productivity are con-siderable, given the automation power of MDEtransformations.

For this part of the evaluation, the goal was todetermine if the results of the approach are sat-isfactory, in terms of funcionality as seen by theend user. For portability to be satisfactory, theuser should not perceive any difference when anapplication is moved from one platform to an-other.

We followed the experimental phases sug-gested by Wohlin et al. [33]. The idea was totake advantage of the solid empirical elementsfrom that methodology for executing ours tests.So the planning was carried out as follows:

5.2.1 Planning

The main idea of the evaluation was to have twoversions of the same application: one running onGoogle App Engine, and the other running onWindows Azure. Subjects were then asked to useboth versions, and tell if they could perceive anydifference.

With this in mind, the test planning involvedthe following phases:

(i)Context Selection: the experiment oc-curred in the academic environment. It was per-

formed at the Software Engineering Laboratoryat Federal University of São Carlos;

(ii)Research Question: is it possible to port,with MDE, an application between cloud plat-forms so that the final users do not perceive anydifferences between the original and the portedapplications?

(iii)Selection of subjects: the subjects wereselected through convenience sampling i.e. thenearest and most convenient people are selectedas subjects[33]; and

(iv)Design: Inspired by other reports from theliterature [29], we defined a set of black box testcases to serve as a script for the subjects. Theidea was to ensure they would use both versionsin a similar way, and also exercise all functionsof the application. These are conventional testcases, with a description, preconditions, a set ofsteps to be performed, and the expected results.Atotal of eleven test cases were defined.

5.2.2 Execution

The tests were executed in 2 steps:Step 1 -Preparation - In this step the instru-

mentation elements were elaborated:a. Guidelines: The material consisted of one

document with the description of the tasks andinstructions the subject should follow and onedocument with the application description andsupport material.

b. Data Collection Instruments: Data col-lection was performed in two moments. The firstmoment was during test case execution. Aftereach test case description in the task descriptiondocument, there was a field where subjects wouldrespond if they considered the test case success-ful or not. In a second moment, a questionnairewas given to each subject, where he would in-form his/her perception on portability. This ques-tionnaire was based on ISO standard 9126 [14],which defines portability as a set of attributes thatbear on the ability of software to be transferredfrom one environment to another. Among its fourattributes, which are adaptability, installability,co-existence and replaceability, we decided to fo-cus on replaceability, as we believe that it is themost adequate to the goal of this research.

Step 2 - Execution- Initially, using the MDEapproach, we generated two version of an appli-cation for the two platforms supported by the ap-proach (GAE and Azure). The application usedin this study was different from the one describedin Section 5.1. Here we used the laboratory anal-ysis domain. The subjects then executed the test

cases. This study had ten participants. The exe-cution took one day, including initial training andthe filling of the questionnaire.

5.2.3 Data Analyses

All ten subjects were able to use both versionsof the application and perform all test cases suc-cessfully. Regarding the questionnaire, the re-sults of each question are discussed next.

Question 1 - Do you consider that in termsof functionality the two versions of the appli-cation are equivalent? For two applications Aand B to be equivalent, the set of functions imple-mented in A must be equal to the set of functionsimplemented in B. In this question all subjectsanswered that the two versions of the applicationwere equivalent in terms of functionality.

Question 2 - Do you consider that in termsof interface the two versions of the applica-tion are equivalent? Two applications can beequivalent in terms of functionality but have dif-ferent interfaces. In this question all subjects an-swered that the two versions of the applicationwere equivalent in terms of interface.

Question 3 - Do you consider that for thesame input on each version of the application,the outputs were equal? This question evalu-ates if the systems are equivalent in terms of in-put and output. In this question all subjects an-swered that the two versions of the applicationwere equivalent in terms of input/output.

Question 4 - Do you consider that the Azureversion can be replaced by the GAE version(and vice-versa)? In this question all subjectsanswered that the two versions could be replacedby each other.

From this evaluation, we can conclude that itwas possible to port, by means of an MDE ap-proach, and in the context of the chosen domain,an application between cloud platforms in such away that the final users do not perceive the differ-ences when using the two versions. This is par-ticularly interesting if we consider that the under-lying storage mechanisms are different, as dis-cussed in Section 4.2. This effectively puts MDEas a viable alternative to port application betweencloud providers.

5.2.4 Threats to validity

Low number of subjects: a small set of usersparticipated in the tests. A larger number of peo-ple using the system can lead to the discovery ofmore fails and differences.

Simple domain: the application built in thecase study is relatively small and represents asmall problem domain. These elements mayhave facilitated the analysis, and it is possiblethat we did not test all situations.

Statistical treatment: the collected data didnot allow a formal, complete statistical treatment,which would lead to much more solid results.But we believe the qualitative analysis has im-portant insight into the approach.

6 Related Work

In the literature it is possible to find several pa-pers related to the portability of applications incloud computing. Proposals for developing ap-plications for cloud basically revolve around twoapproaches: API standardization and MDE.

In the path of standardization, there are someinitiatives gathering efforts for addressing theLock-In problem, such as the DMTF (DistributedManagement Task Force), which employs effortsfocused on standardizing interactions betweencloud environments by developing specificationsthat deliver architectural semantics and imple-mentation details to achieve interoperable cloudmanagement between service providers and theirconsumers.

Also proposing standardization, we can citethe OCCI-WG (Open Cloud Computing Inter-face Working Group), which is a protocol andAPI for all kinds of management tasks, and wascreated to develop a remote management APIfor IaaS-based services, allowing development ofinteroperable tools for common tasks includingdeployment, autonomic scaling and monitoring.The current release of the Open Cloud Comput-ing Interface is suitable to serve many other mod-els in addition to IaaS, including e.g. PaaS andSaaS.

IEEE P230120 is responsible for developing astandard that will enable portability. To achievethis goal, it will group the different options (in-terfaces, tile formats and operation conventions)of the cloud elements into logical profiles. IEEEP230221 also follows a similar path, but to definethe topology, protocols, functionality and gover-nance required to support cloud-to-cloud inter-operability and federated (intercloud) operations[16, 31].

20IEEE P2301: grouper.ieee.org/groups/2301/

21IEEE P2302: grouper.ieee.org/groups/2302/

Sharma and Sood [26] present a model-drivenapproach for interoperability in SaaS. The au-thors define the models at different abstractionlevels, based on separation of concerns - Com-putation Independent Model (CIM), Platform In-dependent Model and Platform Specific Model(PSM) building on MDA22. Each level can becomposed by one or more models to specifystructural, functional and behavioral system. ForPIMs a formal definition of the operations of-fered by the service is used, which can be ac-cessed through an interface that must later becomposed with other services to build a completesystem. Business rules are specified throughthe declaration of restrictions, pre-conditions andpost-conditions and invariants in Object Con-straint Language (OCL). After some transforma-tions the PIM is then converted to a WSDL PSM,which consists of a specific model descriptionlanguage for web services. The final step is thetransformation of the WSDL PSM into a WSDL.

Other approaches:More research issues and approaches related to

the development of systems to the cloud modelcan be found in Armbrust et al. [3] and Silva andLucrédio [28]. Cloud computing is still evolving,and research opportunities are still being iden-tified. Even in this new scenario, is possibleto identify a certain alignment between authors.This work is in agreement with most MDE-basedproposals, which is focus on the PIM-PSM sep-aration. But in our understanding, our researchhas contributions by proposing a practical ap-proach focused on a commercial PaaS provider.It also provides a well-defined methodology forincluding other platforms as well, serving toguide future research.

7 Concluding remarks and fu-ture work

The lack of portability between cloud applica-tions raises the Lock-In problem. In order tosolve this problem, this paper presented a model-driven approach for cloud portability. The cloudtechnologies and MDE, together, can providemany benefits to system developers, such as pro-ductivity, improved maintenance and documen-tation, reuse and more.

We spent 3 months building the DSL and thetransformations. Despite the high initial costs ofsuch elements [17], they can be reused in the de-velopment of new projects and systems. But a

22www.omg.org/mda/

quantitative study related to the cost-benefit ofthe approach is not on the scope of this research.

The results of the evaluation have shown thatMDE can not only promote portability in a waythat users do not perceive differences betweenplatforms, but also lead to additional benefits,mainly productivity.

8 Acknowledgements and Au-thor Biographies

The authors would like to thank CAPES andFAPESP processes number 2012/04549-4 and2012/24487-3 for partially funding this research.

Elias Silva has high experience on developingweb systems. He got his bach. in computer sci-ence at State University of Southwest Bahia andhis Masters at Federal University of São Carlos.Now he is phd candidate at University of SãoPaulo(USP).

Renata P. de M. Fortes received the B.Sc. inComputer Science from the University of SãoPaulo, Brazil, in 1982, and the Ph.D. degreein Computational Physics, from University ofSãoPaulo,SãoCarlos, Brazil, in 1996. Renataserves on the Steering Committee of the ACMSIGDOC conference and is a member of theACM and the Brazilian Computer Society.

Daniel Lucrédio got his computer engineer(2002) and M.Sc. in Computer Science (2005)degrees at the Federal University of São Carlos,Brazil, and his PhD (2009) at University of SãoPaulo, São Carlos, Brazil. During his PhD He re-alized two doctoral internships: in George MasonUniversity (VA, USA) and Microsoft Research(WA, USA). He has academic and industrial ex-perience in computer science (software engineer-ing) working mainly with software reuse, CASE,Model-Driven Development, component searchand component-based development.

References[1] Distribuited Managemente Task Force,

2012.

[2] Open Cloud Computing Interface, 2012.

[3] Michael Armbrust, Armando Fox, ReanGriffith, Anthony D Joseph, Randy Katz,Andy Konwinski, Gunho Lee, David Pat-terson, Ariel Rabkin, Ion Stoica, and MateiZaharia. Above the clouds: A Berkeleyview of cloud computing. 2009.

[4] Michael Armbrust, Armando Fox, ReanGriffith, Anthony D Joseph, Randy Katz,Andy Konwinski, Gunho Lee, David Pat-terson, Ariel Rabkin, Ion Stoica, and MateiZaharia. A view of cloud computing. 53,2010.

[5] Jean Bozman. Cloud Computing: TheNeed for Portability and Interoperability.IDC Analyze the Future, Sponsored by RedHat, Inc, 2010.

[6] Yizeng Chen, Xingui Li, and FangningChen. Overview and analysis of cloud com-puting research and application. 2011.

[7] Jeff Daniels. Server virtualization archi-tecture and implementation. Crossroads,2009.

[8] Van Deursen, , Arie Klint, and Joost Pauland Visser. Domain-specific languages: Anannotated bibliography. ACM Sigplan, 35,2000.

[9] Javier Esparza and Munoz Escoí. Towardsthe next generation of model driven cloudplatforms. In CLOSER 2011, 2011.

[10] I Foster, Yong Zhao, I Raicu, and S Lu.Cloud Computing and Grid Computing360-Degree Compared. In GCE 2008,2008.

[11] Robert France and Bernhard Rumpe.Model-driven Development of ComplexSoftware: A Research Roadmap. IEEEComputer Society, 2007.

[12] Alexandre Freire and Paulo Silveira.Vraptor-simple and quick web framework.In 5th Workshop on free software(WSL2004), 2004.

[13] Jing Han, E Haihong, Guan Le, and JianDu. Survey on NoSQL database. In 6thICPCA 2011, 2011.

[14] ISO/IEC9126. Software product evaluation- Quality characteristics and guidelines fortheir use. ISO Standard, 1991.

[15] Anneke Kleppe, Warmer Jos, and BastWim. MDA Explained, The Model-Driven Architecture: Practice and Promise.Addison-Wesley, 2003.

[16] N Loutas, E Kamateri, F Bosi, and K Tara-banis. Cloud Computing Interoperability:The State of Play. In IEEE CloudCom2011, 2011.

[17] D Lucrédio, E S Almeida, and R P MFortes. An investigation on the impact ofMDE on software reuse. In 6th SBCARS2012. IEEE, 2012.

[18] Peter Mell and Tim Grance. The NIST Def-inition of Cloud Computing . 2009.

[19] M Mernik, J Heering, and A M Sloane.When and how to develop domain-specificlanguages. ACM CSUR, 2005.

[20] P Mohagheghi and T Sæ andther. Soft-ware Engineering Challenges for Migrationto the Service Cloud Paradigm: OngoingWork in the REMICS Project. In Services(SERVICES), 2011 IEEE World Congresson, pages 507–514, 2011.

[21] Parastoo Mohagheghi and Vegard Dehlen.Where is the proof? A review of expe-riences from applying MDE in industry.In Model Driven Architecture-Foundationsand Applications, pages 432–443, 2008.

[22] Balakrishna Narasimhan and Ryan Nichols.State of Cloud Applications and Platforms:The Cloud Adopters’ View. 2011.

[23] Dana Petcu, Georgiana Macariu, SilviuPanica, and Ciprian Craciun. PortableCloud applications - From theory to prac-tice. Fut. Gen. Comp. Systems, 2012.

[24] A Ranabahu and A Sheth. SemanticsCentric Solutions for Application and DataPortability in Cloud Computing. In IEEECloudCom 2010, 2010.

[25] B P Rimal, Eunmi Choi, and I Lumb. ATaxonomy and Survey of Cloud Comput-ing Systems. In INC, IMS and IDC, 2009.NCM ’09. Fifth International Joint Confer-ence on, pages 44–51, 2009.

[26] Sood M Sharma D Sharma R. Modelingcloud SaaS with SOA and MDA. CCIS,2011.

[27] M N Shirazi, Ho Chin Kuan, andH Dolatabadi. Design Patterns to En-able Data Portability between Clouds’Databases. 2012.

[28] Elias A N Silva and Daniel Lucrédio. Soft-ware Engineering for the cloud: A Re-search Roadmap. SBES Brazilian Sympo-sium, 2012.

[29] Liana Silva and Sérgio Soares. Analyzingstructure-based techniques for test coverageon a J2ME software product line. In 10thLATW’09. IEEE, 2009.

[30] Luis M Vaquero, Luis Rodero-Merino, JuanCaceres, and Maik Lindner. A break in theclouds. ACM SIGCOMM, 2008.

[31] Marko Vukolic. The byzantine empire inthe intercloud. ACM SIGACT, 2010.

[32] Lizhe Wang, Gregor von Laszewski, An-drew Younge, Xi He, Marcel Kunze, JieTao, and Cheng Fu. Cloud Computing: aPerspective Study. New Generation Com-puting, 28(2):137–146, 2010.

[33] C Wohlin, P Runeson, M Host, C Ohlsson,B Regnell, and A Wesslén. Experimenta-tion in software engineering: an introduc-tion. 2000.

[34] Robert K Yin. Case study research: Designand methods, volume 5. Sage Publications,Incorporated, 2008.

[35] Shuai Zhang, Xuebin Chen, Shufen Zhang,and Xiuzhen Huo. The comparison be-tween cloud computing and grid comput-ing. In ICCASM 2010, 2010.