TOWARDS THE NEXT GENERATION OF MODEL DRIVEN CLOUD

PLATFORMS

Javier Esparza-Peidro and Francesc D. Mu˜noz-Esco´ı

Instituto Tecnol´ogico de Inform´atica, Universidad Polit´ecnica de Valencia, Camino de Vera s/n, Valencia, Spain

Keywords:

Cloud, Cloud computing, Cloud platform, Scalability, Model driven, Model.

Abstract:

Current cloud platforms are based on two mainstream models: Infrastructure as a Service (IaaS) and Platform

as a Service (PaaS). Both approaches entail strenghts and weaknesses that we collect and present in this paper

and we conclude the need to devise a new approach, based on graphical models, to overcome the imposed

limitations. This model driven approach is introduced and slightly described, highlighting the importance of a

comprehensive scalable modeling language and uncovering new research lines for designing self-manageable

cloud platforms.

1 INTRODUCTION

Current cloud platforms are based on two mainstream

models: Infrastructure as a Service (IaaS) and Plat-

form as a Service (PaaS) (Vaquero et al., 2008), (Fos-

ter et al., 2009), (Lenk et al., 2009) . Both approaches

entail strengthsand weaknesses that we will try to col-

lect and present in the following paragraphs.

The IaaS model (Amazon, 2011) is aimed at

professionals with system administration skills since

the provider does typically supply a set of services

for managing virtual machines and virtual networks.

Deﬁning machine settings, operating system conﬁgu-

rations and network architecture is the users’ respon-

sibility, and requires expertise in all these domains.

Deploying an application in this scenario is not an

easy task either, since each application component

must be distributed to the correct machine, installed

and started, and the whole process must be correctly

orchestrated to have the overall application properly

working. Furthermore, managing application scaling

usually involves developing some additional software

to measure and detect heavy trafﬁc conditions and

scaling out some key application components. Lately

some cloud offers include tools for automatically de-

tecting these conditions and scaling out without user

intervention.

On the other hand, the PaaS model (Google,

2011), (Azure, 2011) hides all the above mentioned

complexities and providesa consistent high level soft-

ware platform for developing scalable applications.

The intricate details of conﬁguringthe underlyinglay-

ers, connecting components and on-demand scaling

are automatically managed by the platform and cov-

ered by a collection of APIs which provide high level

constructs to assist in the application development.

This approach typically imposes a speciﬁc program-

ming language, and usually a new application model

must be followed, forcing the developer to organize

the application components in certain way. Conse-

quently legacy systems are difﬁcult to migrate to the

new platform, since reengineering processes are re-

quired. Moreover, this model typically focuses on

the developmentof new management applications, re-

sulting useless in systems-oriented solutions where

the different components are interconnected network

servers, as in a corporate network.

Therefore, no approach is suitable for every case,

and each one has its speciﬁc shortcomings. IaaS is

adequate for legacy systems or system-oriented appli-

cations provided that the user has deep understanding

of systems administration and assuming some semi-

automated scaling procedures. Conversely, PaaS is

appropriate for new business applications tailored for

a particular programming platform where all scalabil-

ity aspects and much of the application conﬁguration

is automatically carried out by the platform.

To summarize, IaaS is more open and versatile,

in exchange for extra management effort, while PaaS

is more closed and limited, but it automates nearly

any aspect of the platform, letting the developer to

focus on the real application development, which will

be irrevocably bound to the platform on which it was

developed.

494

Esparza-Peidro J. and D. Muñoz-Escoí F..

TOWARDS THE NEXT GENERATION OF MODEL DRIVEN CLOUD PLATFORMS.

DOI: 10.5220/0003444504940500

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

ISBN: 978-989-8425-52-2

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

In this paper we try to conciliate both worlds,

promising to obtain the same versatility and platform

independence as IaaS solutions, and reaching au-

tomation levels very similar to the PaaS counterparts.

To this end, we devise a new approach that merges

the best characteristics of both solutions, and assists

the developer with graphical models, inspired by the

