A REFERENCE MODEL FOR DEVELOPING CLOUD

APPLICATIONS

Mohammad Hamdaqa, Tassos Livogiannis and Ladan Tahvildari

Department of Electrical and Computer Engineering, University of Waterloo, Waterloo, Ontario, Canada

Keywords:

Cloud computing, Reference model, Meta-model, Software architecture, Model-driven architecture.

Abstract:

Cloud Computing is a paradigm shift that involves dynamic provisioning of shared computing resources on

demand. It is a pay-as-you-go model that offers computing resources as a service in an attempt to reduce

IT capital and operating expenditures. The problem is that current software architectures lack elements such

as those related to address elasticity, virtualization and billing. These elements are needed in the design of

cloud applications. Moreover, there is no generic cloud software architecture for designing and building cloud

applications. To further complicate the problem, each platform provider has different standards that inﬂuence

the way applications are written. This ties cloud users to a particular provider. This paper will focus on

deﬁning a reference model for cloud computing; more particularly, it presents a meta-model that shows the

main cloud vocabulary and design elements, the set of conﬁguration rules, and the semantic interpretation.

It is always important to understand the abstract architecture of a system, and then tackle platform-speciﬁc

issues. This separation of concerns allows for better maintainability, and facilitate applications portability.

1 INTRODUCTION

Cloud computing is paving its way into the enter-

prise. In its early years, the cloud computing research

was focused on building robust cloud infrastructure.

Mainly, it focused on improving cloud datacenters

and its related technologies that allow for scalability

and elasticity. After building the underlying cloud in-

frastructure, the hype was building platforms on top

of the cloud infrastructure. Today, a number of com-

panies (e.g., Microsoft, Google, and Amazon) pro-

vide platforms that allow for efﬁcient development

of cloud applications and easy control of data. Of-

fering a pay-as-you-go billing policy ties the oper-

ating expenditure to the provider’s offer. Selecting

the best offer may dictate a shift from one provider

to another; the need to partially redevelop the appli-

cation makes this shift difﬁcult and more costly. The

main concerns of cloud providers are how to deal with

these issues, in particular standardization and inter-

operability between different cloud platforms (Tsai

et al., 2010). Vendor Lock-in, or being tied to a spe-

ciﬁc vendor deployment environment is what hinders

the decision of many customers to move to the cloud.

This challenges cost reduction and portability across

multiple vendors. This paper addresses the above is-

sues by providing a reference model for developing

cloud applications. A good design requires having

the right elements and vocabulary, which match the

implementation elements. Our preliminary study of

two of the main cloud platform development environ-

ments, namely Windows Azure (Microsoft, 2010) and

Google App Engine (GAE) (Google, 2010), uncov-

ered the fact that both platforms share some common

components, despite the fact that they are built based

on different business and pricing models.

The work this paper presents is part of a larger

project. Its aim is to deﬁne a cloud software architec-

ture, a cloud modeling language, and its related de-

sign patterns. The goal is to allow cloud users (Arm-

brust et al., 2009) to design applications independent

of any platform and to build inexpensive elastic appli-

cations.

From a software engineering point of view, a

cloud application is a software provided as a service.

It consists of the following: a package of interrelated

services, that we later will call tasks, the deﬁnition of

these tasks, and the conﬁguration ﬁles, which contain

dynamic information about tasks at run time. Cloud

tasks provide compute, storage, communication and

management capabilities. Tasks can be cloned into

multiple virtual machines, and are accessible through

application programmable interfaces. Cloud applica-

tions are a kind of utility computing that can scale out

Hamdaqa M., Livogiannis T. and Tahvildari L..

A REFERENCE MODEL FOR DEVELOPING CLOUD APPLICATIONS.

DOI: 10.5220/0003393800980103

In Proceedings of the 1st International Conference on Cloud Computing and Services Science (CLOSER-2011), pages 98-103

ISBN: 978-989-8425-52-2

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

and in to match the workload demand. Cloud appli-

cations have a pricing model that is based on different

compute and storage usage, and tenancy metrics.

In the next section we present related work. Sec-

tion 3 justiﬁes the need of a cloud application refer-

ence model. We deﬁne and explain the cloud appli-

cation reference model in Section 4, followed by a

