An Approach for the Development of Portable Applications on PaaS

Clouds

Filippo Giove, Davide Longoni, Majid Shokrolahi Yancheshmeh, Danilo Ardagna

and Elisabetta Di Nitto

Politecnico di Milano, Milan, Italy

Keywords:

Cloud Computing, Performance Study, Portability.

Abstract:

Cloud computing is becoming important for ICT industry. Despite undoubted advantages in term of scalability

and cost savings, today there are still issues regarding its massive diffusion due to portability of applications.

To address this problem, in this paper we propose a new approach for the development of portable applications

for Platform as a Service (PaaS) systems. This is based on a Java library exposing a vendor independent API

that provides an abstract intermediation layer for the most important middleware services typically offered by

PaaS systems (e.g., NoSQL services, message queues and memcache).

The current version of our library supports the portability of applications across Java platforms for Google

App Engine and Windows Azure. We have conducted some experiments especially focusing on evaluating

the performance degradation introduced by our library when executing an application on both PaaS. The

experiments demonstrate that such degradation is not signiﬁcant.

1 INTRODUCTION

Cloud computing is new paradigm which provides a

new way of managing and offering IT services. De-

spite undoubted advantages of Cloud systems in term

of scalability and cost saving, today there are some

issues regarding limitation in their massive diffusion.

Ideally, any company should be able to change its

Cloud supplier. The reasons that can push an IT man-

ager to move all or part of the company software from

one supplier to another can be:

• offered SLA not respected;

• costs increase over time;

• competitors start new interesting or cheaper ser-

vices.

Unfortunately, today moving from a Cloud

provider to another is not an easy task. Each Cloud

provider has its own API for deploying and running

software and, most important, if we focus on the PaaS

(Platform as a Service) level, each Cloud provider of-

fers slightly different services, components and con-

tainers. This implies that an applications built for a

certain PaaS and exploiting certain services (or com-

ponents and containers) needs to be reengineered to

be moved to a different Cloud. This is certainly a time

consuming and very expensive operation that leads to

the perception of so-called Lock-in by the Cloud ser-

vice provider.

In this paper, we propose a library called CPIM

(Cloud Provider Independent Model), that offers

to developers PaaS-level services such as message

queues, noSQL services, and caching service, ab-

stracting from the details that are speciﬁc of the un-

derlying PaaS provider. By exploiting our services

an application developer is able to implement his ap-

plication in a PaaS independent way. At deployment

time, he/she speciﬁes the actual PaaS to be used for

the operation of the application and conﬁgures in the

appropriate way the actual services to be used. At

runtime, the CPIM library is in charge of acting as

a mediator between the application code and the ser-

vices offered by the PaaS that is currently hosting the

application. Should the application owner be willing

to move to a different Cloud, all he/she will have to

do is to re-execute the deployment procedure on the

other Cloud.

By exploiting the current implementation of the

library, the application developer can build advanced

distributed applications that, at the moment, can be

deployed either on Google App Engine or on Win-

dows Azure with no change at the code level. The de-

ployment requires the execution of some speciﬁc con-

ﬁguration steps and is supported by an Eclipse plugin

we have developed that guide the deployer through

591

Giove F., Longoni D., Shokrolahi Yancheshmeh M., Ardagna D. and Di Nitto E..

An Approach for the Development of Portable Applications on PaaS Clouds.

DOI: 10.5220/0004511605910601

In Proceedings of the 3rd International Conference on Cloud Computing and Services Science (CI-2013), pages 591-601

ISBN: 978-989-8565-52-5

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

these steps.

The library has been validated by conducting ex-

periments aiming at assessing the overhead it intro-

duces at runtime while it acts as an intermediary be-

tween the application and the native PaaS APIs. The

experiments have shown that such overhead is negli-

gible.

The paper is structured as follows: Section 2

presents related work. Section 3 introduces the ap-

proach we have taken in building the CPIM library.

Section 4 describes the application “Meeting in the

Cloud” (MiC), we have developed and used as a ref-

erence for our experiments. Section 5 discusses the

experimental tests we performed and the results we

have obtained. Finally, Section 6 draws the conclu-

sion and outlines future work.

2 RELATED WORK

The PaaS market is, in these days, rich of interest-