Model Driven Engineering (MDE) principle. Besides

helping in the speciﬁcation steps, our methodology

will be able to automatize application deployment and

to build scalable self-administering(i.e., autonomous)

applications.

The rest of the paper is organized as follows: sec-

tion 2 presents our model driven approach and intro-

duces an overview of the overall methodology. Sec-

tion 3 discusses a key element in this methodology,

the language used for modeling scalable applications.

We list some of its most important characteristics and

we show a preview of a platform-independent lan-

guage which may meet such characteristics. Section 4

suggests some issues which should be solved in order

to use such language in a concrete environment. Sec-

tion 5 outlines the most important features that a plat-

form should provide in order to support the presented

methodology. Finally, conclusions of this work are

presented in section 6.

2 MODEL DRIVEN APPROACH

As it is known, a software product can become a

very complex creature, so much so that thousands

of developers may be involved in the construction

of a single prototype. To address such a hard job

we need very powerful tools and well deﬁned pro-

cedures. The Software Engineering discipline (De-

Marco, 1979) emerged to give solution to these prob-

lems. It deﬁnes a set of best practices and speci-

ﬁes a concrete sequence of steps that any application

development process should go through in order to

guarantee a minimum quality level. This process can

be roughly broken into the conceptualization phase

and the implementation phase. The ﬁrst stage in-

volves modeling any aspect of the application, includ-

ing static and dynamic characteristics, so that the de-

signer can deﬁne with great detail the entire applica-

tion in advance, before initiating the implementation

tasks. To this end the designer needs a strong model-

ing language, capable of capturing any software prop-

erty. Most of the times, the chosen language is the

Object Management Group’s Uniﬁed Modeling Lan-

guage (UML) (UML, 2011), (Booch et al., 2005).

Nowadays any serious software project begins

with a robust requirements speciﬁcation and a com-

plete collection of models describing in detail the

structure and behavior of the software. The latest

software development methodologies take advantage

of this approach, taking as input the software mod-

els and trying to automatize the next part of the pro-

cess, that is to say, the software construction. This

methodology is coined as Model Driven Engineering

(Kent, 2002), (Schmidt, 2006) and the Object Man-

agement Group’s Model Driven Architecture (MDA)

(MDA, 2011), (Kleppe et al., 2003) is one of the

best known initiatives in this ﬁeld. In MDA the de-

signer deﬁnes a Platform Independent Model (PIM)

by using UML, which describes the architecture and

functionality of the software, including action seman-

tics. This model is not bound to any speciﬁc plat-

form, rather it describes in an abstract way all aspects

of the modeled software. Then the PIM is translated

into one or more Platform Speciﬁc Models (PSMs),

which are models targeted to speciﬁc technological

platforms. PSMs are ﬁnally translated into executable

code. Translations between models are considered as

model transformations, and a language called Query,

Views, Transformations (QVT) (QVT, 2011) is pro-

vided for deﬁning such mappings.

Working with abstract models has a number of ad-

vantages: (1) models allow engineers to reason about

the relevant application properties, ignoring minor de-

tails usually linked to speciﬁc platforms, (2) they in-

crease productivity, since developers work with high

level languages and concepts they are comfortable

with, avoiding low level and error-prone details, and

making easy communication between engineers, and

(3) they provide platform-independence, portability

and cross-platforminteroperability,due to the abstract

nature of the model, which avoids any binding with a

particular platform, and increases the lifespan of the

solution.

Our aim is to follow the presented model driven

approach for designing and deploying scalable ar-

chitectures on a cloud platform. The user captures

every aspect of the application architecture in the

model, specially the scalability features. The plat-

form is responsible for everything else, including dis-

tribution, deployment, execution, monitorizing, on-

demand scaling, etc. The application just works. In

this sense, the application model is some sort of ex-

ecutable speciﬁcation. To the best of our knowledge,

today no cloud platform requires the speciﬁcation of

an abstract model in order to deploy a complete solu-

tion, or at least not in the sense we are proposing in

this paper.