conclusion and future directions in Section 5.

2 RELATED WORK

Perhaps the work done in (Tsai et al., 2010) is the

most related to our work. Tsai et al. proposed

a ”Service-Oriented Cloud Computing Architecture”

that allows cloud applications to work with each

other. The proposed architecture is a three layered ar-

chitecture that consists of a cloud ontology mapping

layer, a cloud broker layer, and a SOA layer. The

work we are presenting in this paper falls under the

ontology mapping layer where we deﬁne a reference

model, providing the main vocabulary of cloud ap-

plications and the relations between them. The refer-

ence model takes into consideration the multi-tenancy

pattern (the Single Application Instance and Multiple

Service Instances) presented by the authors.

A model-driven approach for building cloud so-

lutions is also presented in (Charlton, 2009). Three

design goals, which are similar to our goals, are pre-

sented. These goals are the following: the separation

of applications from infrastructure, the enablement of

computer-assisted modeling and control automation,

and the explicit collaboration to enact changes. In

the same publication, the authors denoted eight char-

acteristics that a cloud application should incorporate,

in order to achieve the above-mentioned goals. Fur-

thermore, this industrial paper introduced and brieﬂy

described three Elastic Modeling Languages (EML)

for computing, deployment and management of elas-

tic applications. The reference model we are present-

ing in this paper acts as a meta-model for such lan-

guages and conforms with the goals presented in this

paper.

In (Frey and Hasselbring, 2010), CloudMIG, a

framework to facilitate the migration of legacy soft-

ware systems to the cloud is presented. Six actions

are proposed for this migration to address four short-

comings that the authors state as problems in the mi-

gration process. Both our approach and CloudMIG

are based on model driven engineering. While our ap-

proach starts from current cloud platforms to extract

common vocabulary and elements to create a cloud

meta-model, CloudMIG starts from existing legacy

systems, extracts the actual architecture, and then uses

the selected target cloud platform meta-model along

with a utilization model to generate a target model to-

ward system migration.

Variation analysis is the technique proposed in

(Zhang and Zhang, 2009) as a way of designing cloud

applications. The authors deﬁned a set of Architec-

tural Building Blocks and ways to assemble a cloud-

SOA solution from them, using variation analysis.

This approach is speciﬁcally designed and checked

for Service Oriented Architecture software systems

built using the Service-Oriented Solution Stack, a

template layered architecture from IBM.

The need to detach the cloud application devel-

opment process from speciﬁc cloud platforms is ad-

dressed in (Maximilien et al., 2009). A platform-

agnostic middleware is proposed. This middleware

lies on top of the Platform-as-a-Service layer. It pro-

vides API and services to be used by cloud users, and

transparently deploys the application to a speciﬁc (but

initially unknown) cloud platform. Interestingly, this

approach relieves developers from the cloud vendor

lock-in problem, but ties the developmentof cloud ap-

plications to the proposed middleware.

A bottom-up approach for assembling cloud ap-

plications from simpler components, the MacroCom-

ponents is presented in (Matthews et al., 2009).

The proposed approach leverages a number of open

source technologies, in order to provide a compo-

nent model for building cloud applications. Open

source technologies involved, include the OSGi com-

ponent model, the P2 provisioning infrastructure for

OSGi component model, and the CloudClipse, which

is an eclipse plugin for managing the deployment and

installation of speciﬁc virtualization images used in

cloud platforms, such as Amazon EC2 or Eucalyptus.

From an IT management perspective, (CA Labs,

2009) proposed a cloud architecture to facilitate com-

patibility between ITIL and cloud computing, as well

as portability of cloud applications between different

cloud vendors. The goal is to maximize the return

of IT investment (ROI) in cloud computing. The ap-

proach’s foundation is the C3A paradigm. The ref-

erence architecture consists of speciﬁc components,

which enable provisioning of application’s agreement

on SLAs, and the migration of the application to dif-

ferent cloud vendors. The proposed architecture is

essential for migrating ITIL compatible applications

to the cloud, and managing existing cloud applica-

tions. Nevertheless, our paper presents a reference

model rather than a reference architecture. The pro-

posed reference model facilitates the cloud applica-

tion development, from the design to the implemen-

tation, in a transparent way, without depending on