ing initiatives. The ﬁrst and most known solutions

are those offered by Google App Engine (Euphro-

sine, 2013) and Windows Azure (Meier, 2013), but

others are being launched and are gaining interest in

the practitioners and scientiﬁc communities. Among

the others, we can mention so called open platform

as a service which allow to develop, test, and de-

ploy applications implemented in any programming

language, see for instance OpenShift (Red-Hat, 2012)

and Cloud Foundry (CloudFoundry, 2013).

Currently each Cloud provider exposes services

that, even when they are classiﬁed as similar, offer

a different semantic and can be accessed through dif-

ferent APIs. This leads to serious problems of inter-

operability and portability of applications and of data

residing on Cloud platforms.

There are some general approaches that could

be taken to facilitate the portability across platforms

(Petcu, 2011):

• Adoption of globally recognized and accepted

standard APIs.

• Use of Wrapper/Adapter, i.e., a mediation layer

that can decouple applications from the character-

istics of Cloud platforms.

Among the standardization initiatives, IEEE

P2301 (Ortiz, 2011) is a working group aiming to

draw directives for the deﬁnition of Cloud services

APIs. The goal is to deﬁne concepts, formats and

conventions that, if widely adopted, would facili-

tate the portability and interoperability of different

Clouds, allowing further growth and effective use of

Cloud computing. Another example in this area is the

partnership between Google and VMware (VMware

and Google, 2012). The two companies, leaders of

the Cloud market, through this alliance are trying to

answer to portability issues by leveraging VMware

vCloud technologies, Spring-Source, Google Web

Toolkit and Google App Engine, to facilitate the de-

velopment and implementation of business applica-

tions. Using the development environment based on

Eclipse Spring Source Tool Suite, developers can cre-

ate their own applications and later have the oppor-

tunity to carry out the deployment on a VMWare

vSphere private environment, on a VMware vCloud

partner or directly on Google AppEngine. OCCI,

Open Cloud Computing Interface (OCCI, 2012) is an-

other standardization activity that has been initially

focusing on the creation of OCCI API for remote

management of low level Clouds called IaaS (Infras-

tructure as a Service) and that now is trying to cover

the PaaS model as well.

Among the mediation approaches, CSAL, Cloud

Storage Abstraction Layer (Hill and Humphrey,

2010), provides an abstraction of typical storage ser-

vices offered by most of PaaS, i.e., blobs and tables.

The challenge of this project is related to the map-

ping of abstract operations in speciﬁc calls to such

services.

SimpleCloud (Zend et al., 2013) is a open source

project created by Zend Technologies in collabora-

tion with IBM, Microsoft, Rackspace, Nirvanix and

GoGrid, having the objective of improving the porta-

bility of PHP applications. With SimpleCloud, the

developercan use a provider speciﬁc API or use a me-

diation layer that allows to write portable code among

the supported set of vendors.

Among the current European-funded projects,

mOSAIC (Open-Source API and Platform for Mul-

tiple Clouds) (mOSAIC, 2013) has the aim of de-

veloping an open-source PaaS as a mean of com-

munication between Cloud applications and IaaS ser-

vices. A mOSAIC application is able to postpone

the choice of the underlying infrastructure. In other

words, application developers and Cloud operators

have the potential to defer decisions about which IaaS

provider to use when the applications will actually

run. The Cloud4SOA(Nikos Loutas, 2011) consor-

tium seeks to consolidate three computing paradigms,

namely Cloud computing, the service-oriented archi-

tecture (SOA) and lightweight semantics. The overall

objective is to propose a reference architecture that

allows interoperability between different Cloud ven-

dors, facilitating the development, deployment and

migration of applications among different Cloud PaaS

providers. Speciﬁcally, Cloud4SOA adopts a seman-

tic approach to allow developers and PaaS providers

to express their technology-speciﬁc concepts with a

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

592

standardized vocabulary and common relationships.

Compared to the approaches presented above,

CPIM library belongs to the category of mediation

approaches. It differs from CSAL, since we provide

an abstraction layer not only for services related to

storage, but also for NoSQL, SQL, Queue, and Mem-

cache services.

It also differs from all other approaches as it is

the only one able to support both Windows Azure and

