Combining TOSCA and BPMN to Enable Automated Cloud Service

Provisioning

Domenico Calcaterra, Vincenzo Cartelli, Giuseppe Di Modica and Orazio Tomarchio

Department of Electrical, Electronic and Computer Engineering, University of Catania, Catania, Italy

Keywords:

Cloud Provisioning, Cloud Orchestration, TOSCA, BPMN.

Abstract:

The Cloud computing paradigm has kept its promise to transform computing resources into utilities ready

to be consumed in a dynamic and ﬂexible way, on an “as per need” basis. The next big challenge cloud

providers are facing is the capability of automating the internal operational processes that need to be run in

order to efﬁciently serve the increasing customers’ demand. When a new cloud service request has to be

served, there is a bunch of operations the provider needs to carry out in order to get the requested cloud service

up and ready for usage. This paper investigates the automation of the “provisioning” activities that must be

put into place in order to build up a cloud service. Those activities range from the procurement of computing

resources to the deployment of a web application, passing through the installation and conﬁguration of third

party softwares and libraries that the web application depends upon in order to properly work. Leveraging

on a well-known speciﬁcation used for the representation of a cloud application’s structure (TOSCA), we

designed and implemented an orchestrator capable of automating and putting in force, in the correct timing,

the sequence of tasks building up the cloud application in a step-by-step fashion. The novelty in the followed

approach is represented by the deﬁnition of a converter which takes as input a TOSCA template and produces

a workﬂow that is ready to be executed by a workﬂow engine. The BPMN notation was used to represent both

the workﬂow and the data that enrich the workﬂow. To support the viability of the proposed idea, a use case

was developed and discussed in the paper.

1 INTRODUCTION

In the past ﬁve years the scientiﬁc community has

shown a growing interest around the topic of cloud

provisioning and orchestration (Ranjan et al., 2015;

Bousselmi et al., 2014). The appeal of this topic is

further witnessed by the investments that big cloud

players have been making to develop tools and soft-

wares that support the automation of cloud services’

delivery and maintenance. Also, many commercial

players have been engaged in the deﬁnition of inter-

national standards that would foster the widespread

adoption of technological solutions for the orchestra-

tion of portable (i.e., provider-agnostic) cloud appli-

cations.

In the panorama of standard initiatives, OASIS

TOSCA (Topology and Orchestration Speciﬁcation

for Cloud Applications) (OASIS, 2013) has become

very popular. It is supported by many big cloud play-

ers and promises to cater for the cloud providers’

need of streamlining cloud service orchestration and

provisioning operations. Also, the standardization

body has released a version of the speciﬁcation which

makes use of a very simple and human understand-

able language (YAML) that has contributed to speed-

up the standard adoption process.

The work described in this paper grounds on the

TOSCA speciﬁcation. It leverages the TOSCA fea-

tures to build up a cloud service orchestrator capa-

ble of automating the execution of tasks and opera-

tions required for the provisioning of a cloud appli-

cation. The strategy adopted by the cloud orchestra-

tor is to convert a TOSCA cloud application model

into its equivalent BPMN workﬂow and dataﬂow

model (OMG, 2011). The orchestrator will then use

a BPMN engine to enforce the operations speciﬁed in

the BPMN model. The approach we propose clearly

separates the orchestration of the provisioning tasks

from the real provisioning services (i.e., the e-services

that enforce the provisioning). In this paper, we

present the design of a cloud service provisioning

framework, and discuss the design and implementa-

tion of a cloud orchestrator prototype. Further, we

discuss a real use case of a cloud application provi-

sioning.

The remainder of the paper is organized in the fol-

Calcaterra, D., Cartelli, V., Modica, G. and Tomarchio, O.

Combining TOSCA and BPMN to Enable Automated Cloud Service Provisioning.

DOI: 10.5220/0006304701870196

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

ISBN: 978-989-758-243-1

159

lowing way. In Section 2 a survey of the literature is

proposed. Section 3 provides a bird’s eye view of the

TOSCA speciﬁcation. The core ideas of this work,

along with the design and implementation details of

the cloud orchestrator, are discussed in Section 4. A

real use case showing the potential of the proposed

idea is discussed in Section 5. Section 6 draws some

ﬁnal considerations and suggests some future direc-

tions.

2 RELATED WORK

This section presents a survey of all the recent and au-

thoritative initiatives, both commercial and scientiﬁc,

that address the cloud provisioning and orchestration

topic.

Many cloud industry players have developed

cloud management platforms (Cisco, 2016; Amazon,

2016; Rightscale, 2016; RedHat, 2016; HP, 2016;

IBM, 2016; GigaSpaces, 2016) for automating the

provisioning of cloud services. All platforms, to vary-

ing degrees, promise to provide automation in three

fundamental steps: cloud conﬁguration, cloud provi-

sioning and cloud deployment. The more advanced

platforms also offer services and tools for the manage-

ment of cloud applications’ lifecycle. None of these

commercial products are open to the community, and

the solutions they offer are not portable across third-

party providers either.

The open source world has shown interest on this

topic as well. Taking a look at the category of con-

ﬁguration management tools, DevOps Chef (Chef,

2016) is a software used to streamline the task of

conﬁguring and maintaining server applications and

utilities. It is based on the concept of conﬁguration