speciﬁc Platform-as-a-Service or Infrastructure-as-a-

A REFERENCE MODEL FOR DEVELOPING CLOUD APPLICATIONS

Service components.

The problem of migrating legacy software sys-

tems is the main topic of (Zhang et al., 2009). The

authors provide a seven step methodology, inspired

from the SEI’s horseshoe model, to migrate legacy

software systems to cloud platforms. The methodol-

ogy involves re-engineering the original legacy archi-

tecture, reﬁning it to a modern service oriented archi-

tecture, and porting it to the cloud using MDA trans-

formation techniques. Our cloud reference model can

add value to this methodology, by providing a unique

targeted model for the transformations, before the de-

ployment of the re-factored legacy application to the

cloud. This can improve the approach’s ﬂexibility, es-

pecially that the original methodologyforces develop-

ers to choose a cloud vendor before porting the legacy

application to the cloud.

3 THE NEED OF A CLOUD

APPLICATION REFERENCE

MODEL

Before listing the cloud application reference model

components and their relations, it is important to jus-

tify the need for this model and the difference be-

tween this model and SOA reference model.

SOA is an umbrella that describes any kind of ser-

vice. A cloud application is a service. A cloud ap-

plication meta-model is a SOA model that conforms

to the SOA meta-model. This makes cloud applica-

tions SOA applications. However, SOA applications

are not necessary cloud applications. A cloud appli-

cation is a SOA application that runs under a speciﬁc

environment, which is the cloud computing environ-

ment (platform). This environment is characterized

by horizontal scalability, rapid provisioning, ease of

access, and ﬂexible prices. While SOA is a busi-

ness model that addresses the business process man-

agement, cloud architecture addresses many technical

details that are environment speciﬁc, which makes it

more a technical model.

Cloud platforms are complex environments,

which need to be reﬁned at different levels of gran-

ularity. The cloud hierarchical view (i.e. SaaS, PaaS,

IaaS) is an example of a reﬁnement that uses SOA

to describe the high level services provided over the

internet (the cloud). There is a need to create a model-

ing language that is tailored to build efﬁcient, elastic

and autonomous applications from tasks and services

provided by the cloud environment, and to deﬁne pat-

terns that can result in the efﬁcient optimization of

money and resources.

The modeling language should be platform inde-

pendent, with enough technical details that allow it to

tackle the platform speciﬁc environments. This will

facilitate the task of the design and implementation

of application in these environments. This will also

help in migrating applications between differentcloud

providers, or deploy the same implementation on dif-

ferent platforms. This programming model should

also provide programmers with the best practices that

can help in the design and implementation of cloud

applications.

Any model consists of a vocabulary of design el-

ements, a set of conﬁguration rules, and a semantic

interpretation. In the following section, we will de-

ﬁne the cloud computing architecture by drawing a

meta-model that represents the main components of

cloud applications and the relations between them.

4 THE CLOUD APPLICATION

META-MODEL

Figure 1 is a meta-model of cloud applications. A

Cloud Application is neither pure service oriented nor

a standard web application. Cloud applications com-

bine traditional software with remote services to pro-

vide highly available, scalable and high performance

software, in addition to a fault tolerance, scalable stor-

age that can scale to petabytes. A cloud application

supports the Software plus Services (S+S) paradigm

(Sirtl, 2008), where each application consists of a

number of Tasks.

A Cloud Task is a composable unit, which con-

sists of a set of actions that utilize services to pro-

vide a speciﬁc functionality to solve a problem. It is

a mutated unit that can be copied to other virtual ma-

chines in order to allow horizontal and vertical scal-

ability. Tasks should satisfy when composed the fol-

lowing principals: statelessness, low coupling, modu-

larity, and semantic interoperability. Tasks are seman-

tically connected to other tasks in the cloud through

the roles they play in order to satisfy a speciﬁc busi-

ness requirement, which is bounded by obligations

or responsibilities. Cloud tasks are uniquely identi-

ﬁed by a global Dynamic Name Service (DDNS) that

can be assigned to a dynamic virtual IP address at run

time. This makes the task highly available and fault

tolerant, and allows the cloud application to be dy-

namically upgradable without any interrupts.

Like any other service or component, a Cloud-

Task has a deﬁnition ﬁle. A TaskDeﬁnition stores in-

