Model Driven Cloud Orchestration by Combining TOSCA and OCCI

Fabian Glaser, Johannes Erbel and Jens Grabowski

University of Goettingen, Institute of Computer Science, Germany

Keywords:

Cloud Computing, Open Cloud Computing Interface, Topology and Orchestration Speciﬁcation for Cloud

Applications, Metamodelling.

Abstract:

To tackle the problem of a cloud-provider lock-in, several standards have emerged in the recent years which

aim to provide a uniﬁed interface to cloud resources. The Open Cloud Computing Interface (OCCI) thereby

focuses on the standardization of a common API for Infrastructure-as-a-Service (IaaS) providers and the

Topology and Orchestration Speciﬁcation for Cloud Applications (TOSCA) focuses on the standardization of a

template language to enable the proper deﬁnition of the topology of cloud applications and their orchestrations

on top of an IaaS cloud. TOSCA thereby does not deﬁne how the application topologies are created on the

cloud. Therefore, it is worthwhile to analyse the conceptual similarities between the two approaches and

the possibilities to integrate both. In this paper, we provide an overview of the similarities between the two

standardization approaches. Furthermore, we deﬁne a concept of a fully model driven cloud orchestrator based

on the two standards.

1 INTRODUCTION

With the rise of cloud computing, a multitude of pro-

prietary cloud APIs became available that made it

hard for cloud costumers to switch between differ-

ent cloud providers. To tackle the problem of this

cloud-provider lock-in, consortia have been formed

to develop common standards for interfacing cloud

resources. The Open Cloud Computing Interface

(OCCI) (Nyr

en et al., 2016b), developed by the Open

Grid Forum (OGF)

1,2

, thereby aims to provide a stan-

dardized managing interface, enabling the customer

to manage cloud resources. It has been initially pub-

lished in 2010 and several open-source implementa-

tions have been developed since then supporting all

major open-source cloud middleware frameworks, in-

cluding OpenStack

, OpenNebula

and CloudStack

At a higher level of abstraction, the Organiza-

tion for the Advancement of Structured Information

Standards (OASIS)

is developing the Topology and

Orchestration Speciﬁcation for Cloud Applications

(TOSCA)(OASIS, 2013), a template format that aims

https://www.ogf.org/ogf/doku.php/start

All URLs have been last retrieved on 01/31/2017.

http://www.openstack.org

http://opennebula.org

https://cloudstack.apache.org

https://www.oasis-open.org/

to standardize the deﬁnition of application topolo-

gies for cloud orchestration. As such, it enables

the customer to deﬁne the topology of the cloud ap-

plication in a reusable manner and to deploy it on

TOSCA compliant IaaS clouds. TOSCA has been

initially published in 2013 and many major indus-

trial cloud-providers plan supporting it. In contrast to

OCCI, TOSCA does not deﬁne how the topology are

programmatically created on the cloud infrastructure

and leaves the implementation to the cloud provider.

While the approaches of TOSCA and OCCI are differ-

ent, both deﬁne a model for cloud resources. The goal

of this work is to identify the conceptual similarities

and differences between the two models and provide a

mapping between them where possible. Such a map-

ping is the ﬁrst step for building a fully model driven

cloud-provider agnostic cloud orchestrator that lever-

ages both TOSCA and OCCI for portable application

and infrastructure provisioning and deployment. The

remainder of this paper is structured as follows. First

we brieﬂy introduce the models of TOSCA and OCCI

in Section 2. Then we provide a conceptual compar-

ison and a mapping between the two models in Sec-

tion 3, followed by the discussion of the model driven

cloud orchestrator in Section 4. A feasibility study is

discussed in Section 5. We introduce related work in

Section 6. Finally, we draw our conclusions and give

an outlook on future work in Section 7.

644

Glaser, F., Erbel, J. and Grabowski, J.

Model Driven Cloud Orchestration by Combining TOSCA and OCCI.