“recipes”, which are instructions on the desired state

of resources (software packages to be installed, ser-

vices to be run, or ﬁles to be written). Chef takes

care of those recipes and makes sure that resources

are actually in the desired state. Chef can integrate

with cloud-based platforms such as Amazon EC2,

Google Cloud Platform, OpenStack, Microsoft Azure

and Rackspace to automatically provision and con-

ﬁgure new virtual machines. Similar recipe-based

approaches are proposed by other open-source so-

lutions like Puppet (Puppet, 2016) with its Puppet

manifests and Juju (Juju, 2016) with its Juju charms.

Speaking of cloud orchestration tools, OpenStack

Heat (OpenStack, 2016) is a service to orchestrate

composite cloud applications using a declarative tem-

plate format - namely, the Heat Orchestration Tem-

plate (HOT) - through both an OpenStack-native

REST API and AWS CloudFormation-compatible

API (Amazon, 2016). HOT describes the infrastruc-

ture for a cloud application in text ﬁles which are

readable and writable by humans and by software

tools as well. Also, it integrates well with software

conﬁguration management tools such as Puppet and

Chef. Very recently, orchestration concepts have been

analyzed also in the context of containers (Tosatto

et al., 2015). Even if containers represent a portable

unit of deployment, when an application is built out

of multiple containers the setting up of a cluster of

containers can become actually complex, because it

is needed to make one container aware of another and

expose several details required for them to commu-

nicate. As an example, Docker Compose, currently

under active development, is one of the ﬁrst tools for

deﬁning and running multi-container Docker applica-

tions (Docker, 2017).

With respect to standardizing initiatives, OASIS

is the most active on the topic. TOSCA (OASIS,

2013) is an OASIS open cloud standard supported

by a large and growing number of international in-

dustry leaders. It deﬁnes an interoperable descrip-

tion of applications, including their components, re-

lationships, dependencies, requirements, and capabil-

ities, thus enabling portability and automated man-

agement across multiple cloud providers regardless of

underlying platform or infrastructure. No commer-

cial solution supports processing of the TOSCA spec-

iﬁcation at this moment. OpenTOSCA (Binz et al.,

2013) is a famous open source TOSCA runtime en-

vironment. Although authors have been working on

adding support to the TOSCA Simple Proﬁle (Open-

TOSCA, 2015), only a few YAML elements are sup-

ported by the converter. At this moment, imports, in-

puts, outputs and groups are not supported, thereby

limiting the description of application components.

The reader may ﬁnd some insight on the technical as-

pects of TOSCA in Section 3.

In the scientiﬁc literature a few works have ad-

dressed the TOSCA speciﬁcation. In (Kopp et al.,

2012), BPMN4TOSCA was proposed as a domain-

speciﬁc BPMN (OMG, 2011) extension to ease mod-

eling of management plans by enabling convenient

integration and direct access to TOSCA topology

and provided management operations. Since the

BPMN4TOSCA extension introduces new function-

alities which are not natively supported by workﬂow

engines, it leads to a non-standards-compliant BPMN

and, therefore, needs special treatment, i.e., a trans-

formation to plain BPMN. In (Katsaros et al., 2014),

a proof of concept for the actual portability features of

TOSCA on OpenStack and Opscode Chef has been

presented. To that end, an execution runtime envi-

ronment named TOSCA2Chef was developed to auto-

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

160

mate the deployment of TOSCA-based cloud applica-

tion topologies to OpenStack by employing Chef and

BPEL processes. In (Wettinger et al., 2014), a uniﬁed

invocation bus and interface to be used by TOSCA

management plans has been presented. Based on

OpenTOSCA’s architecture, a service bus (Operation

Invoker) was implemented to provide a uniﬁed in-

vocation interface for TOSCA plans to invoke op-

erations. In (Wettinger et al., 2016), with the goal

of achieving a seamless and interoperable orches-

tration of arbitrary artifacts, an integrated modelling

and runtime framework has been introduced. Af-

ter executable DevOps artifacts of different kinds get

discovered and stored in DevOps knowledge repos-

itories, they are transformed into TOSCA-based de-

scriptions. In (Breitenb

ucher et al., 2015), a process

modelling concept to enable the integration of pro-

visioning models has been introduced. The general

modelling approach is based on extending imperative

workﬂow languages such as BPMN and BPEL (OA-

SIS, 2007) by means of Declarative Provisioning Ac-

tivities, which enable to specify declarative provision-

ing goals directly in the control ﬂow of a workﬂow

model. The data ﬂow between provision activities is

deﬁned through input parameters, output parameters

and content injection. A prototype based on the Open-

TOSCA ecosystem and the BPEL workﬂow language

was implemented.

Several EU funded research projects, such as

ARTIST (Menychtas et al., 2014), SeaClouds (Brogi

et al., 2015), PaaSage (Rossini, 2016), MODAClouds

(Ferry et al., 2017) and PaaSport (Bassiliades et al.,

2017), also addressed cloud application portability in

its essence. Most of these projects, instead of build-

ing a TOSCA engine, transform the TOSCA-based

application speciﬁcation into a single orchestration

script, such as YAML, and execute it by a correspond-

ing management tool, such as CAMP (OASIS, 2014),