Google App Engine which are very heterogeneous

and can be considered the PaaS platforms market

leaders. Among the other features, CPIM reconciles

the strong difference in the semantics of the queue

services offered by Azure and App Engine and imple-

ments two different services called task queue, adopt-

ing the App Engine semantics and message queue

adopting the Azure semantics.

3 A LIBRARY FOR THE

DEVELOPMENT OF

PORTABLE PaaS

APPLICATIONS

The most interesting characteristic of PaaSs is the

set of abstractions they make available to applica-

tion developers. Typical abstractions concern the con-

cept of queue, which enables a reliable and asyn-

chronous communication among distributed applica-

tion components, and various different storage mech-

anisms ranging from a pure distributed ﬁle system to

SQL and noSQL databases. All these abstractions

are made available as services that can be invoked

through well deﬁned interfaces.

While the abstractions can be considered indepen-

dent of each speciﬁc PaaS, the corresponding actual

services are PaaS-speciﬁc and differ from PaaS to

PaaS. The differences can either concern the interface

they offer to programmers or their actual behavior. In

both cases, these differences have a signiﬁcant impact

on the applications under development. In the follow-

ing we present our solution to overcome these differ-

ences.

3.1 Solution Overview

The CPIM library aims at offering to application de-

velopers a homogeneousset of abstract PaaS services,

that at runtime it adapts to the actual PaaS services

being used. The services supported currently are the

following:

• SQL service offers all capabilities of a traditional

relational database and offers a SQL interface for

interaction with its users.

• Blob service offers the possibility of storing sim-

ple bulk of data by relying on large storage re-

sources offered by the Cloud.

• NoSQL service offers the capabilities of storing

large quantities of data. Differently from SQL

databases, these systems do not support com-

pletely the linguistic power of relational algebra

as they do not offer the join operation, but they

offer mechanisms to support high scalability and

reliability.

• TaskQueue service offers the possibility to queue

tasks to be executed and provides the logic layer

that extracts tasks from the queue and executes

them.

• Message Queue service offers the possibility to

queue messages so that the sender and the recip-

ient components can interact in a decoupled and

asynchronous way.

• Memcache service offers the possibility to build

an in-memory database up to a size of about 32

GB.

• Mailing service provides the operations to send an

email message to some address speciﬁed by the

user.

Figure 1 positions CPIM between an application

and the two currently supported PaaS, Google Ap-

pEngine and Microsoft Azure). These last ones are

relevant cases to study for two main reasons: ﬁrst,

they are the two market leaders at the moment, sec-

ond, they offer quite speciﬁc and diversiﬁed services.

Because of this second reason, we argue that demon-

strating the feasibility of creating an abstraction layer

on top of them allows us to show that the CPIM phi-

losophy has the potential to work in general.

The left handside of Figure 1 highlights the pres-

ence of a conﬁguration ﬁle through which the ap-

plication developers provides information concerning

the cloud to be adopted for deploying the application.

This conﬁguration ﬁle is not to be provided during the

development of the application, which remains com-

pletely cloud agnostic, but should be available at the

moment of deployment. Its speciﬁc content is de-

scribed in detail in Section 3.5.

The design pattern used for implementing the li-

Figure 1: Overview of the CPIM library approach.

AnApproachfortheDevelopmentofPortableApplicationsonPaaSClouds

593

Figure 2: Usage of CPIM to initialize the NoSQL and Mem-

cache services, GAE case.

brary is the AbstractFactory pattern (Metsker and

Wake, 2006). More precisely, the developer of an ap-

plication exploiting the library is supposed to exploit

the primitives of a factory class to use all services of-

fered by the library. Such a factory at runtime reads

from the conﬁguration ﬁle the information concerning

the cloud provider to be used and instantiates the cor-

responding concrete factory that in turn, on request,

instantiates the factory handling the speciﬁc service

that the application is going to use. The sequence di-

agram shown in Figure 3 describes this interaction in

the case the application has been deployed on Google

App Engine where the NoSQL service is used.

For the sake of space we cannot provide details

on all implemented services. In the following sub-

sections we describe the NoSQL and Task Queue ser-

vices as they have been the most challenging for the

implementation of the library.

3.2 NoSQL Service