DOI: 10.5220/0006372706720678

In Proceedings of the 7th International Conference on Cloud Computing and Services Science (CLOSER 2017), pages 644-650

ISBN: 978-989-758-243-1

2 BACKGROUND

Both TOSCA and OCCI deﬁne languages for mod-

elling cloud resources. Since they hence provide a

model for modelling they can be seen as metamod-

els (OMG, 2014). We introduce these metamodels in

the following.

2.1 TOSCA

According to the speciﬁcation (OASIS, 2013),

TOSCA is “a language to describe service compo-

nents and their relationships using a service topol-

ogy, and it provides for describing the management

procedures that create or modify services using or-

chestration processes.” Therefore, it is able to de-

scribe both the service structure as well as the pro-

cesses that can be executed on this structure. As the

time of this writing, two versions of TOSCA exist.

The ﬁrst is based on XML (OASIS, 2013), and the

second is based on YAML (OASIS, 2016). While

for TOSCA XML a XML Schema Deﬁnition (XSD)

schema exists, the TOSCA YAML version lacks of

a formal metamodel. A simpliﬁed metamodel of

TOSCA is depicted in Figure 1. A ServiceTemplate

captures the structure and the life cycle operations

of the application. It consists of a TopologyTemplate

and a Plan. Plans deﬁne how the cloud application

is managed and deployed. TopologyTemplates con-

tain EntityTemplates, which are NodeTemplates that

deﬁne e.g., the virtual machines or application com-

ponents, RelationshipTemplates that encode the rela-

tionships between the NodeTemplates, e.g., that a cer-

tain application component is deployed on a certain

virtual machine, or GroupTemplates

that allow to de-

ﬁne groups of NodeTemplates, which e.g. should be

scaled together. Additionally, TOSCA deﬁnes the En-

tityTemplates Capability and Requirement. Capabili-

ties are used to deﬁne that a NodeTemplate has a cer-

tain ability, e.g., providing a container for running ap-

plications, and Requirements are used to deﬁne that

a certain NodeTemplate requires a certain Capabil-

ity of another NodeTemplate. All EntityTemplates

can have Properties, e.g., an IP address for a virtual

machine, and a certain type that references an Enti-

tyType. The EntityType deﬁnes the allowed Proper-

ties through PropertyDeﬁntions, and have Interfaces,

which deﬁne the Operations that can be executed on

an instances implementing the type, e.g., the termina-

tion of a certain application component, or the restart

of a virtual machine. Operations have Parameters that

GroupTemplates and GroupTypes are currently part of

the TOSCA YAML rendering, but not part of the TOSCA

XML speciﬁcation.

deﬁne their input and output. In addition to parame-

ters for operations, TOSCA also allows to deﬁne input

parameters for Plans.

Besides this abstract metamodel, the TOSCA YAML

speciﬁcation deﬁnes normative types that should be

supported by each TOSCA conformant cloud orches-

trator. These normative types include e.g., base types

for cloud services and virtual machines. More details

on the model elements can be found in (OASIS, 2013)

and (OASIS, 2016).

2.2 OCCI

According to the OGF, “OCCI is a Protocol and API

for all kinds of Management tasks. OCCI was orig-

inally initiated to create a remote management API

for IaaS model based services, allowing for the de-

velopment of interoperable tools for common tasks

including deployment, autonomic scaling and moni-

toring.”

. The OCCI speciﬁcation comprises several

parts. The OCCI Core Model (Nyr

en et al., 2016b)

deﬁnes a model for cloud resources and their depen-

dencies. OCCI extensions deﬁne extensions of the

core model to be used for a speciﬁc domain. Several

extensions are already standardized, e.g., the OCCI

Infrastructure Extension (Metsch et al., 2016), which

deﬁnes compute, network and storage resources for

IaaS clouds, and the OCCI Infrastructure Extension

for the Platform-as-a-Service (PaaS) domain, that de-