formation about tasks that the cloud application pro-

vides. A TaskDeﬁnition contains information about

the cloud application tasks, which are determined at

CLOSER 2011 - International Conference on Cloud Computing and Services Science

100

-appID : Decimal

-appURI : String

-version : Decimal

CloudApplication

-name : String

-Virtual_IP : String

CloudTask

-VMSize : Integer

-numberOfInstances : Integer

-DBSize : Integer

-bandwidth : Integer

-locationProximity

ConfigurationData

TaskDefinition

CloudFrontTask CloudRotorTask Cloud PersistenceTask

Persistence

Page

Blob Table Queue

-provisioned by1

-provisions*

DataInjectionPort

-name : String

EndPoint

Internal External

Protocol

AccessMechanism

-belongs to

-has

-associated with

-use*

Semantic Interaction Patterns

-associated with1

-have*

One-Way MEP Two-Way MEP

-used by

-use*

Push

Pull

SLA

BillingAgent

determines

Sync Async

Push-Pull Push-Push

-belongs to1

-has*

-depends on1

-specifies1

-defined by

-defines

-has

CloudCrossCuttingTask

-has

-change properties

-URI : String

Container

WebTask ServiceTask

Block

-use*

-used by

-created by

-creats*

-in1

-contains

Figure 1: Cloud Application Meta-Model.

design time. A TaskDeﬁnition provides the struc-

ture of the cloud application, in terms of the provided

tasks, their types and relationships. It also provides

the set of task interfaces and their contracts.

What makes a cloud application different from

other applications is its elasticity. Cloud applications

have the ability to scale out and in. This can be

achieved by cloning tasks into multiple virtual ma-

chines at runtime to meet the changing work demand.

ConﬁgurationData is where dynamic aspects of cloud

application are determined at runtime. There is no

need to stop the running application or redeploy it

in order to modify or change the information in this

ﬁle. ConﬁgurationData contains information such

as the size of the virtual machine (VMSize), number

of instances (numberOfInstances), database size (DB-

Size), bandwidth, even the location (locationProxim-

ity) where you want your task instances to run and

whether they belong to the same afﬁnity group or

not. Different cloud platform providers have different

pricing models. The general umbrella is pay-as-you-

go. However, the way resources are allocated based

on the amount of money you pay is different. Some

cloud platform providers allow the cloud user (appli-

cation developer) to allocate resources explicitly. The

cloud user can set the values in the ConﬁgurationData

ﬁle based on need and budget. Other cloud plat-

form providers provide algorithms (BillingAgent) to

dynamically allocate resources based on the amount

of money a cloud user is willing to pay. The user

can set the budget and general guidelines, and the

provider will modify the values in the Conﬁgura-

tionData ﬁle automatically for the best conﬁguration.

The cloud provider uses the ConﬁgurationData as a

contract with the cloud user. This can be represented

in a clear readable format as a Service Level Agree-

ment (SLA).

Task properties can also be modiﬁed at runtime.

This can be achieved through a DataInjectionPort. A

DataInjectionPort modiﬁes tasks crosscutting proper-

ties such as those related to quality of service (QoS).

Cloud platform providersvary in the way they support

data-injection. This is because data-injection tech-

niques are considered risky and can be a source of

many security threats.

CloudTask can be classiﬁed into:

a CloudFrontTask. An entry point to the cloud ap-

plication that handles user requests, which are dis-

A REFERENCE MODEL FOR DEVELOPING CLOUD APPLICATIONS

101

tributed by a load balancer. A CloudFrontTask

must support the interactive request-response pat-

tern. It is usually a web application (WebTask)

hosted on the cloud datacenter where a web-server

is always enabled. However, it can also be a web-

service (ServiceTask), which is provided by a third

party. A ServiceTask uses the Enterprise Service

Bus (EBS) to discover and access remote or enter-

prise services.

b CloudRotorTask. This task runs in the background

of the CloudFrontTask on the cloud datacenter. It is

not directly accessible from outside the cloud dat-

acenter. Mainly, it does some general development

work, or helps other tasks by performing a partic-

ular functionality. CloudRotorTask must support

event-driven communication patterns. Grid com-

puting tasks are common examples for CloudRo-

torTasks.