NoSQL services are provided natively by both App

Engine, with its Datastore service, and Azure, with

the Table Service. As discussed in (Hecht and Jablon-

ski, 2011) (Han et al., 2011), a large number of

NoSQL databases are available and support a variety

of data models.

In order to cope with such variety, we have chosen

to access such databases through a JPA (Java Persis-

tence API) interface. JPA (Apache, 2012) (Hibernate,

) is a speciﬁcation deﬁning a way to manage the per-

sistency of objects on a database. As such, it allows

us to abstract from the low-level APIs offered by the

speciﬁc storage service, at the expenses of a reduced

efﬁciency in the way queries and update operations

are performed.

In case of Google App Engine, the interface and

its implementation, are supplied directly by the SDK

for Java Google App Engine. Vice versa, Microsoft

does not offer an ofﬁcial JPA implementation for the

Azure Table Service.

To compensate this limitation, we have adopted

an open source library (jpa4azure Library, ), and ex-

tended it by implementing the main methods for sup-

porting the execution of queries. Thank to this exten-

sion, we standardize the invocation of queries written

in SQL-like language.

The types of attributes remappable in properties

supported by both platforms are: byte, date, Boolean,

integer, String, Double. If the developer needs to in-

sert an attribute of a type different from those sup-

ported, as long as serializable, this attribute should be

deﬁned as @Embedded. This annotation allows the

JPA to convert the attribute into a byte array at the

time of serialization. Vice versa, when the value of

an attribute annotated with @Embedded is returned,

the JPA converts the corresponding array in the object

type declared in Java class.

3.3 Task Queue

A queue is a service frequently used by Web appli-

cations deployed in the Cloud. It allows to decou-

ple the application tiers (e.g., the front-end and back-

end) in a way that application containers supporting

the runtime can scale in and scale out independently.

Usually, queues are used to store messages that are

transferred from the application front-end to the back-

end or vice versa. Task queues offered by Google

(Queue, 2013), instead, store tasks (or links to task

code) that have to be activated as soon as the corre-

sponding record is extracted from the queue. A task

queue not only includes the mechanisms for storing

information about the tasks, but also the mechanism

that, typically adoptinga FIFO ordering, gets from the

queue a task and triggers its execution. This mecha-

nism is particularly useful to support the execution of

background operations.

Task queues appear to be useful in a variety of ap-

plications where it is possible to execute some compu-

tational intensive operations in the background. Thus,

we have decided to offer them as part of the CPIM li-

brary and we have developed a software layer on top

of the Azure Queue Service (AzureDOC, 2013) to im-

plement them according to the schema in Figure 5.

In the CPIM library a task is represented as a

Cloud-independent object. This object is represented

by the CloudTask class, which encapsulates the fol-

lowing information (see Figure4):

• HTTP method used for the invocation of the task.

• Parameters passed to the task. These are repre-

sented by typical key-value pairs.

• Path of the task.

• Unique identiﬁer of the task.

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

594

Figure 3: Sequence Diagram for MF and NoSQL.

Figure 4: Class CloudTask.

In the case of Google, this information is extracted

to populate the TaskOption object, which is then in-

serted into the App Engine Push Queue. Instead,

for Azure, this information is extracted, properly for-

matted in a text message, and inserted in a Message

Queue.

Azure requires also the implementation of an ad-

hoc consumer executed in a dedicated Role to guar-

antee the separation between the presentation layer of

the application from its back-end. In particular, in our

implementation we instantiate a different consumer

thread (exploiting the Azure InternalWorker class) for

each task queue to monitor. This thread reads the

messages from the queue and creates a sub-consumer

dedicated to each read message (see Figure 5). Each

sub-consumer:

• Extracts the information contained in the mes-

sage.

• Invokes the task through the path included in the

message.

• Deletes the message from the queue.

The consumer thread executes its operations periodi-

cally. The duration of such period can be customized

by the user.

In the case of incorrect execution of a task, App

Engine offers the possibility to automatically retry the

execution of the same task. In Azure we rely on the

fault tolerant features of Azure queues. Queues ex-

pect to obtain a feedback from the consumer of a mes-

sage within a Visibility Timeout that by default is set

to 10 minutes (AzureDOC, 2013) and put the message