In Figure 1 we illustrate this methodology. The

software architect deﬁnes the application model along

with the application bits. Both elements may be pack-

TOWARDS THE NEXT GENERATION OF MODEL DRIVEN CLOUD PLATFORMS

495

Figure 1: Model driven methodology.

aged in just one bundle that will be called executable

model. The executable model is then injected into

the platform. The platform analyzes the model and

creates a plan for deploying the different parts of the

application on the appropriate physical machines, ac-

cording to the application properties described in the

model. This plan introduces several advantages: (1)

application deployment can be fully automatized, (2)

the plan is able to devise a components monitoring

scheme, making possible a fast reaction of the plat-

form and/or the application components when dif-

ferent events occur (workload variations, component

failures, etc), and (3) either the plan or the model may

hold different rules that allow the implementation of

self-managed components.

3 SCALABLE COMPONENT

LANGUAGE

The key component of the methodology advocated

in this document is the language used to model the

scalable application. To keep the language platform-

independent it should not focus on intracomponent

details, rather it should be positioned at the architec-

tural level, being able to deﬁne abstract components

and connections between those components. Fur-

thermore, the language must be expressive enough to

catch all the scalability properties related with the ap-

plication components. The minimum and maximum

number of instances of one component, or the circum-

stances under which the component gets replicated

are some examples of scalability features.

Therefore we must ﬁnd a modeling language

which meets the above-mentioned requirements. Lit-

erature searches have only given a fairly good result

which loosely matches our expectations. It is the

UML component and deployment diagram deﬁned by

OMG, which targets the deﬁnition of an application at

the architectural level. This model is comprehensive

enough for deﬁning abstract components and connec-

tions between components, but unfortunately the re-

sulting diagrams do not collect characteristics related

with scalability. Trying to capture these properties in

the model is ardous and confusing, since the language

was not designed for that purpose.

For example, in a component diagram there is no

way to specify that a component may replicate in n in-

stances, or that the set of instances may growor shrink

within some limits and under certain circumstances.

Also, connecting scalable components, which at run-

time may expand in many instances, can not be solved

with simple interface connections. Rather, complex

connection elements should be considered, such as

load balancers, proxies, etc.

For the above reasons, we believe that a new mod-

eling language must be designed. The language must

be rich enough to describe the individual components

of any distributed application, as well as its connec-

tions. Regarding scalability, the language must pro-

vide a means for deﬁning when, where and how many

replications of each component may take place. Also,

the language must supply tools for accurately speci-

fying different types of connections between compo-

nents, considering the multivalued nature of such re-

lationships in scalable architectures. Another goal to

achieve is to design a language which software archi-

tects feel comfortable with.

To attain the discussed objectives the most suit-

able approach involves taking features from a widely

spread modeling language - with similar purposes -

and redeﬁning some of its graphical components and

introducingsome newones. We are currently working

on the deﬁnition of such a modeling language, though

some extra work is needed to have a precise speciﬁ-

cation.

In Figure 2 we present a diagram written with such

hypotheticalmodeling language, and we present some

of the challenges the language will need to face to

properly design scalable architectures. The diagram

closely resembles the UML component and deploy-

ment diagram, facilitating its understanding and re-

ducing the learning curve required by software archi-

tects. The example depicts an elaborated business ap-

plication, which is composed of four connected com-

ponents: a simple HTTP front end which forwards re-

quests to the next component, a web application im-

plementing the application GUI, a business applica-

tion containing the application logic and a back end

SQL database server. Each component may expose a

public interface, represented by the familiar ball sym-

bol.

The ﬁrst three components are scalable, that is,

there may be several instances at runtime. It is rep-

resented by a multiple box. The minimum and max-

imum number of instances of each component is de-

CLOSER 2011 - International Conference on Cloud Computing and Services Science

496

Figure 2: Application model example.

ﬁned at the bottom right corner. For example, at exe-

cution time one or more instances of the web applica-

tion may be concurrently running.

In a real environment, each component runs

within a concrete execution environment, which pro-