ﬁnes additional resources for the PaaS Service level.

OCCI Renderings deﬁne how the OCCI Core Model

can be interacted with, e.g., the OCCI HTTP Protocol

(Nyr

en et al., 2016a) that deﬁnes how OCCI resources

can be managed over the HTTP protocol.

The OGF does not provide a formal metamodel

for OCCI. This gap has been recently addressed by

Merle et al. (Merle et al., 2015) and we adopt their

metamodel in scope of this work. Figure 2 depicts

the OCCI Core Model. The OCCI Core Model is

composed of eight elements. The Category is the

base type for all other classes and provides the neces-

sary identiﬁcation mechanisms. Categories have At-

tributes that are used to deﬁne the properties of a cer-

tain class, e.g., the IP address of a virtual machine.

Three classes are derived from Category: Kind, Ac-

tion, Mixin. Kind deﬁnes the type of a cloud entity,

e.g., a compute resource and Mixins deﬁne how an

entity can be extended. Both have Actions that de-

ﬁne which actions can be executed on an entity. The

cloud entities themselves are modelled by the class

Entity, which provides the base class for cloud Re-

sources, e.g., virtual machines, and Links that deﬁne

how the resources are connected.

http://occi-wg.org/

Model Driven Cloud Orchestration by Combining TOSCA and OCCI

645

S e rviceTemplate

TopologyTemplate

Plan

EntityT emplate

- na m e: String [0..1]

P ro p erties

- element: String [1 ..*]

- value: S tring [1..*]

NodeTemplate RelationshipT emplate

EntityT ype

- na m e: String

P ropertiesDefinitio n

- element: String [0 ..*]

- type: S tring [0..*]

NodeType RelationshipType

In terface

- na m e: String

Operation

- na m e: String

P a ra meter

- na m e: String

- type: S tring

GroupTypeGroupTemplate

CapabilitiyType

R equirement

RequirementType

Capab ility

+derivedFrom

0..1

+targetE lement

0..1

+type 1

+properties

0..1

+validMember

0 ..*

+ope rations

1 ..*

+entity T emplates 0 ..*

+inputP arameter

0 ..*

+interfaces 0 ..*

+plan

0 ..*

+sourceElement

0..1

+validS ource

0..1

+mem ber

0 ..*

+inputP arameter

0 ..*

+validT a rg et

0..1

+topologyTemplate

+outputParameter

0 ..*

+propertiesD e finition

0..1

Figure 1: Metamodel of TOSCA (adapted from (Bergmayr et al., 2016)).

Figure 2: Metamodel of OCCI Core (Nyr

en et al., 2016b).

In addition to the Core model, the OGF provides

extensions, which deﬁne the resources for a certain

cloud service level. For example, the OCCI Infras-

tructure Extension (Metsch et al., 2016) deﬁnes the

Resources for IaaS. It provides the deﬁnitions of the

Resources Compute, Network and Storage, and the

links that can be established between them, namely

StorageLink, which connects a compute resource to

a storage resource and NetworkInterface and IPNet-

workInterface which connect a compute resource to a

network resource.

3 MAPPING TOSCA TO OCCI

While both standards deﬁne a metamodel for cloud

resources, their focus is different. The focus of OCCI

is to provide a standardized API and it does not de-

ﬁne concepts to address reusability, composability,

and scalability. Instances of the OCCI metamodel are

not meant to be stored persistently and to be reused

later on as it is the goal of TOSCA. TOSCA on the

other side does not deﬁne how the deﬁned topology is

deployed by means of API calls to the cloud provider

as it is done with the OCCI HTTP rendering. Hence,

both approaches have their strengths and weaknesses

and it is worthwhile to investigate how to integrate

them.

Several concepts of TOSCA do not have a one-

to-one correspondence in OCCI. These are the con-

cepts for composability, namely the deﬁnition of Ca-

pabilities and Requirements, the concepts to achieve