Brooklyn (The Apache Software Foundation, 2016),

etc.

The work we propose grounds on the TOSCA

standard as well. A distinctive feature of our approach

is the clear separation between the orchestration of

the provisioning tasks, intended as the scheduling of

the logical steps to be taken, and the provisioning ser-

vices, which are the services implementing the tasks’

instructions. As for the orchestration aspect, we de-

vised a mechanism that automatically builds a plain

BPMN orchestration plan starting from a cloud appli-

cation’s TOSCA model.

3 THE TOSCA SPECIFICATION

TOSCA is the acronym for Topology and Orchestra-

tion Speciﬁcation for Cloud Applications. It is a stan-

dard put together by OASIS that can be used to en-

able the portability of cloud applications and related

IT services. This speciﬁcation permits describing the

structure of a cloud application as a service template,

that is in turn composed of a topology template and

the types needed to build such a template. The topol-

ogy template is a typed directed graph, whose nodes

(called node templates) model the application com-

ponents, and edges (called relationship templates)

model the relations occurring among such compo-

nents. Each node of a topology can also be asso-

ciated with the corresponding component’s require-

ments, the operations to manage it, the capabilities

it features, and the policies applied to it. Inter-node

dependencies associate the requirements of a node

with the capabilities featured by other nodes. TOSCA

supports the deployment and management of applica-

tions in two different ﬂavors: imperative processing

and declarative processing. The imperative process-

ing requires that all needed management logic is con-

tained in the Cloud Service Archive (CSAR), which

stores all software artifacts required to provision, op-

erate, and manage the application. Management plans

imperatively orchestrate low-level management oper-

ations that are either provided by the application com-

ponents themselves or by publicly accessible services

(e.g., the Amazon Web Services API). These plans

are typically implemented using workﬂow languages,

such as BPMN or BPEL (OASIS, 2007). The declar-

ative processing shifts management logic from plans

to runtime, therefore no plans are actually required.

TOSCA runtime engines automatically infer the cor-

responding logic by interpreting the application topol-

ogy template. This requires a precise deﬁnition of

the semantics of nodes and relations based on well-

deﬁned Node Types and Relationship Types. The set

of provided management functionalities depends on

the corresponding runtime and is not standardized by

the TOSCA speciﬁcation.

The TOSCA Simple Proﬁle is a rendering of the

TOSCA speciﬁcation in the YAML language (OASIS,

2015). It aims to provide a more accessible syntax as

well as a more concise and incremental expressive-

ness of the TOSCA language in order to speed up the

adoption of TOSCA to describe cloud applications in

a portable manner. The work described in this paper

heavily grounds on the TOSCA standard and, speciﬁ-

cally, on the TOSCA Simple Proﬁle.

Combining TOSCA and BPMN to Enable Automated Cloud Service Provisioning

161

4 DESIGN OF A CLOUD SERVICE

PROVISIONING FRAMEWORK

This work addresses the design and implementation

of a software framework that aims at easing and au-

tomating the processes that support the operational

management of cloud services. The stakeholders that

may have interest in the services provided through

the framework are the Customers in need of cloud re-

sources and cloud applications (in a nutshell, “cloud

services”) and the Providers of cloud services. To

the former, the framework offers tools to clearly state

functional requirements of the cloud service they are

in need of; from those requirements, the framework

puts in force the actions necessary for the service

delivery to take place. The latter have the chance

to offer their cloud services through the framework,

while playing no active role in the service orchestra-

tion which, instead, is in charge of the framework it-

self.

The focus of this work is put on the automation

of the cloud service provisioning process, i.e., the

process which is entrusted with the procurement and

the set-up of all the resources that build up the cloud

service requested by the Customer. We point out that

the framework has been designed to integrate the sup-

port for more sophisticated operations such as, to cite

a few, resource monitoring, resilience and scaling.

Those speciﬁc operations are though out of the scope

of the current work, and will be part of our future

work’s investigation. As for the service provision, the

objective of this work will be the design and imple-

mentation of an orchestrator which, starting from the

Customer requirements, is capable of generating on

the ﬂy a cloud provisioning process made up of tasks

that build up the ready-to-use service to be delivered.

Speciﬁcally, the orchestrator will be in charge of co-

ordinating the overall process by making sure that ev-

ery task’s activity is carried out in accordance with the

proper timing.

We surveyed the literature in search of a well es-

tablished and broadly accepted way of representing

the cloud application requirements, i.e., a language

or a meta-model the Customer may use to express

the stack of resources (from the virtual machine up

to the top level libraries and softwares) they need in

order to set up their application, and also, the way

those resources need to get conﬁgured and coupled

together in order to ensure that the ﬁnal service de-

livered to the Customer will meet the Customer ex-

pectation. As mentioned before, the approach we

propose grounds on the OASIS TOSCA standard and,

more speciﬁcally, on the TOSCA Simple Proﬁle ren-

dering. The choice of TOSCA was driven by the fact

that TOSCA is a mature standard which embeds all

the features which we deem useful to our purpose.

In particular, the TOSCA Simple Proﬁle provides a

meta-model written in YAML (a human friendly data

serialization standard) which the Customer may use

to deﬁne their cloud application model, i.e., to de-

scribe both the application topology and the artifacts

needed by the application itself. Since the objective