vides some facilities and imposes some requirements

to the embedded component. The execution environ-

ment is represented by a 3D box which surrounds

the component. In the example, the web application

component must run inside a web application server,

whereas the business application requires an applica-

tion server to successfully run.

Each component can deﬁne scalability proper-

ties, which describe how the component instance set

should grow and shrink at runtime. This feature is

speciﬁed inside a ≪scalability≫ compartment in the

component. In the example, the web application com-

ponent should be replicated when the average proces-

sor consumption of all its instances reaches the 90%.

Similarly, when the average processor utilization of

all instances reaches the 30%, some instances should

be destroyed.

Each component requires speciﬁc resources, such

as processor and memory, to successfully run. This

aspect is deﬁned inside a ≪resources≫ compartment

in the component. In the example, the business ap-

plication component requires a 2GHz processor and

4Gb of main memory to run.

Finally, components must be able to connect, in

such a way that one component consumes the inter-

faces published by other components. Connections

do not entail any problem in 1 to 1 runtime scenarios,

that is to say, when one instance of a component con-

nects to another single instance of a second compo-

nent. Troubles arise when considering contexts with

multivalued connections, in other words, when one

or more instances of a component connect to one or

more instances of another component. In such cases,

we consider two types of connections: anonymous

connections and named connections. The ﬁrst type

of connection, represented by a socket-like connector,

as the connection between the front end and the web

application components in the example, does forward

requests from the client to either of the differentserver

instances, without knowing the real identity of the ac-

tual replying server. This type of connection could

be easily implemented by a load balancer element. In

turn, a named connection, represented by an arrow,

like the connection between the web application and

the business application components in the example,

describes a connection where the client knows all the

server instance identities at all times, being able to

choose the most appropriate instance to serve its re-

quests.

4 CLOUD OPERATIONAL

DETAILS

A language which looks like the one introduced in the

previous section seems sufﬁcient to deﬁne any scal-

able architecture with a reasonable detail level. How-

ever, it needs some additional declarations in order to

be executable by a concrete cloud platform. Describ-

ing these features in the modeling language would

probably bind the language to the speciﬁc platform

requiring those features. That is why we present these

operational features in a different section. In the fol-

lowing paragraphs we discuss some of the most im-

portant issues which should be considered in order

to turn an abstract model into an executable model

inside a particular platform. It is not an exhaustive

enumeration, but the reader will get an idea about the

extensions needed to that end.

The proposed modeling language allows to de-

scribe components and execution environments in an

abstract fashion, explicitly avoiding dependencies on

a concrete platform. Determining the components ab-

straction level, as well as the relationship between

components and execution environments depends on

the modeled system type and is the architect’s re-

sponsibility. For example, in a corporate network

model, a component may be a web server running

within a particular operating system, whereas in a

business web application, a component may be a web-

site running within a web server which in turn runs

inside a particular operating system. Therefore, the

same element, the web server, may be considered a

component or execution environment depending on

the context. This ﬂexibility, though desirable at the

modeling level, introduces confusion and an extra de-

gree of freedom very difﬁcult to manage at the oper-

ational level. Therefore, each particular cloud plat-

form should deﬁne a ﬁxed set of commonly accepted

execution environments within which the application

components will be deployed, installed and executed.

On the other hand, the proposed model deﬁnes the

application composition but it does not deﬁne its be-

havior. The behavior is provided by the actual appli-

cation bits, which are typically broken down into sev-

eral pieces, each one implementing a particular com-

TOWARDS THE NEXT GENERATION OF MODEL DRIVEN CLOUD PLATFORMS

497

ponent of the overall system. Each component bits

may be provided as a package or as a set of URLs

from which the actual bits could be automatically

downloaded and assembled. If URLs are supplied,

the platform could provide automatic application up-

grades when URL content updates are detected. Fur-

thermore, if URL contents are properly packaged and

the platform provides some means of automatically

installing new software, then the deployment, instal-

lation and upgrade of applications could be fully au-

tomatized by the platform.

The combination of the application model and the