scalability, namely Groups, Policies, and Parameters

and the concepts to achieve reusability, which are

ServiceTemplates and TopologyTemplates. These are

missing due to the different focus of OCCI. Nev-

ertheless, the mapping of most concepts is possible

and is summarized in Table 1. EntityTypes are used

to deﬁne reusable elements in TOSCA. They have

PropertyDeﬁnitions assigned, that allow to deﬁne the

properties that a certain EntityType is allowed to have.

This matches the purpose of OCCI Categories and

their Attributes. Additionally, EntityTypes have Inter-

faces that deﬁne the allowed operations. This matches

the Kinds and Actions in OCCI respectively. Hence,

we can map all elements that inherit from Entity-

Types, namely NodeTypes, RelationshipTypes, and

GroupTypes to OCCI Kinds. Their Operations be-

come Actions in OCCI and their Properties become

Attributes. For the deﬁnition of provisionable ele-

ments, TOSCA uses the concept of EntityTemplates,

namely NodeTemplates, RelationshipTemplates and

GroupTemplates. NodeTemplates get be transformed

into Resources and RelationshipTemplates can be

transformed in Links. Their is no one-to-one cor-

respondents for GroupTypes and GroupTemplates in

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

646

Table 1: Mapping of TOSCA elements to OCCI elements.

TOSCA element OCCI element

EntityType Kind

Capability/Requirement Mixin

Operation Action

Property Attribute

NodeTemplate Resource

RelationshipTemplate Link

OCCI. Nevertheless, EntityTemplates that form a

group in TOSCA can be transformed into a num-

ber of Resources and Links in OCCI. Capabilities

and Requirements are used to extend a certain Enti-

tyTemplate with certain functionality. This concept

can modelled by using OCCI Mixins and the impli-

cated RelationshipTemplates can be modelled by us-

ing Links. Based on this mapping we deﬁne the con-

cept of a fully model driven cloud orchestrator in the

next Section.

4 MODEL DRIVEN CLOUD

ORCHESTRATION

Both OCCI and TOSCA are actively developed and

have a vibrant research and user community. Hence,

they are still subject to change. By adopting a model

driven approach for a cloud orchestrator implementa-

tion, it is easier to cope with these changes, since most

of the code can be generated from formal metamod-

els and model transformations can be easily adapted

accordingly. For the proliferation of the standards,

it is important that open-source implementations are

provided. Currently, three open-source implementa-

tions of TOSCA are available, which provide both

the modelling of TOSCA templates and the orches-

trated launch of the deﬁned infrastructure: Cloud

Application Management Framework (CAMF) (Loul-

loudes et al., 2015) and OpenTOSCA (Binz et al.,

2013) are provided from academia, while Cloudify

is developed in the industry. OCCI support is im-

plemented for all major open-source cloud platforms,

and with OCCIWare

efforts exist to provide an in-

tegrated Integrated Development Environment (IDE)

for the modelling and orchestration of cloud resources

with help of the OCCI metamodel. However, the ap-

proaches listed above are neither fully model driven

nor do they combine both standards. Therefore,

we propose a fully model driven cloud orchestra-

tor to provide a playground for future extensions on

http://getcloudify.org

http://www.occiware.org/

Workflow

Metamodel

Deployment

Workflow

TOSCA Model

TOSCA

Metamodel

Instance of

OCCI Model

OCCI

Metamodel

Instance of

M2M

Synchronisation

Modeling

Provisioning and

Deployment

Runtime

Provisioning

IaaS Cloud

M2M

Figure 3: Model driven orchestration with TOSCA and

OCCI.

TOSCA and OCCI. A conceptual overview is de-

picted in Figure 3.

In the modelling step, cloud resources are mod-

elled according to the TOSCA metamodel. A Model-

to-Model (M2M) transformation is used to generate

a OCCI-compliant resource model from the TOSCA