back into the queue in case this timeout has elapsed.

Thanks to this mechanism, in case of failure of any

component involved in the execution of the task, the

Figure 5: Implementation of Task Queue for Azure.

message providing information about the task will be

read again and the task will be re-executed.

The sequence diagram in Figure 6 shows how our

Azure task queue works. The diagram highlights the

organization of software in two different parts, back-

end and front-end that interact through the queue and,

being decoupled, can be managed and scaled indepen-

dently from each other depending on the actual load

of each application part.

Figure 6: Sequence Diagram for the Amazon Task Queue

On the library side, the queue instantiation re-

quires the conﬁguration of various parameters, by us-

ing the queue.xml conﬁguration ﬁle. This conﬁgura-

tion ﬁle is read by the CloudTaskQueueFactory object

that is then able to instantiate the CloudTaskQueue

object (see Figure 7), the Cloud-independent wrap-

per used to communicate with the queues of the two

providers. Once this object is obtained, it is possible

to invoke the following methods for interacting with

it:

AnApproachfortheDevelopmentofPortableApplicationsonPaaSClouds

595

Figure 7: Class Diagram CloudTaskQueue.

• add(CloudTask): allows to add a CloudTask to the

queue

• delete(CloudTask): allows to delete a CloudTask

from the queue

• purge(): deletes all CloudTask

• getQueueName(): returns the name of the queue

3.4 Summary of CPIM Supported

Services

Table 1 summarizes the characteristics and limits of

the two PaaS and the extensions implemented in our

library. The ﬁrst column contains the abstract Cloud

services, the second and the third columns are the

Google App Engine and Azure solutions for each ser-

vice, and the last column is the approach provided by

our library. As it can be seen, the two platforms in

some cases offer several solutions. When needed and

in particular for the task queues, SQL and NoSQLser-

vices, we have built an extensive software layer to of-

fer to the library users the richest possible semantics

for the corresponding service.

3.5 Application Deployment

As discussed before, using the CPIM library applica-

tion developers are able to build a Cloud-independent

code even when they use PaaS level services. The

next step is then to deploy the application on the se-

lected PaaS. This, in general, is not a trivial task as

each PaaS has its own procedure and conﬁguration

parameters to be set. For this reason, we have care-

fully deﬁned the deployment steps for a CPIM-based

application on the two supported PaaS and we have

developed an Eclipse plugin to support this task.

Such plugin supports the deployer in the following

tasks:

1. Specify the conﬁguration ﬁles needed to identify

the selected cloud and properly conﬁgure it.

2. Create an ad-hoc project including: (i) the pack-

age (typically jar ﬁles) of the vendor speciﬁc

APIs, (ii) the package (war ﬁle) containing the ap-

plication code and (iii) the CPIM library package

(jar ﬁle).

3. In case task queues are used in Azure, prepare

a separated deployment package (war) containing

the implementation of the queue consumer.

The conﬁguration ﬁle is a XML ﬁle which contains

information such as choice of Cloud Provider and

conﬁguration for each services. For example, the

<vendor> tag allows to set the Cloud platform to be

used, while the <sql> tag contains the conﬁguration

of the SQL service that will be used for conﬁguring

JDBC. In Figure 8 a screenshot of the plugin is shown.

The user can choose GAE and Azure and how he can

enable the services required by his application.

Figure 8: CPIM Plug in for eclipse.

If, for any reason, the need to change the Cloud

provider arises, no re-engineering or modiﬁcation of

the code is required. Only simple changes in the con-

ﬁguration ﬁle are needed.

4 MEETING IN THE CLOUD

APPLICATION

MiC (Meeting in the Cloud) is a social networking

web application. It allows a user to register and to

choose his/her topics of interest providing a grade in

the range 1-5. At the end of the registration process,

MiC identiﬁes the most similar users in the social net-

work according to the registered user’s preferences,

in particular, similarity is computed through the Pear-

son coefﬁcient (Pearson, 2010). After registration, the

user can enter into the MiC portal and can interact

with his “Best Contacts” writing and reading posts on

the selected topics.

Figure 9 shows the registration and user similarity

computationprocesses by highlightingthe application

components that are involved in their execution.

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

596