software bits (or URLs) could be packaged inside

a bundle which makes application distribution easy.

If the bundle contains the software bits it will take

up much space. However, if it does only contain

URLs, the ﬁle could take just some kilobytes. This

last approach, together with the automatic deploy-

ment, installation and upgrade facilities mentioned

before could revolutionize today’s system administra-

tion area. Following this line of thought installing a

new full-ﬂedged corporate network could be as sim-

ple as downloading from some place a properly con-

ﬁgured bundle ﬁle and feed the platform with it, get-

ting in return a scalable, high available and fully func-

tional corporate network with all the corporate servers

automatically deployed and ready to accept new re-

quests. The platform will automatically download

the required software, distribute it among several ma-

chines and install it on each of these machines. Then

it will start the overall application and will make it

available to the outside world. If any update is de-

tected in the original URLs, the platform will auto-

matically undertake the upgrade process, constantly

maintaining an up-to-date system.

Yet another aspect to consider is the application

component’s lifecycle. The platform must publish a

stable and robust lifecycle which will be enforced for

all the deployed components. The platform will typ-

ically notify the components about lifecycle changes

by sending events. To that end, the components will

have to publish a speciﬁc interface, so that the plat-

form may convey the appropriate information at all

times. In order to avoid speciﬁc platform dependen-

cies, such interface should be deﬁned in some neutral

manner, using open and standard protocols, such as

HTTP or web services. These events will be sent to

the particular instances of each component at runtime.

For example, when a new instance of a component

gets created, the platform should send an event to the

rest of the instances, since they may need to perform

some particular operations in order to accommodate

the new instance. Similar considerations should be

taken when an old instance gets destroyed or fails, or

when the application must be updated, etc.

To conclude this section, we would like to sug-

gest that in some cases the platform will have to pro-

vide special components to ﬁll some gaps left by the

scalable modeling language. These components will

not be standard application components, but part of

the platform instead, even though they could be made

available as standard components. We will support

this thesis with an example. As presented above, the

scalable modeling language provides a way to deﬁne

the resources that each component needs for its suc-

cessful execution. One of these resources should be

the storage. In this way, when a component instance

gets created it receives the speciﬁed amount of stor-

age, probably mounted as a local partition or similar.

This storage may be used by the instance at will while

it is active. When the instance is destroyed, the asso-

ciated storage should also be destroyed, along with

the rest of allocated instance’s resources. With this

approach, data could not persist across different sys-

tem executions, or be shared by all the instances of

the same component. To solve this type of shortcom-

ings, the platform should provide special components

which offer the required functionality. In the storage

case, the special component could be modeled either

as a stand-alone component which provides shared

and persistent storage to a set of client components,

or as a special feature of the platform which should be

speciﬁed by using some sort of platform-dependent

notation. Notice that the persistent storage can not

be included as an out-of-the-box property in the pro-

posed abstract modeling language, since depending

on the platform this feature will be provided with a

different system implementation, with diverse com-

munications protocols and special properties regard-

ing scalability, fault tolerance, efﬁciency and other as-

pects.

5 THE CLOUD PLATFORM

So far, we have explained our model driven approach,

setting the model as the cornerstone of the whole

process. Needless to say, such an executable model

would not make sense without a full-ﬂedged platform

which supports the exposed methodology. Our ap-

proach demands a highly automated platform, capa-

ble of managing all the details of running scalable

applications without requiring any user intervention.

Modern platforms should go one step beyond though,

and implement the concept of autonomic comput-

ing (Kephart and Chess, 2003), (Kramer and Magee,

2007), which aims to obtain self-managed systems.

In the following paragraphs we present some of the

CLOSER 2011 - International Conference on Cloud Computing and Services Science

498

features a model driven platform should implement.

First and foremost, the platform will cover a real

datacenter. Whether the datacenter is homogeneous

or heterogeneous, or if it must comply with certain

network architecture or not is not relevant to this dis-

cussion and does only have to do with the platform

versatility and applicability. The datacenter may be