model. From this model, a deployment and provision-

ing workﬂow is generated (see e.g., (Breitenb

ucher

et al., 2014) or (Lushpenko et al., 2015) for automatic

deployment and provisioning workﬂow generation).

The deployment and provisioning workﬂow then uti-

lizes the information stored in the OCCI model to

initiate the correspondent API calls over the OCCI

HTTP rendering to provision the deﬁned resources in

the IaaS cloud. We will exemplify this workﬂow in

the next Section.

5 FEASIBILITY STUDY

To evaluate the feasibility of the conceptual mapping

and the orchestration workﬂow introduced above, we

use a small TOSCA topology example and will go

through the different transformation steps. Since,

the current OCCI implementations do not support the

PaaS layer yet, we restrict the discussion to the IaaS

layer. However, the approach is valid for all service

layers, since the same metamodel is used.

5.1 Setup

We implemented the M2M transformation using

the Eclipse Modeling Framework (EMF)

and the

Eclipse Epsilon Transformation Language (ETL)

As a TOSCA metamodel, we used the XSD provided

by the standard and utilized the OCCI metamodel pro-

vided by (Merle et al., 2015). We used this model

transformator to transform the initial TOSCA topol-

ogy to an OCCI resource model.

In practice, the Resources, Kinds and Mixins that can

be utilized in the OCCI model depend on the speciﬁc

https://www.eclipse.org/modeling/emf/

http://www.eclipse.org/epsilon/doc/etl/

Model Driven Cloud Orchestration by Combining TOSCA and OCCI

647

IaaS cloud management framework. Our test setup

is based on OpenStack

and the OCCI implementa-

tion OpenStack OCCI Interface (OOI)

. We used

the Java OCCI library jocci-api

to implement an

OCCI model extractor that is able to extract the avail-

able Resources, Kinds and Mixins from our Open-

Stack deployment and serialize it to a model artefact

which conforms to the utilized OCCI metamodel. The

model transformator links to these available Mixins

and Kinds during the transformation of the TOSCA

model.

5.2 Example TOSCA Topology

The logical structure of the TOSCA model is de-

picted on the right hand side in Figure 4. We use

the graphical notation used in the standard (OASIS,

2016) to depict the TOSCA topology. The Properties

of the NodeTemplates are omitted here for brevity.

The topology consists of two virtual machines vm1

and vm2, which are connected to the network network

via port1 and port2 respectively. In addition, vm1

is attached to an external block-storage device vol-

ume. The virtual machines, the ports, the volume and

the network are modelled as TOSCA NodeTemplates.

The connections between them are modelled with Re-

lationshipTemplates. The virtual machines have the

Capabilities OperatingSystem, which models the op-

erating system to be used, and Container, which mod-

els the technical speciﬁcation of the virtual machine,

e.g., the number of compute cores, and RAM. To be

able to attach the block-storage volume to vm1, the

NodeTemplate volume has the Capability Attachment.

To be able to bind the ports to the virtual machines

and link them to the network, the ports have the Ca-

pabilities Linkable and Bindable. Finally, the corre-

sponding Requirements are modelled for the Node-

Templates to be able to establish the relationships.

All NodeTemplates, RelationshipTemplates, and Ca-

pabilities use TOSCA normative EntityTypes as they

are deﬁned in the TOSCA YAML speciﬁcation. An

overview of the utilized types is given in the second

column of Table 2.

5.3 Corresponding OCCI Model

The results after transforming the example into an

OCCI model are shown on the left hand side of Fig-

ure 4 in an UML object diagram. The NodeTemplates

vm1 and vm2 are transformed into Resources with the

OCCI Kind Compute. The NodeTemplate volume is

https://www.openstack.org/

https://github.com/openstack/ooi

https://github.com/Misenko/jOCCI-api

Table 2: Mapping of TOSCA Types to OCCI Elements.

Element TOSCA Type OCCI Element