Table 1: Summary of the services offered by App Engine, Azure and CPIM.

Service Google App Engine Windows Azure Our Approach Library

Proprietary API Proprietary API JPA interface

NoSQL

JPA interface JPA interface(third-party) Support serializable objects

JDO interface (@Embedded)

MySQL-like SQL Server-like

SQL

Maximum 10GB for instance sharing java.sql

JDBC Driver JDBC Driver

Dedicated/Co-located

Memcache

Synchronous/Asynchronous Memcache supported by the Synchronous

Caching service(third-party)

Two typologies to manage Two blob typologies Flat organization

Blob

Flat organization Hierarchical organization 32MB maximum blob size

32MB maximum blob size Max 200GB/1TB for Block/Page blob

Two typologies to manage code Message code Message code

Queue

Task code Limits to 64KB for message Task Code

Limits 64KB for message

Internal SMTP External SMTP

Mail

Direct API support java.mail support java.mail

support java.mail

Figure 9: Registration and User Similarity computation of

MiC.

More precisely, the application is composed of a

front-end developed as JSPs and Servlets and a back-

end developed as a CPIM CloudTask. The front-end

and back-end are decoupled by a task queue and share

user proﬁles through the SQL Service. This same ser-

vice also stores messages, and best contacts that are

accessed by the front-end. The Blob Service is used

to store pictures while the NoSQL Service stores user

interests and preferences. Both are accessed by the

front-end. Finally, the Memcache Service is used to

temporarily store the last retrieved user proﬁles and

best contacts messages with the aim of improving the

response time of the whole application.

Figures 10 and 11 show the component diagrams

describing the deployment on Google App Engine

and Microsoft Azure. In the case of Google App En-

gine, the components of the MiC software are:

• Web Application Project which contains:

– MiC Component that includes the speciﬁc

application-dependent Servlet classes and JSP

pages as well as the CPIM API library and its

conﬁguration ﬁles

– Google App Engine SDK for Java: SDK for

the development of Java applications for GAE.

It includes the Java API for accessing services

offered by platform

– Java SQL API: APIs to access and use rela-

tional DB

• GAE Services: services offered by Google

In the case of Microsoft Azure, Apache Tomcat

has been deployed in each WorkerRole in order to use

Java Servlet technology and the Component Diagram

includes the following components:

• the same MiC Component as in the GAE case

• Internal Worker war: war containing the code for

the queue manager we have developed for Azure.

• jpa4Azure API: API for accessing services

Queue, Blob and Table (through the JPA inter-

face)

• Java SQL API: API to access and use of relational

databases

• SpyMemcache client: client component of the

Memcache service

• Azure Services: Azure platform services

5 EXPERIMENTAL RESULTS

The objective of the evaluation has been to assess the

overhead introduced by the adoption of our vendor in-

dependent. To do this, for each PaaS we deployed two

implementations of the MiC application, one using

our library and one using directly the vendor-speciﬁc

API.

AnApproachfortheDevelopmentofPortableApplicationsonPaaSClouds

597

Figure 10: Component Diagram: deploy on Google App

Engine.

Figure 11: Component Diagram: deploy on Azure.

Experimental Setting. The metrics we have

adopted for comparison are:

• The latency

• The computational overhead, in terms of CPU re-

source utilization

We used JMeter (Apache, 2013) as workload injector

and we considered the following two workload sce-

narios as they cover all actions a user can perform on

MiC:

Test Plan 1. The user session registration as de-

scribed in Figure 9.

Test Plan 2. A session where the user performs the

following actions:

• Login

• Update proﬁle

• Write a message

• Logout

The content of the storage system was the same for all

tests:

• SQL Database:

– Number of Tuples in table Message: 3,000

– Number of Tuples in table User Proﬁle: 4,300

– Number of Tuples in table User Similarity:

14,800

• NoSQL Table Service:

– Number of entities for User Ratings: 14,800

– Number of entities for Topic: 7

On Azure the tests were carried out deploying

MiC on two Worker Roles (one for the front-end and

one for the back-end) by using Small instances, while

for GAE the tests were carried out deploying MiC on

two instances with F1 size. Tables 2 and 3 show, for

each request, the cloud services that have been used,

the concerned tier and the think time introduced to