c CloudCrossCuttingTask. This task is responsible

for managing cross-cutting aspects such as those

related to monitoring cloud resources, which in-

cludes compute and storage instances and a load

balancer to ensure resource utilization and per-

formance. It is also responsible for logging,

maintaining quality of services of the cloud ap-

plication, deployments of application/tasks, dy-

namically add/remove instances based on metrics,

launching instances, log-in to instances, and task

properties change through the DataInjectionPort.

CloudCrossCuttingTasks can be accessed directly

through a web portal or a speciﬁc API (i.e. REST,

SOAP). Communication with CloudCrossCutting-

Tasks should be secure by applying, for example,

one of the public key algorithms and by using cer-

tiﬁcates (i.e. HTTPS EndPoint)

d CloudPersistenceTask. The main role of Cloud-

PersistenceTasks is to manage storage accounts.

CloudPersistenceTasks manage the access control

and login to cloud storages. A cloud storage (e.g.,

blob, table, queue) does not have any access control

mechanism; it is the responsibility of the persis-

tence task to provide the authorization and authen-

tication services. CloudPersistenceTasks create

containers, which are analogous to folders but with

no nesting. Containers are accessible through a

unique Uniform Resource Identiﬁer (URI). Cloud-

PersistenceTasks assign persistency to containers

and give them a unique URI that is either privately

or publicly accessible. The CloudPersistenceTask

supports three main types of cloud storages that

are reliable, can scale out, simple, inexpensive and

have better performance under the cloud environ-

ment. These types are: unstructured data (blobs),

structured data (tables) and asynchronous messag-

ing (queues).

i Blob. Blobs are unstructured large data ﬁles

and their meta-data. It can be stored as a se-

quence of blocks or pages. The blob is the

simplest and largest cloud storage unit. Cloud

drive storages are blobs.

ii Table. Tables are structured data ﬁles, that are

more complex than blobs, but different than re-

lational database (RDB) tables. Cloud tables

are much simpler. This makes them suitable

for massive scalability. They can scale out to

support any number of simultaneous tasks. A

cloud table is a set of entities and its associated

properties. It uses two types of keys: partition

keys and row keys. Cloud tables do not sup-

port SQL queries, have no schema and use op-

timistic concurrency for updates and deletions.

Cloud tables are more like datasheet tables.

iii Queue. A scalable messages storage, which

supports the polling-based model used in mes-

sage passing between tasks. A message can

be stored for long periods (i.e. days) before

it is read and then removed from the queue.

Cloud queues are different from conventional

queueing systems. Cloud queues must support

fault tolerance. Unlike conventional queues, a

message read does not delete the message from

the queue. The message is set into a hidden

mode until it is successfully processed. It is the

responsibility of the processing task to delete

the message. The queue is the main commu-

nication mechanism between CloudFrontTasks

and CloudRotorTasks. Which makes it one of

the most frequently used design patterns in the

cloud. This design pattern does not only relief

the end-user from waiting for a long time un-

til a task processes the message, but also makes

scalability easier.

Relationships between tasks can be determined

by EndPoints. EndPoints are ports through which a

CloudTask can connect to other tasks or to the envi-

ronment. Each Task has one or more EndPoints. An

EndPoint can be classiﬁed based on several criteria.

Whether it is publicly visible (external) or only ac-

cessible within the Cloud Application (internal), load

balanced at the network level or not, or whether it

allows inbound or outbound communication. Each

EndPoint uses an access mechanism, which uses a

semantic interaction pattern for the coordination of

message exchange. These patterns are based on spe-

ciﬁc protocols that determine the syntax and seman-

tics of the messages that are exchanged between the

CLOSER 2011 - International Conference on Cloud Computing and Services Science

102

two communication parties. Message Exchange Pat-

terns (MEP) can be classiﬁed into two main cate-

gories, one-way or two-way. The one-way MEP is

usually referred to as the event driven MEP, or pub-

lish subscribe (pub/sub), in which the participating

parties are not fully aware of each other. A tempo-

rary storage in the form of a queue is usually used

to accomplish this. One party will push a message,

and the second will pull it from the queue. This is

one of the common communication patterns between

CloudFrontTasks and CloudRotorTasks. On the other

hand, the two way MEP is usually referred to as re-