we pursue is to automate the application provisioning,

we opted for a workﬂow-based solution which, start-

ing from the cloud application model description, is

capable of devising and orchestrating the ﬂow of the

provisioning operations to execute. Instead of devel-

oping a workﬂow engine from scratch, we decided to

make use of a BPMN engine, i.e., an engine capa-

ble of executing workﬂows represented in the BPMN

language. Since a YAML application model is not

executable by a BPMN engine, we developed an ad-

hoc YAML-to-BPMN converter. The reader may dis-

cover the details of the converter in Section 4.1. We

opted on the BPMN as workﬂow language since it is

a robust standard and it also provides support for data

modelling, a feature that we exploited to represent the

application artifacts needed along the workﬂow.

A novelty introduced by this approach is the sep-

aration between the orchestration of the provisioning

tasks and the provisioning services themselves. We

propose a solution where the provisioning services

may be supplied by third party service providers,

while the provisioning tasks orchestrated by the work-

ﬂow engine will draw on those services in a SOA

(Service Oriented Architecture) fashion. This enables

a scenario of a market of services in which many

providers are allowed to participate and where Cus-

tomers can get the best combination of services that

meet their requirements. The overall scenario de-

scribed so far is best depicted in Figure 1.

Cloud Orchestrator

BPMN Engine

Create VM

Service #1

Create VM

Service #2

Deploy DB

Service #1

Deploy App Container

Service #1

BPMN

Service BUS

YAML-TO-BPMN

YAML

Figure 1: Cloud Orchestrator scenario.

We have designed and implemented a TOSCA

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

162

Orchestrator which takes as input the application

model and deploys the concrete application in the

cloud. The Orchestrator takes the YAML model and

transforms it into an equivalent BPMN model. The

BPMN model, in its turn, is fed to a BPMN engine

that will instantiate and coordinate the relative pro-

cess. The process will put in force all the provision-

ing activities needed to build up the application stack

(e.g., getting a virtual machine from a cloud provider,

installing all the required libraries and third party soft-

wares on it, conﬁguring the software dependencies,

and so on); as the reader may notice, the provision-

ing activities access a service bus in order to get the

required services which, in their turn, are supplied by

third party service providers. Finally, once the cloud

application is up and running, the Customer is invited

to take the control.

The framework we propose aims to offer tools and

services that enable the scenario depicted in Figure

1. To date, only a subset of those services has been

implemented. Speciﬁcally, the implementation of the

service bus and the invocation of the provisioning ser-

vices will be addressed in future work. Customers

can use the YAML representation to express applica-

tion requirements and push those requirements to the

framework. Providers can design their services ac-

cording to speciﬁc templates and offer them to Cus-

tomers through the framework. The framework is en-

trusted with orchestrating the provisioning activities

and matching the services’ offer and demand. In the

current implementation, the framework cares just for

functional requirements, i.e., it provides matches be-

tween what the Customer needs in terms of functional

needs (gets a given virtual machine, installs a speciﬁc

database, etc.). Non-functional requirements, which

call for enhanced service matchmaking mechanisms,

are out of the scope of this work and will be addressed

in future work.

4.1 Converting YAML to BPMN

This section discusses the features and the techni-

cal details of the software component we devised

to convert a TOSCA Simple Proﬁle into its equiva-

lent BPMN process model. Starting from a TOSCA

Simple Proﬁle compliant service template, our soft-

ware creates a Provisioning Plan which is fed into

the workﬂow engine for the automated application de-

ployment. This approach brings considerable bene-

ﬁts, among which a) reusability of the process logic,

since components of the same type use the same logic;

b) portability of the Plan, as the application can be

deployed on a generic Cloud Provider; c) efﬁciency

in terms of streamlining Customer’s work, because

they only have to deﬁne their templates and ﬁll them

with the management functions of their choice, with-

out caring about how Provisioning Plans will be cre-

ated and executed on the Cloud Provider.

The proposed solution consists of three com-

ponents: TOSCA-Parser, BPMN-Generator, and

BPMN-Validator. The TOSCA-Parser deals with the

service template by providing means to load, parse

and validate the YAML ﬁle, and creates the depen-

dency graph, a data structure containing the rela-

tionships between all of the nodes in the TOSCA

template. Vertices in the graph represent Nodes,

while edges represent relationships occurring be-

tween them. The BPMN-Generator grounds the cre-

ation of the Provisioning Plan on the parsed service

template and the dependency graph. The BPMN-

Validator validates the automatically generated Plan

against the BPMN speciﬁcation. The following Sec-

tions will provide more details about these compo-

nents.

4.1.1 TOSCA-Parser

The TOSCA Parser takes a TOSCA YAML template

as input, with an optional dictionary of needed pa-

rameters with their values, validates it, and produces

in-memory objects of different TOSCA elements with

their relationship to each other. It also creates an in-

memory graph of TOSCA node templates and their

relationships. This software component is widely

based on the OpenStack parser for TOSCA Simple

Proﬁle in YAML (OpenStack, 2016), a Python project

licensed under Apache 2.0. In agreement with the

overall structure of a service template, the parser con-

tains various Python modules to handle it including

topology templates, node templates, relationship tem-

plates, data types, node types, relationship types, ca-