make realistic behavior of a user in the session. More

speciﬁcally, we assume that the think time follows a

Gaussian distribution for which we provide in the ta-

ble the average (parameter K) and the standard devia-

tion (parameter D).

Table 2: Summary Table Test Plan 1.

HTTP REQUEST Used cloud services Think Time(sec)

SELECT TOPICS

(K=5;D=1)

SAVE ANSWER NoSQL, TaskQueue (K=20;) (D=5)

Table 3: Summary Table Test Plan 2.

HTTP REQUEST Used cloud services Think Time(sec)

EDIT PROFILE

(K=2;) (D=0.1)

SELECT TOPICS NoSQL,SQL,Memcache (K=5;) (D=1)

SAVE ANSWER NoSQL,TaskQueue (K=20;)(D=5)

REFRESH NoSQL,SQL,Memcache (K=2;)(D=0.5)

WRITE POST SQL (K=10;)(D=3)

LOGOUT Memcache

Latency measures have been collected directly

through JMeter while to capture data regarding the

CPU utilization of the Azure and Google App Engine

containers we had to use some platform speciﬁc tools.

Azure offers the ability to remotely access the

VMhost of the application deployment (using Remote

Desktop Protocol). Thanks to this, we collected data

directly from the monitoring tool of Azure for the

CPU utilization. App Engine does not offer the possi-

bility to access to virtual machine-level information.

Thus, we had to exploit the Quota service API by in-

strumenting the code of MiC. In this way, through the

Java SDK, we were able to get for speciﬁc blocks of

code, the number of CPU cycles consumed by execut-

ing the block within the sandbox App Engine.

The unit of measure used by the API is machine

megacycles. If all instructions are performed sequen-

tially on a reference machine 1.2 GHz 64-bit x86

CPU, 1200 megacycles are equivalent to one CPU

second devoted for a block execution.

Using the obtained data, we can estimate the per-

centage of use of the CPU, through the following for-

mula:

∑

k=1

)

1200∗ T

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

598

where M

indicates the number of megacycles con-

sumed by the k-th request within a test, N denotes the

total number of requests made during a test, while T

indicates the duration in seconds of the whole test.

Results on Azure. Figure 12 reports the latency

time results for Azure in the two test scenarios when

the number of users grows from 1 to 50. In this way

we were able to vary the VM role utilization between

2 and 70 %, analysising the behaviour of the system

both in light and medium/heavy load conditions. As

it appears from the graphs, no signiﬁcant difference

between the use of our library and the native Azure

APIs can be observed.

Figure 12: Latency Time Evaluation Test: CPIM results vs

Azure Native results for Test 1 and 2.

A careful analysis was done for the results ob-

tained in the second test plan with 10 users, where

a higher average latency for the native version has

been observed. Speciﬁcally, the results of the queries

presented some differences greater than 300 millisec-

onds. The Response time graph in Figure 13 shows

that requests with large latency times (around 30 sec-

onds) occurred during three time intervals. We guess

that these large delays have been caused by the mi-

gration of the VM which hosts the application on a

different machine. This caused a temporary block in

requests execution. This problem, as shown in the

graph of Figure 14, has not occurred in the test case

using our library where the maximum registered re-

sponse time has been below 7 seconds.

Figure 13: Response Time - 10 users version Native.

Figure 14: Response Time - 10 users version by CPIM.

Figure 15: CPU utilization Test: CPIM results vs Azure

Native results.

Figure 15 reports the CPU utilization gathered

during the tests. The computational overhead intro-

duced by our library both for the front-end and back-

end is almost negligible, even under heavy load (the

green line representing the front-end CPU utilization

in the CPIM case is completely hidden by the line rep-

resenting the utilization in the native case). This result

conﬁrms that our implementation of the Task Queue

service, which resides in the back-end, has good per-

formance.

Results on Google App Engine. Similar results

have been obtained for the Google platform. These

are reported in Figure 16 for latency time and in

Figure17 for CPU utilization.

AnApproachfortheDevelopmentofPortableApplicationsonPaaSClouds

599

Figure 16: Latency Time Evaluation Test: CPIM results vs

GAE Native results for Test 1 and 2.

Figure 17: CPU utilization Test: CPIM results vs GAE Na-