vm1, vm2 tosca.nodes.Compute Compute

network tosca.nodes.network.Network Network + IPNetwork

volume tosca.nodes.BlockStorage Storage

port1, port2 tosca.nodes.network.Port -

OperatingSystem tosca.capabilities.OperatingSystem Mixin (OpenStack speciﬁc)

Container tosca.capabilities.Container Mixin (OpenStack speciﬁc)

Linkable tosca.capabilities.network.Linkable -

Bindable tosca.capabilities.network.Bindable -

Attachment tosca.capabilities.Attachment -

LinksTo tosca.relationships.network.LinksTo NetworkInterface + IPNetworkInterface

BindsTo tosca.relationships.network.BindsTo NetworkInterface + IPNetworkInterface

AttachesTo tosca.relationships.AttachesTo StorageLink

transformed into a Resource with the Kind Storage,

and the NodeTemplate network is transformed into a

Resource with the Kind Network. In the OCCI Infras-

tructure model, there is no corresponding element to

the NodeType Port, and the corresponding informa-

tion is stored in the Links with the OCCI Kind Net-

workInterface which connects the virtual machines to

the network. These Links are additionally associated

with the Mixin ipnetworkinterface to allow to setup

speciﬁc IP addresses. The attachment of the block-

storage to vm1 is transformed into a Link of the OCCI

Kind StorageLink. The Capabilities OperatingSystem

and Container are transformed into references to the

cloud-provide speciﬁc Mixins to model images with a

certain operating system, and certain virtual machine

types respectively. The Resource network is associ-

ated to the Mixin ipnetwork to allow the IP speciﬁc

conﬁguration of the network. An overview of the

mapped OCCI Kinds and Mixins is given in the third

column of Table 2.

5.4 Provisioning Order With the OCCI

HTTP Protocol

Figure 5 shows the provisioning plan for the example.

Each action in the diagram corresponds to a single

call to the OCCI server. The Resources vm1, vm2,

network and volume can be provisioned in parallel.

Links can be created, when the two corresponding Re-

sources are ready.

5.5 Findings

The generated model is fully conformant with the

OCCI metamodel deﬁned by (Merle et al., 2015).

We saw that most of the utilized TOSCA normative

Types have a one-to-one correspondence with OCCI

elements. In case of the many-to-one relationship of

the ports in the example, we implemented a post-

processing in the transformation step. In this step,

we replaced the created port Resource and the corre-

sponding Links with a single Link connecting the vir-

tual machines to the Network. Such a post-processing

step might be necessary also for other TOSCA nor-

mative types. There are also some cases where there

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

648

BindsTo

Compute

vm1

Capabilities

BlockStorage

volume

Capabilities

Attachment

Network

network

Bindable

Container

OperatingSystem

Requirements

Attachment

Port

port1

Requirements

Bindable

Linkable

Port

port2

Requirements

Bindable

Linkable

Compute

vm2

Capabilities

Bindable

Container

OperatingSystem

Capabilities

Linkable

LinksTo

AttachesTo

vm1: Compute vm2: Compute

flavor1: Mixin

flavor2: Mixinimage1: Mixin image2: Mixin

vm1linksToNetwork: NetworkInterface

vm2linksToNetwork: NetworkInterface

vm1linksToVolume: StorageLink

volume: Storage

network: Network

ipnetworkinterface: Mixin

ipnetwork: Mixin

TOSCA OCCI

Figure 4: Transformation of an example TOSCA topology to OCCI.

provision volume

provision vm1

provision network

provision vm2

attach volume to

vm1

link vm1 to network

link vm2 to network

Figure 5: Example Provisioning Plan.

is a one-to-many relationship, and one TOSCA ele-

ment might correspond to several elements in OCCI,

e.g. when a GroupTemplate is used to control the

scaling of several other NodeTemplate. Current IaaS

middlewares impose certain restrictions on what can

be provisioned, such that the Capabilities deﬁned in