pability types, artifact types, etc. The ToscaTemplate

class is an entry class of the parser and is of great

importance, along with TopologyTemplate, NodeTem-

plate and RelationshipTemplate, in the construction

of the ToscaGraph, which keeps track of all nodes

and dependency relationships between them in the

TOSCA template. This in-memory graph is, in its

turn, a milestone in the generation of the BPMN Pro-

visioning Plan, and the entire process is covered in

Section 4.1.2.

4.1.2 BPMN-Generator

The BPMN-Generator takes the aforementioned

ToscaGraph and ToscaTemplate elements (e.g., In-

puts, Outputs, NodeTemplates, RelationshipTem-

plates) as input and automatically generates the

BPMN Provisioning Plan for the designated Cloud

Combining TOSCA and BPMN to Enable Automated Cloud Service Provisioning

163

application. For clarity purposes, the service template

shown in Listing 1 will be taken as an example to

show what needs to be done to reach the goal. The

BPMN generation is composed of the following two

steps: (1) the creation of a Workﬂow modelling a de-

tailed sequence of business activities to perform; (2)

the creation of a Dataﬂow modelling the data to be

read, written or updated during the Workﬂow execu-

tion.

t o s c a d e f i n i t i o n s v e r s i o n : t o s c a s i m p l e y a m l 1 0

d e s c r i p t i o n : >

TOSCA s i m pl e p r o f i l e w i t h a s o f t w a r e c omp one nt .

t o p o l o g y t e m p l a t e :

i n p u t s :

cpus:

t y p e : i n t e g e r

d e s c r i p t i o n : Number o f CPUs f o r t h e s e r v e r .

c o n s t r a i n t s :

- v a l i d

v a l u e s : [ 1 , 2 , 4 , 8 ]

d e f a u l t : 1

n o d e t e m p l a t e s :

sw:

t y p e : t o s c a . n o d e s . Soft w a r eCom p o n ent

p r o p e r t i e s :

c o m p o n e n t v e rs i o n: 1 . 0

r e q u i r e m e n t s :

- h o s t : s e r v e r

i n t e r f a c e s :

S t an d a r d :

c r e a t e : s o f t w a r e i n s t a l l . s h

s t a r t : s o f t w a r e s t a r t . sh

s e r v e r :

t y p e : t o s c a . n o d e s . Compute

c a p a b i l i t i e s :

h o s t :

p r o p e r t i e s :

d i s k s i z e : 10 GB

num c pus : { g e t i n p u t : c p u s }

mem size : 1024 MB

os:

p r o p e r t i e s :

a r c h i t e c t u r e : x 86 6 4

t y p e : L i nux

d i s t r i b u t i o n : U bu ntu

v e r s i o n : 1 4 .04

Listing 1: SW Component - Service Template.

The Workﬂow basically comprises a BPMN pro-

cess made of Service Tasks, Sequence Flows and

Gateways used to control how the process ﬂows,

with every single component being derived from

all the node templates and their requirements in the

YAML Service Template. In particular, taking inspi-

ration from normative node states and lifecycle oper-

ations of the Standard interface (OASIS, 2013), each

node template in the YAML scenario leads to a new

Service Task for every operation speciﬁed on that

node. Such Service Tasks are related to each other

by means of Sequence Flows and possible Gateways,

whose creation depends on Service Tasks dependen-

cies, which, in their turn, depend on node templates

requirements. The ToscaGraph is the reference point

to determine such requirements. In this regard, the

graph is traversed and for each node, represented by

a vertex, the whole set of requirements is constructed

in terms of relationships with other nodes, represented

by related edges. Service Tasks dependencies are then

obtained by taking into account the node requirements

and the lifecycle operations they represent. Starting

from such dependencies, it is possible to compute the

execution order of all Service Tasks in the Provision-

ing Plan, i.e., the deployment order of all Cloud appli-

cation components. This information is represented

by numerical data: the lower the number is, the less

priority that Service Task gets. Service Tasks with

the lowest execution order, hereby collectively called

Service Tasks Endpoint, don’t feature in between any

Service Task’s required dependencies, whereas Ser-

vice Tasks with the highest execution order, hereby

collectively called Service Tasks Startpoint, don’t fea-

ture any Service Task as a required dependency. With

reference to our example scenario, the resulting data

structures are shown in Listing 2.

se r v i ce _t as ks = [ ’ ser ve r ’ , ’ sw _c re at e ’ , ’ sw _c o n f ig ur e ’ ,

’ sw _s ta rt ’ ]

s e r vi ce _t a sk s_ re q ui re me n ts = { ’ sw _c re at e ’: [ ’ ser ve r ’] ,

’ sw _c on f i g ur e ’: [ ’ sw _c re at e ’] ,

’ sw _s ta rt ’ : [ ’ sw _c o n f ig ur e ’ ]}

se r vi ce _t as k s_ or de r = { ’ se rv er ’ : 4 , ’ s w_ cr ea t e ’ : 3 ,

’ sw _c on f i g ur e ’: 2 , ’ sw _s ta rt ’: 1 }

se r vi ce _t a sk s_ st a rt po in t = [ ’ se rv er ’ ]

se r vi ce _t a sk s_ en d p o in t = [ ’ sw _s ta rt ’ ]