quest/response MEP. It can be either a synchronous

(blocking) or asynchronous (non-blocking). This is

an interactive communication that is usually needed

when you have direct interaction with the user. Cloud-

FrontTasks must support this type of interaction with

the application user.

5 CONCLUSIONS

This paper presented a meta-model for cloud applica-

tions. Cloud computing is a new paradigm for devel-

oping elastic and ﬂexible applications with less time

to market. The promise is to reduce the overhead of

developing, conﬁguring, deploying, and maintaining

cloud applications. Currently, there is no common

vocabulary, developmentmethodologies,or best prac-

tices that distinguish the cloud development paradigm

from the existing ones. The lack of standardization

and common terminologies challenges portability and

migration between different cloud platforms. On the

other hand, the lack of software architectural models

and design patterns makes cloud application develop-

ment an ad-hock approach.

To address the previous problems, in this paper we

deﬁned a cloud application meta-model that is capa-

ble of capturing the syntax and some of the semantics

of cloud applications. This meta-model can be used

by developers to better understand cloud applications

independent of any speciﬁc cloud development envi-

ronment. This meta-model will serve as a ﬁrst step to-

ward a cloud modeling language that we are currently

working on.

Future directions include reﬁning the syntax and

deﬁning semantics of the proposed reference model,

mapping the reference model to different cloud plat-

forms, and creating a platform independent modeling-

language for cloud applications.

REFERENCES

Armbrust, M., Fox, A., Grifﬁth, R., Joseph, A., Katz, R.,

Konwinski, A., Lee, G., Patterson, D., Rabkin, A.,

Stoica, I., et al. (2009). Above the clouds: A berkeley

view of cloud computing. EECS Department, Univer-

sity of California, Berkeley, Tech. Rep. UCB/EECS-

2009-28.

CA Labs (2009). Cloud computing Web-Services offering

and IT management aspects. In OOPSLA09, 14th con-

ference companion on Object Oriented Programming

Systems Languages and Applications, pages 27–39.

Charlton, S. (2009). Model driven design and operations for

the cloud. In OOPSLA09, 14th conference companion

on Object Oriented Programming Systems Languages

and Applications, pages 17–26.

Frey, S. and Hasselbring, W. (2010). Model-Based migra-

tion of legacy software systems into the cloud: The

CloudMIG approach. In WSR2010, 12th Workshop

Software-Reengineering, pages 1–2.

Google (2010). Google app engine. Retrieved: December

2010, from http://code.google.com/appengine/.

Matthews, C., Neville, S., Coady, Y., McAffer, J., and

Bull, I. (2009). Overcast: Eclipsing high proﬁle open

source cloud initiatives. In OOPSLA09, 14th con-

ference companion on Object Oriented Programming

Systems Languages and Applications, pages 7–15.

Maximilien, E. M., Ranabahu, A., Engehausen, R., and An-

derson, L. C. (2009). Toward cloud-agnostic middle-

wares. In OOPSLA09, 14th conference companion

on Object Oriented Programming Systems Languages

and Applications, pages 619–626.

Microsoft (2010). Windows azure microsoft’s cloud ser-

vice platform. Retrieved: December 2010, from

http://www.microsoft.com/windowsazure/.

Sirtl, H. (2008). Software plus Services: New IT-and

Business Opportunities by Uniting SaaS, SOA and

Web 2.0. In IEEE EDOC’08, 12th International En-

terprise Distributed Object Computing Conference,

pages 1541–7719.

Tsai, W., Sun, X., and Balasooriya, J. (2010). Service-

Oriented Cloud Computing Architecture. In ITNG10,

7th International Conference on Information Technol-

ogy: New Generations, pages 684–689.

Zhang, L. J. and Zhang, J. (2009). Architecture-Driven vari-

ation analysis for designing cloud applications. In

IEEE CLOUD09, 2nd International Conference on

Cloud Computing, pages 125–134.

Zhang, W., Berre, A. J., Roman, D., and Huru, H. A. (2009).

Migrating legacy applications to the service cloud. In

OOPSLA09, 14th conference companion on Object

Oriented Programming Systems Languages and Ap-

plications, pages 59–68.

A REFERENCE MODEL FOR DEVELOPING CLOUD APPLICATIONS

103