speciﬁed by using a particular computer network di-

agram, like Cisco-alike diagrams, which have be-

come the de facto standard for describing network

topologies. On the other hand, the datacenter physi-

cal infrastructure may also be dynamically discovered

(Breitbart et al., 2004), (Jin et al., 2006), relieving the

administrator of the burden of providing such infor-

mation and ensuring up-to-date data, though some in-

accuracies may arise. This autodiscovery facility is

extremely useful when new machines are added to the

pool, since no speciﬁc conﬁguration protocols are re-

quired.

Secondly, the platform should understand per-

fectly the scalable modeling language, as well as the

required extensions used for deﬁning the scalable ap-

plication properties. Once the application model has

been submitted, the platform automatically analyzes

its structure, properties and requirements and tries to

conciliate them with the physical infrastructure. This

process will typically result in a deployment plan for

distributing the different elements of the application

to the physical machines. Then most of the elements

of the application will be virtualized and transferred

to the planned locations. The devised plan must be

dynamic, since the datacenter infrastructure condi-

tions may change in the course of the application ex-

ecution. For example, a machine may fail due to a

power supply crash, or most of the datacenter ma-

chines may be busy because of occasional heavy de-

mands coming from other applications running in the

same cloud. Furthermore, when the concrete ma-

chines for deploying the application must be chosen,

the deployment plan should take into account high

availability, energy consumption and workload pre-

diction issues, in addition to the application speciﬁc

requirements.

Regarding high availability (Cristian, 1991), if a

component must be replicated, the different instances

will tend to be transferred to machines located in dif-

ferent fault domains. A fault domain includes all the

machines and devices which are likely to fail at the

same time, maybe because they belong to the same

computer rack, or because they are powered by the

same power line, or because they are located inside

the same network segment. Also, the platform will

take the required measures to ensure no single point

of failure exists on the actual application layout, and

if a component fails, it will undertake all the needed

actions to recover the failed component and restart it

transparently.

Also, while deploying the different components of

the application, the platform should try to do its best

on power consumption savings (Berl et al., 2010),

(Beloglazov and Buyya, 2010), taking into account

not only single machines consumptions, but network

devices and cooling systems consumption as well. To

that end, when a component must be transferred to a

new machine, busy machines will typically be chosen

ﬁrst, since they are already working and consuming

power and running a new component on them would

consume less power than switching on a new ma-

chine. Other similar measures should be implemented

for the sake of saving energy.

Finally, predicting workload behavior (Akaike,

1969) (Smith et al., 1998) could signiﬁcantly improve

the performance and response time of the deployed

applications, helping to allocate resources in advance

and reducing the delay inherent in the distribution and

launching of new elements.

6 CONCLUSIONS

In this paper we have introduced a new methodology

for designing cloud platforms, due to the difﬁculties

found in current approaches. This methodology fol-

lows the model driven paradigm, where the whole

process starts with a user-deﬁned application model

which is injected into the platform. To that end, we

list the most important features that such a language

should have, and we present a preview of a famil-

iar modeling language which meets all requirements

for modeling scalable architectures. We are actively

working on the formal deﬁnition of such language and

we will make the results available in the short term.

Our approach requires a platform capable of auto-

matically handling almost every aspect of both the un-

derlying infrastructure and the applications deployed

on it. We collect our thinkings about all the character-

istics that a cloud platform should take into consider-

ation in order to support our fully automatized model

driven vision.

ACKNOWLEDGEMENTS

This paper has been partially supported by EU

FEDER and Spanish MICINN under research grant

TIN2009-14460-C03-01.

TOWARDS THE NEXT GENERATION OF MODEL DRIVEN CLOUD PLATFORMS

499

REFERENCES

Akaike, H. (1969). Fitting autoregressive models for predic-

tion. Annals of the Institute of Statistical Mathematics,

21:243–247.

Amazon (2011). Amazon Web Services web site. http://

aws.amazon.com/.

Azure (2011). Microsoft Azure web site. http://

www.microsoft.com/windowsazure/.