tive results.

6 CONCLUSIONS AND FUTURE

WORK

Avoiding vendor lock-in is an important issue that be-

comes quite difﬁcult to achieve when exploiting PaaS.

In this paper we haveproposed the development of

an abstraction layer exposing a “vendor-independent”

API, which allows developers to use the most impor-

tant and common services offered by PaaS systems.

The approach is oriented to the Java language and the

platforms currently supported are Google App Engine

and Windows Azure. Using a social networking ap-

plication as a test case, we have carried out tests to

evaluate the overhead introduced by the use of the ab-

straction layer with respect to the direct use of the

proprietary APIs provided by the two vendors. The

results have shown that the overhead introduced by

the library, both for the latency and CPU utilization,

is negligible.

Future work will consider the integration of addi-

tional services offered by the two platforms. Further-

more, additional Cloud systems both at the PaaS and

IaaS layers will be supported.

ACKNOWLEDGEMENTS

This research has been partially supported by the

European Commission, Grant no. FP7-ICT-2011-8-

318484MODACloudsproject (MODAClouds,2013).

REFERENCES

Apache (2012). Java Data Objects (JDO API 3.0 ). http://

db.apache.org/jdo/jdo v jpa.html.

Apache (2013). Jmeter USer Manual Document. Apache.

AzureDOC (2013). http://msdn.microsoft.com/en-us/

library/windowsazure/hh767287.aspx.

CloudFoundry (2013). CloudFoundy. http://

www.cloudfoundry.com/about.

Euphrosine, J. (2013). Getting Started with Google Tasks

API on Google App Engine.

Han, J., Haihong, E., Le, G., and Du, J. (2011). Survey on

nosql database. In Pervasive Computing and Applica-

tions (ICPCA), 2011 6th International Conference on,

pages 363 –366.

Hecht, R. and Jablonski, S. (2011). Nosql evaluation: A use

case oriented survey. In Cloud and Service Computing

(CSC), 2011 International Conference on, pages 336

–341.

Hibernate. Hibernate Developer Guide. Hibernate.

Hill, Z. and Humphrey, M. (2010). CSAL: A Cloud Storage

Abstraction Layer to Enable Portable Cloud Applica-

tions. In Cloud Computing Technology and Science

(CloudCom), 2010 IEEE Second International Con-

ference on, pages 504 –511.

jpa4azure Library. JAR jpa4azure.jar (version 0.7). http://

jpa4azure.codeplex.com/.

Meier, J. (2013). Windows Azure Developer Guidance Map.

Metsker, S. J. and Wake, W. C. (2006). Design Patterns in

Java, chapter 17. Addison-Wesley Professional.

MODAClouds (2013). http://www.modaclouds.eu/.

mOSAIC (2013). http://www.mosaic-cloud.eu/.

Nikos Loutas, C. (2011). Cloud4SOA Reference Architec-

ture.

OCCI (2012). http://occi-wg.org/.

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

600

Ortiz, S. (2011). The problem with cloud-computing stan-

dardization. Computer, 44(7):14 –15.

Pearson, K. (2010). Similarity Metrics: Pearson Correlation

Coefﬁcient. http://mines.humanoriented.com/classes/

2010/fall/csci568/portfolio exports/sphilip/ pear.html.

Petcu, D. (2011). Portability and interoperability between

clouds: Challenges and case study. In Abramow-

icz, W., Llorente, I., Surridge, M., Zisman, A., and

Vayssire, J., editors, Towards a Service-Based Inter-

net, volume 6994 of Lecture Notes in Computer Sci-

ence, pages 62–74. Springer Berlin Heidelberg.

Queue, G. T. (2013). Task Queue Java API Overview.

https://developers.google.com/appengine/docs/java/

taskqueue/overview?hl=en.

Red-Hat (2012). OpenShift - User Guide : Using OpenShift

to manage your applications in the cloud, edition 2.0

edition.

VMware and Google (2012). www.vmware.com/

cloudportability.

Zend, IBM, Microsoft, Rackspace, Nirvanix, and

GoGrid (2013). SimpleCloud API. http://

www.simplecloud.org/.

AnApproachfortheDevelopmentofPortableApplicationsonPaaSClouds

601