the TOSCA model need to be mapped to the available

Mixins. Such a map would need to be provided for

each IaaS infrastructure. Overall, the results of this

initial feasibility study are promising and it showed

that TOSCA and OCCI can be used complementary

for model driven cloud orchestration.

6 RELATED WORK

Besides TOSCA, several other orchestration template

formats exist, which have been developed by differ-

ent cloud providers or communities, e.g., OpenStacks

Heat Orchestration Template Language

and the

Amazons CloudFormation template format

. They

are not considered in this paper, since our focus is

on interoperability of standards. Merle et al. (Merle

et al., 2015) deﬁned a metamodel for OCCI with help

of EMF to provide a common basis for the genera-

tion and conformance testing of OCCI tools. This

metamodel is used by (Paraiso et al., 2016) to model

the deployment of applications with help of con-

https://wiki.openstack.org/wiki/Heat

https://aws.amazon.com/cloudformation/

tainers. Both works have been published in scope

of the OCCIWare

project, that aims to provide a

fully integrated IDE to support the whole cloud ap-

plication management life cycle on multiple clouds

based on OCCI. Interoperability with TOSCA is

not considered. With the Eclipse Incubation Project

CAMF (Loulloudes et al., 2015), Loulloudes et al.

attempt to build a whole IDE to manage cloud ap-

plications with the help of TOSCA. In the scope

of the project different adapters have been developed

to deploy the deﬁned TOSCA topology on multi-

ple clouds. However, no model driven mapping and

interaction with OCCI is provided. Regarding the

modelling of cloud applications, several extensions

to UML have been developed to capture cloud appli-

cation speciﬁcs, e.g., (Bergmayr et al., 2014), (Ka-

mali et al., 2014), (Guill

en et al., 2013). In addition,

Bergmayr et al. (Bergmayr et al., 2016) show how

to convert reﬁned UML models to TOSCA templates.

Their approach is also based on an Ecore metamodel

generated from the TOSCA XSD. These works con-

sider the modelling of cloud applications, but do not

take the mapping to certain API calls into account.

Ferry et al. (Ferry et al., 2014) deﬁne a models at run-

time approach for the management of cloud applica-

tions. Their approach is based on a modelling lan-

guage called CloudML and is not based on standards.

7 CONCLUSIONS AND

OUTLOOK

In the paper, we presented an approach to combine

TOSCA and OCCI for model and standard driven

cloud orchestration. We deﬁned an initial mapping

between the metamodel elements of TOSCA and

OCCI and explained how we will adopt this map-

ping for a model driven cloud orchestrator based on

https://www.occiware.org/

Model Driven Cloud Orchestration by Combining TOSCA and OCCI

649

the two standards. By adopting a model driven ap-

proach, it becomes easier to incorporate changes to

both evolving standards and to provide a playground

for new concepts. We will continue with the evalua-

tion of the mapping between TOSCA normative types

and OCCI elements. Furthermore, we will use this ap-

proach to support the adaptation of models at runtime

to keep the model of the infrastructure and the appli-

cation deployment consistent with its actual state in

the Cloud. This will also allow us to react to chang-

ing workloads.

ACKNOWLEDGEMENTS

We thank the Simulationswissenschaftliches Zentrum

Clausthal-G

ottingen (SWZ) for ﬁnancial support.

REFERENCES

Bergmayr, A., Breitenb

ucher, U., Kopp, O., Wimmer, M.,

Kappel, G., and Leymann, F. (2016). From Archi-

tecture Modeling to Application Provisioning for the

Cloud by Combining UML and TOSCA. In 6th In-

ternational Conference on Cloud Computing and Ser-

vices Science (CLOSER).

Bergmayr, A., Troya, J., Neubauer, P., Wimmer, M., and

Kappel, G. (2014). UML-based Cloud Application

Modeling with Libraries, Proﬁles, and Templates. In