Beloglazov, A. and Buyya, R. (2010). Energy efﬁcient allo-

cation of virtual machines in cloud data centers. Clus-

ter Computing and the Grid, IEEE International Sym-

posium on, 0:577–578.

Berl, A., Gelenbe, E., Di Girolamo, M., Giuliani, G.,

De Meer, H., Dang, M. Q., and Pentikousis, K. (2010).

Energy-Efﬁcient Cloud Computing. The Computer

Journal, 53(7):1045–1051.

Booch, G., Rumbaugh, J., and Jacobson, I. (2005). Uniﬁed

Modeling Language User Guide, The (2nd Edition)

(Addison-Wesley Object Technology Series). Addison-

Wesley Professional.

Breitbart, Y., Garofalakis, M., Jai, B., Martin, C., Rastogi,

R., and Silberschatz, A. (2004). Topology discovery in

heterogeneous IP networks: the NetInventory system.

Networking, IEEE/ACM Transactions on, 12(3):401–

414.

Cristian, F. (1991). Understanding fault-tolerant distributed

systems. Commun. ACM, 34(2):56–78.

DeMarco, T. (1979). Structured Analysis and System Spec-

iﬁcation. Prentice Hall PTR, Upper Saddle River, NJ,

USA.

Foster, I., Zhao, Y., Raicu, I., and Lu, S. (2009). Cloud

Computing and Grid Computing 360-Degree Com-

pared. ArXiv e-prints, 901.

Google (2011). Google App Engine web site. http://

code.google.com/appengine/.

Jin, X., p. Ken Yiu, W., Member, S., Member, S.,

h. Gary Chan, S., Member, S., and Wang, Y. (2006).

Network topology inference based on end-to-end

measurements. IEEE JSAC, 24:2182–2195.

Kent, S. (2002). Model driven engineering. In Butler,

M., Petre, L., and Sere, K., editors, Integrated Formal

Methods, volume 2335 of Lecture Notes in Computer

Science, pages 286–298. Springer Berlin / Heidelberg.

Kephart, J. O. and Chess, D. M. (2003). The vision of auto-

nomic computing. Computer, 36:41–50.

Kleppe, A. G., Warmer, J., and Bast, W. (2003). MDA

Explained: The Model Driven Architecture: Practice

and Promise. Addison-Wesley Longman Publishing

Co., Inc., Boston, MA, USA.

Kramer, J. and Magee, J. (2007). Self-managed systems:

an architectural challenge. In 2007 Future of Software

Engineering, FOSE ’07, pages 259–268, Washington,

DC, USA. IEEE Computer Society.

Lenk, A., Klems, M., Nimis, J., Tai, S., and Sandholm,

T. (2009). What’s inside the cloud? an architectural

map of the cloud landscape. In Proceedings of the

2009 ICSE Workshop on Software Engineering Chal-

lenges of Cloud Computing, CLOUD ’09, pages 23–

31, Washington, DC, USA. IEEE Computer Society.

MDA (2011). OMG Model Driven Architecture web site.

http://www.omg.org/mda/.

QVT (2011). OMG Query, View, Transformation spec.

http://www.omg.org/spec/QVT/1.0/.

Schmidt, D. C. (2006). Model-driven engineering. IEEE

Computer, 39(2).

Smith, W., Foster, I., and Taylor, V. (1998). Predicting ap-

plication run times using historical information. In

Feitelson, D. and Rudolph, L., editors, Job Schedul-

ing Strategies for Parallel Processing, volume 1459 of

Lecture Notes in Computer Science, pages 122–142.

Springer Berlin / Heidelberg.

UML (2011). OMG Uniﬁed Modeling Language spec.

http://www.omg.org/spec/UML/.

Vaquero, L. M., Rodero-Merino, L., Caceres, J., and Lind-

ner, M. (2008). A break in the clouds: towards a

cloud deﬁnition. SIGCOMM Comput. Commun. Rev.,

39:50–55.

CLOSER 2011 - International Conference on Cloud Computing and Services Science

500