Listing 2: SW Component - Tasks, Requirements, Order.

Figure 2: Output of the BPMN generator - Workﬂow.

Figure 3: Output of the BPMN generator - Workﬂow and

Dataﬂow.

Service Tasks Endpoint and Startpoint are of

paramount importance to deﬁne a proper execution

ﬂow, because they may lead to some degree of par-

allelism in the Workﬂow through Parallel Gateways,

which are used to synchronize or create parallel ﬂows.

Speciﬁcally, they play a role in the creation of Start

Event, End Event and Service Tasks. Service Tasks

and related Sequence Flows are created by proceed-

ing in ascending Service Tasks priority fashion (i.e.,

in their reverse execution order). From lowest to high-

est priority, each Service Task is created and then their

incoming and outgoing paths are determined by dis-

tinguishing three further cases: a) the Service Task

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

164

HostedOn

HostedOn HostedOn

HostedOn

ConnectsTo

wordpress

WebApplication

Properties

• context_root

Requirements

Endpoint.Database

Container

PHPModule

mysql_database

Database

Properties

• name

• user

• password

• port

Requirements

Container

Capabilities

Endpoint.Database

php

SoftwareComponent

Capabilities

PHPModule

Requirements

Container

apache

WebServer

Properties

• port

• document_root

Capabilities

Container

Requirements

Container

mysql_dbms

DBMS

Properties

• port

• root_password

Capabilities

Container

Requirements

Container

app_server

Compute

Capabilities

Container

Properties

• disk_size

• num_cpus

• mem_size

• cpu_frequency

OperatingSystem

Properties

• architecture

• type

• distribution

• version

mysql_server

Compute

Capabilities

Container

Properties

• disk_size

• num_cpus

• mem_size

• cpu_frequency

OperatingSystem

Properties

• architecture

• type

• distribution

• version

Figure 4: Wordpress Deploy - TOSCA Template.

belongs to Service Tasks Endpoint set, b) the Service

Task belongs to Service Tasks Startpoint set, c) the

Service Task belongs to neither of them. As to our

example scenario, the resulting BPMN Workﬂow is

shown in Figure 2.

The Dataﬂow simply consists of Data Inputs, Data

Outputs and Data Objects, which are derived from

node templates and their data requirements in the

YAML Service Template. Speaking of data require-

ments, the TOSCA standard allows template authors

to customize Service Templates through the inputs

section in the Topology Template, which represents

an optional list of input parameters for the Topology

Template. In a complementary way, the outputs sec-

tion represents an optional list of output parameters

for the Topology Template. Inputs and outputs can

be used to parameterize node

templates properties or

node templates and relationship templates lifecycle

operations. Data Inputs, which capture input data that

Activities and Processes often need in order to exe-

cute, are utilized to model such inputs; Data Outputs,

which capture data that they can produce during or

as a result of execution, are utilized to model such

outputs. It should be noted that node templates at-

tributes can be used as parameters in the lifecycle op-

erations as well. Data Objects are utilized to model

this kind of data requirements, with Data Associations

determining how information stored in Data Objects

is handled and passed between Process ﬂow elements.

With reference to our sample template in Listing 1,

there is only one input variable speciﬁed in the server

num cpus property. This leads to a Data Input and

a Data Association between the Start Event and the

server Service Task, as depicted in Figure 3.

Combining TOSCA and BPMN to Enable Automated Cloud Service Provisioning

165

Figure 5: Wordpress Deploy - Workﬂow.

4.1.3 BPMN-Validator

The BPMN-Validator validates the BPMN Plan gen-

erated in the previous step against the BPMN XML

Schema (OMG, 2011), with both of them being taken

as input parameters. The validation is performed by

means of etree module in Python lxml package (lxml,

2016). More speciﬁcally, the BPMN XML Schema

gets parsed and turned into an XML Schema valida-

tor, which checks if the previously parsed BPMN plan

complies with the provided schema. If that is not the

case, then a validation error is going to be raised.

5 USE CASE

The Application modelling use case taken into con-

sideration aims to deploy a WordPress web applica-

tion on an Apache web server, with a MySQL DBMS

hosting the database content of the application on a

separate server. Figure 4 shows the overall architec-

ture compliant with the TOSCA Simple Proﬁle spec-

iﬁcation (although wordpress, php and apache node

types are non-normative). There are two separate

servers: app server for the web server hosting and

mysql server for the DBMS hosting. Both servers

are conﬁgurable on hardware side (e.g., disk size,

number of cpus, memory size and CPU frequency)

and software side (e.g., OS architecture, OS type, OS

distribution and OS version). The apache node fea-

tures port and document root properties, and is de-

pendent upon the app server via a HostedOn rela-

tionship as well. In the same way, the php node

is dependent upon the app server via a HostedOn

relationship. The mysql dbms node features port

and root password properties, and a HostedOn de-

pendency relationship upon the mysql server. The

mysql database node features name, username, pass-

word and port properties, and a HostedOn depen-

dency relationship upon the mysql dbms. Finally,

the wordpress node features the context root property,

and depends on mysql database and php by means

of two ConnectsTo relationships and on apache by

means of a HostedOn relationship, respectively.

a p a c h e :

t y p e : t o s c a . n o d e s . We bServ er . Apache