3rd International Workshop on Model-Driven Engi-

neering on and for the Cloud (CloudMDE), pages 56–

65.

Binz, T., Breitenb

ucher, U., Haupt, F., Kopp, O., Ley-

mann, F., Nowak, A., and Wagner, S. (2013).

OpenTOSCA–a runtime for TOSCA-based cloud ap-

plications. In Service-Oriented Computing, pages

692–695. Springer.

Breitenb

ucher, U., Binz, T., Kepes, K., Kopp, O., Leymann,

F., and Wettinger, J. (2014). Combining Declarative

and Imperative Cloud Application Provisioning Based

on TOSCA. In IC2E, pages 87–96. IEEE Computer

Society.

Ferry, N., Brataas, G., Rossini, A., Chauvel, F., and Sol-

berg, A. (2014). Towards Bridging the Gap Between

Scalability and Elasticity. In 4th International Con-

ference on Cloud Computing and Services Science

(CLOSER), pages 746–751.

Guill

en, J., Miranda, J., Murillo, J. M., and Canal, C.

(2013). A UML Proﬁle for Modeling Multicloud Ap-

plications. In Service-Oriented and Cloud Computing,

pages 180–187. Springer.

Kamali, A., Mohammadi, S., and Barforoush, A. A. (2014).

UCC: UML proﬁle to cloud computing modeling: Us-

ing stereotypes and tag values. In 7th International

Symposium on Telecommunications (IST), pages 689–

694. IEEE.

Loulloudes, N., Sofokleous, C., Trihinas, D., Dikaiakos,

M. D., and Pallis, G. (2015). Enabling Interop-

erable Cloud Application Management through an

Open Source Ecosystem. IEEE Internet Computing,

19(3):54–59.

Lushpenko, M., Ferry, N., Song, H., Chauvel, F., and Sol-

berg, A. (2015). Using adaptation plans to control the

behavior at runtime. In Bencomo, N., G

otz, S., and

Song, H., editors, CEUR Workshop Proceedings, vol-

ume 1474. CEUR.

Merle, P., Barais, O., Parpaillon, J., Plouzeau, N., and Tata,

S. (2015). A Precise Metamodel for Open Cloud

Computing Interface. In 8th IEEE International Con-

ference on Cloud Computing (CLOUD), pages 852–

859. IEEE.

Metsch, T., Edmonds, A., and Par

ak, B. (2016). Open Cloud

Computing Interface - Infrastructure. [Available on-

line: http://ogf.org/documents/GFD.224.pdf].

Nyr

en, R., Edmonds, A., Metsch, T., and Par

ak, B.

(2016a). Open Cloud Computing Interface - HTTP

Protocol. [Available online: http://ogf.org/

documents/GFD.223.pdf].

Nyr

en, R., Edmonds, A., Papaspyrou, A., Metsch, T., and

Par

ak, B. (2016b). Open Cloud Computing Inter-

face - Core. [Available online: http://ogf.org/

documents/GFD.221.pdf].

OASIS (2013). Topology and Orchestration Spec-

iﬁcation for Cloud Applications (TOSCA) 1.0.

[Available online: http://docs.oasis-open.org/

tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html].

OASIS (2016). TOSCA Simple Proﬁle in YAML Version

1.0. [Available online: http://docs.oasis-open.

org/tosca/TOSCA-Simple-Profile-YAML/v1.0/

TOSCA-Simple-Profile-YAML-v1.0.html].

OMG (2014). MDA Guide rev. 2.0. OMG Document

ormsc/2014-06-01 [Available Online: http://www.

omg.org/cgi-bin/doc?ormsc/14-06-01.pdf].

Paraiso, F., Challita, S., Al-Dhuraibi, Y., and Merle, P.

(2016). Model-Driven Management of Docker Con-

tainers. In 9th IEEE International Conference on

Cloud Computing (CLOUD), San Francisco, United

States.

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

650