p r o p e r t i e s :

p o r t : { g e t i n p u t : a p a c h e p o r t }

d o c um e n t r oo t : { g e t i n p u t : a p a c h e d o c r o o t }

r e q u i r e m e n t s :

- h o s t : a p p s e r v e r

i n t e r f a c e s :

S t an d a r d :

c r e a t e :

i n p u t s :

i p : { g e t a t t r i b u t e : [ a p p s e r v e r , p r i v a t e a d d r e s s ] }

p o r t : { g e t p r o p e r t y : [ SELF , p o r t ] }

d o c r o o t : { g e t p r o p e r t y : [ SELF , d oc u m e n t r o o t ]}

i m p l e m e n ta t io n : s c r i p t s / i n s t a l l a p a c h e . sh

s t a r t :

i n p u t s :

i p : { g e t a t t r i b u t e : [ a p p s e r v e r , p r i v a t e a d d r e s s ] }

i m p l e m e n ta t io n : s c r i p t s / s t a r t a p a c h e . sh

Listing 3: Wordpress Deploy - Apache node.

For the sake of clarity, Listing 3 shows the apache

node declaration in YAML. As mentioned above, the

node takes the app server as requirement and has port

and document root properties, whose values are re-

trieved from apache port and apache doc root input

parameters, respectively, by means of the get input

intrinsic function. Two lifecycle operations are

also deﬁned (i.e., create and start), with both of

them taking ip as input parameter, whose value is

retrieved from the private address attribute of the

app server through the get attribute intrinsic func-

tion. In conformity with Section 4.1.2, the node

transformation from YAML to BPMN leads to the

creation of: (1) three Service Tasks (apache create,

apache conﬁgure and apache start); (2) two Data In-

puts (doc root and port) with their respective Data

Input Associations in apache create; (3) one Data

Object (app server.private address) with its Data In-

put Associations in apache create and apache start.

Figure 5 and Figure 6 show the overall Workﬂow

and Dataﬂow-decorated Workﬂow, respectively. The

workﬂow represented in Figure 6 is then fed to a

BPMN engine that will actually enforce the work-

ﬂow’s tasks.

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

166

Figure 6: Wordpress Deploy - Workﬂow and data ﬂow.

6 CONCLUSION

The challenge of automating the operational manage-

ment and orchestration of cloud services has attracted

many cloud industry players. The open source world

too is very active in this topic. Very recently an open

standard for the representation of the cloud applica-

tion structure (TOSCA) has boosted the interest in

the research environment and has fostered the ﬂour-

ishing of many more cloud automation products even

from small cloud players. This work leverages on the

TOSCA potential to propose the deﬁnition of a cloud

orchestration and provisioning framework that auto-

mates the cloud service deployment operations. Ba-

sically, the automation is carried out by a two-step

process: 1) transforming a TOSCA cloud application

model into a BPMN workﬂow; 2) getting the work-

ﬂow executed on a workﬂow engine. The novelty of

the approach also consists in the deﬁnition of a data

model that enriches the workﬂow. In the future, the

framework will be enhanced with an ecosystem of

services that can be invoked by the workﬂow engine

and that will actually carry out the deployment tasks.

REFERENCES

Amazon (2016). Amazon CloudFormation.

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

accessed on 15-02-2017.

Bassiliades, N., Symeonidis, M., Meditskos, G., Kontopou-

los, E., Gouvas, P., and Vlahavas, I. (2017). A se-

mantic recommendation algorithm for the paasport

platform-as-a-service marketplace. Expert Systems

with Applications, 67:203 – 227.

Binz, T., Breitenb

ucher, U., Haupt, F., Kopp, O., Leymann,

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

– A Runtime for TOSCA-Based Cloud Applications,

pages 692–695. Springer Berlin Heidelberg, Berlin,

Heidelberg.

Bousselmi, K., Brahmi, Z., and Gammoudi, M. M. (2014).

Cloud services orchestration: A comparative study of

existing approaches. In IEEE 28th International Con-

Combining TOSCA and BPMN to Enable Automated Cloud Service Provisioning

167

ference on Advanced Information Networking and Ap-

plications Workshops, (WAINA 2014), pages 410–416.

Breitenb

ucher, U., Binz, T., Kopp, O., Leymann, F., and

Wettinger, J. (2015). A modelling concept to integrate

declarative and imperative cloud application provi-

sioning technologies. In Proceedings of the 5th In-

ternational Conference on Cloud Computing and Ser-

vices Science, pages 487–496.

Brogi, A., Carrasco, J., Cubo, J., Nitto, E. D., Dur

an, F.,

Fazzolari, M., Ibrahim, A., Pimentel, E., Soldani, J.,

Wang, P., and D’Andria, F. (2015). Adaptive man-

agement of applications across multiple clouds: The

seaclouds approach. CLEI Electron. J., 18(1).

Chef (2016). Devops Chef.

https://www.chef.io/solutions/devops/. Last ac-

cessed on 15-02-2017.

Cisco (2016). Cisco Intelligent Automation for Cloud

(IAC). http://www.cisco.com/c/en/us/products/cloud-

systems-management/intelligent-automation-

cloud/index.html. Last accessed on 15-02-2017.

Docker (2017). Docker Compose.

https://docs.docker.com/compose/. Last accessed on

15-02-2017.

Ferry, N., Almeida, M., and Solberg, A. (2017). The

MODAClouds Model-Driven Development, pages 23–

33. Springer International Publishing, Cham.

GigaSpaces (2016). Cloudify. http://getcloudify.org/. Last

accessed on 15-02-2017.

HP (2016). HP Cloud Service Automation.

http://www8.hp.com/it/it/software-solutions/cloud-

service-automation/. Last accessed on 15-02-2017.

IBM (2016). IBM Cloud Orchestrator. http://www-

03.ibm.com/software/products/it/ibm-cloud-

orchestrator. Last accessed on 15-02-2017.

Juju (2016). Juju charms. https://jujucharms.com/. Last

accessed on 15-02-2017.

Katsaros, G., Menzel, M., Lenk, A., Revelant, J. R., Skipp,

R., and Eberhardt, J. (2014). Cloud application porta-

bility with tosca, chef and openstack. In Proceedings

of the 2014 IEEE International Conference on Cloud

Engineering, IC2E ’14, pages 295–302, Washington,

DC, USA. IEEE Computer Society.

Kopp, O., Binz, T., Breitenb

ucher, U., and Leymann, F.

(2012). BPMN4TOSCA: A Domain-Speciﬁc Lan-

guage to Model Management Plans for Composite Ap-

plications, pages 38–52. Springer Berlin Heidelberg,

Berlin, Heidelberg.

lxml (2016). lxml project. http://lxml.de/. Last accessed on

15-02-2017.

Menychtas, A., Konstanteli, K., Alonso, J., Orue-

Echevarria, L., Gorro

nogoitia, J., Kousiouris, G.,

Santzaridou, C., Bruneli

ere, H., Pellens, B., Stuer, P.,

Strauß, O., Senkova, T., and Varvarigou, T. A. (2014).

Software modernization and cloudiﬁcation using the

artist migration methodology and framework. Scal-

able Computing: Practice and Experience, 15(2).

OASIS (2007). Web Services Business Process Exe-

cution Language Version 2.0. https://www.oasis-

open.org/committees/download.php/23964/wsbpel-

v2.0-primer.htm. Last accessed on 15-02-2017.

OASIS (2013). Topology and Orchestration Speciﬁcation

for Cloud Applications Version 1.0. http://docs.oasis-

open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-

os.html. Last accessed on 15-02-2017.

OASIS (2014). Cloud Application Management

for Platforms Version 1.1. http://docs.oasis-

open.org/camp/camp-spec/v1.1/camp-spec-

v1.1.html. Last accessed on 15-02-2017.

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

1.0. http://docs.oasis-open.org/tosca/TOSCA-Simple-

Proﬁle-YAML/v1.0/csprd01/TOSCA-Simple-Proﬁle-

YAML-v1.0-csprd01.html. Last accessed on

15-02-2017.

OMG (2011). Business Process Model and Notation

(BPMN 2.0). http://www.omg.org/spec/BPMN/2.0/.

Last accessed on 15-02-2017.

OpenStack (2016). OpenStack Heat.

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

on 15-02-2017.

OpenStack (2016). OpenStack project.

https://github.com/openstack/tosca-parser. Last

accessed on 15-02-2017.

OpenTOSCA (2015). OpenTOSCA project.

https://github.com/CloudCycle2/YAML Transformer.

Last accessed on 15-02-2017.

Puppet (2016). Puppet. https://puppet.com/. Last accessed

on 15-02-2017.

Ranjan, R., Benatallah, B., Dustdar, S., and Papazoglou,

M. P. (2015). Cloud Resource Orchestration Program-

ming: Overview, Issues, and Directions. IEEE Inter-

net Computing, 19:46–56.

RedHat (2016). RedHat CloudForms.

https://www.redhat.com/it/technologies/

management/cloudforms. Last accessed on 15-02-

2017.

Rightscale (2016). Rightscale Cloud Management

Platform. http://www.rightscale.com/why-cloud-

management-platform/beneﬁts. Last accessed on 15-

02-2017.

Rossini, A. (2016). Cloud Application Modelling and Ex-

ecution Language (CAMEL) and the PaaSage Work-

ﬂow, pages 437–439. Springer International Publish-

ing, Cham.

The Apache Software Foundation (2016). The Apache

Brooklyn project. https://brooklyn.apache.org/. Last

accessed on 15-02-2017.

Tosatto, A., Ruiu, P., and Attanasio, A. (2015). Container-

Based Orchestration in Cloud: State of the Art and

Challenges. In 9th International Conference on Com-

plex, Intelligent, and Software Intensive Systems, (CI-

SIS 2015), pages 70–75.

Wettinger, J., Binz, T., Breitenb

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

mann, F., and Zimmermann, M. (2014). Uniﬁed invo-

cation of scripts and services for provisioning, deploy-

ment, and management of cloud applications based on

tosca. In Proceedings of the 4th International Confer-

ence on Cloud Computing and Services Science, pages

559–568.

Wettinger, J., Breitenb

ucher, U., Kopp, O., and Ley-

mann, F. (2016). Streamlining DevOps automation

for Cloud applications using TOSCA as standardized

metamodel . Future Generation Computer Systems,

56:317 – 332.

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

168