Automated Generation of Application Management

Workﬂows using TOSCA Policies

Domenico Calcaterra and Orazio Tomarchio

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

Keywords:

Automated Management, Cloud Application Management, Policies, TOSCA, BPMN.

Abstract:

Cloud orchestration frameworks are recognised as a key driver to tackle the complexity of deploying and man-

aging cloud resources and services. Although automated orchestration approaches have been widely adopted

in industry and academia, most of them only provide limited management capabilities, such as monitoring

or scaling individual components. Holistic management features concerning multiple application components

are mostly not covered by existing solutions. Supporting such features typically involves a custom implemen-

tation of management logic, which can be error-prone, time-consuming and frequently outdated. In this work,

we present an approach for the automated generation of holistic management workﬂows based on TOSCA

application models, reusable node types and policy types. A prototype implementation and a case study are

also discussed to prove the feasibility of the proposed idea.

1 INTRODUCTION

As a result of several beneﬁts in terms of avail-

ability, scalability, costs and time savings (Marston

et al., 2011), cloud computing adoption has expanded

rapidly over the past decade, leading to a larger dis-

tribution of resources and services across the inter-

net (Dikaiakos et al., 2009). COVID-19 has further

accelerated the migration to cloud computing, caus-

ing cloud adoption to increase at an even greater rate.

According to Flexera 2021 State of the Cloud Re-

port (Flexera, 2021), many organisations have suc-

cessfully adopted cloud computing worldwide.

A key point to optimise resource usage and fully

exploit the potential of cloud computing is cloud or-

chestration (Ranjan et al., 2015; Weerasiri et al.,

2017). Due to the proliferation of heterogeneous

providers, cloud orchestration is considered to be

challenging, error-prone and time-consuming (Ca-

baller et al., 2018). Manual solutions to orchestra-

tion are discouraged because they require a familiarity

with different cloud provider platforms, services and

low-level APIs. Most commercial cloud providers

offer automated orchestration platforms to end-users

(Bousselmi et al., 2014): however, these products

are proprietary and not portable. Cloud-agnostic ap-

proaches to automation are also provided by tools

https://orcid.org/0000-0003-4653-0480

falling under the realm of DevOps (Leite et al., 2019),

Infrastructure as Code (IaC) (Morris, 2016) and Con-

ﬁguration Management (CM) (Delaet et al., 2010).

By contrast, these approaches only have limited

automated management, such as monitoring or scal-

ing individual components (Toffetti et al., 2017),

whereas holistic application management involving

components distributed over multiple environments is

not automatically supported for the most part. Holis-

tic application management includes features such

as performing backups of stateful components, test-

ing the availability of application components, etc.

However, the support for such features requires cus-

tom implementations which can be error-prone, time-

consuming and frequently outdated.

In this paper we propose an approach to auto-

matically generate holistic management workﬂows

from TOSCA application models, which are transpar-

ently enriched with component-speciﬁc management

features by means of an appropriate combination of

reusable TOSCA node types and policy types. As a

consequence of such enrichment process, application

architects are not required to provide manual imple-

mentation of management functionalities, leading up

to reduced efforts and more error resilience.

The remainder of the paper is structured as fol-

lows. Section 2 provides a background of the con-

cepts used in this work and motivates the need for

holistic management automation. Section 3 delves

Calcaterra, D. and Tomarchio, O.

Automated Generation of Application Management Workﬂows using TOSCA Policies.

DOI: 10.5220/0011096200003200

In Proceedings of the 12th International Conference on Cloud Computing and Services Science (CLOSER 2022), pages 97-108

ISBN: 978-989-758-570-8; ISSN: 2184-5042

into the proposed approach to automatically generate

management workﬂows from TOSCA-based applica-

tion models. Section 4 discusses a prototype imple-

mentation and a case-study showing the potential of

the proposed idea. Related work is discussed in Sec-

tion 5. Concluding remarks and future directions are

debated in Section 6.

2 BACKGROUND AND

MOTIVATION

In this section, we ﬁrst outline basic principles for de-

ployment and management automation and then pro-

vide a brief overview on the TOSCA speciﬁcation. Fi-

nally, a motivation scenario for holistic management

automation is introduced.

2.1 Deployment and Management

Automation

Over the past few years, quite a few orchestration and

management frameworks have emerged from both in-

dustry and academia (Tomarchio et al., 2020). Most

cloud industry players have developed Cloud Man-

agement Platforms (CMP) to automate cloud service

provisioning. The most advanced platforms also offer

lifecycle management of cloud applications. These

commercial products are typically neither open to the

community nor portable across third-party providers.

There are a number of tool categories which share

similarities with cloud orchestrators. Conﬁguration

management tools, such as Ansible, Chef, Puppet and

Salt, mostly automate the development, delivery, test-

ing and maintenance throughout the software lifecy-

cle. These tools have recently moved towards orches-

tration, which leverage Infrastructure as Code (IaC) to

change, conﬁgure and automate infrastructure. Ter-

raform is one of the most notable IaC open-source

solutions. These technologies use either declarative

or imperative models to automate application deploy-

ment. While declarative models describe the desired

application state from which the deployment tasks are

automatically derived, imperative models specify the

deployment tasks and their execution order.

Although declarative models are highly intuitive

and reusable, they suffer from a few limitations. On

the one hand, deployment systems can directly infer

all tasks to be executed from the models, but on the

other hand they can neither customise tasks nor al-

ter their execution order. Imperative models are then

necessary when it comes to modelling complex ap-

plication deployments with customised tasks. Work-

ﬂows languages, such as BPMN (OMG, 2011) and

BPEL (OASIS, 2007), are typical examples of imper-

ative technologies. However, imperative models re-

quire technical expertise and are frequently outdated

as compared to declarative models.

While the available technologies support auto-

mated deployments over multiple environments, they

only provide limited support for automated manage-

ment (Toffetti et al., 2017). As far as cloud providers

are concerned, they usually only offer management

features for the hosted components, with the result

that single management features need to be orches-

trated when multiple providers are involved. Holistic

management of multiple components located in dif-

ferent environments is mostly unsupported as well.

Typical holistic management features include but are

not limited to component backup, testing, update, etc.

Even in that case, automating holistic management re-

quires single management features to be orchestrated

(by a workﬂow, for instance).

2.2 The TOSCA Speciﬁcation

High-level speciﬁcation languages to describe the

topology of cloud services facilitate the orchestra-

tion process and foster interoperability across differ-

ent providers. TOSCA (OASIS, 2013) represents a

notable contribution to the development of cloud stan-

dards, since it allows to describe multi-tier applica-

tions and their lifecycle management in a modular and

portable fashion (Bellendorf and Mann, 2018).

According to TOSCA, the structure of a cloud ap-

plication is described as a service template, which

consists of a topology template and the types needed

to build such a template. The topology template is a

typed directed graph, whose nodes (called node tem-

plates) model the application components, and edges

(called relationship templates) model the relations oc-

curring among such components. Each topology node

can also be associated with the corresponding capa-

bilities and requirements, the interfaces to manage it,

the attributes and properties it features, the software

artifacts it uses and the policies applied to it.

TOSCA supports the deployment and manage-

ment of applications in two different ﬂavours: imper-

ative processing and declarative processing. The im-

perative processing requires that management logic

is contained in the Cloud Service Archive (CSAR),

which stores all software artifacts needed to provi-

sion and manage the application. Management plans

imperatively orchestrate low-level management op-

erations that are provided either by the application

components themselves or by publicly accessible ser-

vices. Management plans are typically implemented

CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science

using workﬂow languages (e.g., BPMN, BPEL). The

declarative processing shifts management logic from

plans to runtime. TOSCA runtimes automatically in-

fer the corresponding logic by interpreting the appli-

cation topology template. Management functionali-

ties depend on the corresponding runtime, which is

not standardised by the TOSCA speciﬁcation.

TOSCA Simple Proﬁle (OASIS, 2020) is an iso-

morphic rendering of a subset of the TOSCA speciﬁ-

cation in the YAML language. It provides a more con-

cise and accessible syntax to describe portable cloud

applications. TOSCA Simple Proﬁle deﬁnes a few

normative workﬂows that are used to operate a topol-

ogy and speciﬁes how they are declaratively gener-

ated. Imperative workﬂows can be used for complex

use cases that cannot be solved in declarative work-

ﬂows. However, they provide less reusability as they

are deﬁned for a speciﬁc topology rather than being

dynamically generated based on the topology content.

The work described in this paper heavily grounds on

the TOSCA Simple Proﬁle.

2.3 Motivation

As mentioned in Section 2.1, while the available ap-

proaches provide automated deployment over mul-

tiple environments, they only support limited au-

tomated management which requires orchestration

when multiple cloud providers, services and compo-

nents are involved. Besides, automated holistic man-

agement is mostly unsupported and, when it is sup-

ported, custom implementations are often required.

Figure 1 illustrates a declarative application model

describing a typical cloud application scenario based

on TOSCA. In order to have a proper application de-

ployment, it is crucial to check if it is successful from

both a technical and business perspective. This is

where testing becomes relevant. In case of multi-

cloud applications, it might be necessary for appli-

cation components to communicate with each other.

For instance, depending on the testing, SSH connec-

tions (e.g. Compute nodes), HTTP connections (e.g.

WordPress and Apache nodes) or even SQL connec-

tions (e.g. DBMS and Database nodes) might need

to be established. Since huge expertise is required to

implement testing, the automated generation of tests

is important to ensure that all components and com-

munication among them work as expected. In case

of a web application, it is also important to copy cur-

rent data on a regular basis. In order to back up the

Database in our scenario, it is required to either use

the backup feature of the underlying DBMS or estab-

lish a direct connection to the database and execute a

query to retrieve all data. However, additional tech-

nology and domain-speciﬁc logic need to be orches-

trated and executed in the correct order.

In general terms, even automating the manage-

ment of simple applications can be a major chal-

lenge when management features must be imple-

mented manually, since manual implementations re-

quire massive domain-speciﬁc expertise and are error-

prone, time consuming and frequently outdated. In

this work we propose an approach for the automatic

generation of holistic management workﬂows based

on TOSCA application models and policies.

3 POLICY-BASED APPLICATION

MANAGEMENT

In this section, we delve into the proposed method-

ology to automatically generate management work-

ﬂows from TOSCA-based application models. First,

we provide a bird’s-eye view of the approach; then,

we analyse the main steps of the entire process.

3.1 High-level Approach

In order to automatically generate executable man-

agement workﬂows from TOSCA application models,

we propose the approach depicted in Figure 2.

The overall process is composed of three distinct

sequential phases. The process begins with the Ap-

plication Speciﬁcation phase, where the application

architect is in charge of modelling and submitting a

TOSCA application model which is speciﬁed based

on interface types, node types and policy types in-

cluded in a TOSCA Simple Proﬁle extension. All

these types deﬁne to varying degrees management in-

terfaces and policies for different management fea-

tures, using a general-to-speciﬁc pattern. In a nut-

shell, given a general management feature (e.g. test-

ing), general interface types and policy types are de-

ﬁned for such a feature which get to be extended for

speciﬁc node types (e.g. Database). Managed node

types are also deﬁned by extending basic TOSCA

node types with all available management interfaces.

The submitted input triggers the Workﬂow Gen-

eration phase, that in turn consists of the transfor-

mation of a TOSCA application model into differ-

ent workﬂow plans, namely provisioning and man-

agement plans, based on input data. Speciﬁcally,

the provisioning plan is generated based on node de-

pendencies, whereas management plans are generated

based on policies and management interface opera-

tions deﬁned on nodes. The TOSCA Processor com-

ponent is responsible for parsing a TOSCA applica-

tion model, generating its provisioning and manage-

Automated Generation of Application Management Workﬂows using TOSCA Policies

mysql_database

Database.MySQL

Properties

●

name

●

user

●

password

●

port

Capabilities

Endpoint.Database

Requirements

Container

host: mysql_dbms

mysql_dbms

DBMS.MySQL

Properties

●

port

●

root_password

Capabilities

Container

Requirements

Container

host: mysql_server

mysql_server

Compute

Capabilities

Container

OperatingSystem

wordpress_wa

WebApplication.WordPress

Properties

●

context_root

Requirements

Container

host: apache_ws

Endpoint.Database

database: mysql_database

Root

php: php_sc

ConnectsTo

php_sc

SoftwareComponent.PHP

Capabilities

Root

Requirements

Container

host: app_server

apache_ws

WebServer.Apache

Capabilities

Container

Requirements

Container

host: app_server

Compute

Capabilities

Container

OperatingSystem

HostedOn

app_server

Figure 1: TOSCA application model of a WordPress scenario.

BPMN

Engine

BPMN Plans

Catalogue

BPMN

Provisioning Plan

TOSCA

Processor

Application

specification

Workflow

Generation

BPMN Management

Plan (Test)

BPMN Management

Plan (Backup)

………………………..

TOSCA Scenario

Orchestration

TOSCA Simple

Profile Extension

Figure 2: Overview of the approach for the automated generation of application management workﬂows.

ment plans and validating them. Finally, in the Or-

chestration phase, a workﬂow engine performs the

enactment of such plans.

3.2 Application Speciﬁcation

One of the main strengths of this work is the develop-

ment of a standards-based approach for the descrip-

tion of application topology and management, which

leverages the TOSCA standard.

Although the TOSCA Simple Proﬁle speciﬁcation

includes two normative interface types, i.e. Stan-

dard and Conﬁgure, for component lifecycle and con-

ﬁguration management respectively, there is a lack

of support for management features. As a result,

we extended the standard speciﬁcation by deﬁning

management-oriented interface types. By way of il-

lustration, Figure 3 shows a few exemplifying inter-

face type deﬁnitions included in our TOSCA Sim-

ple Proﬁle extension. As mentioned in Section 3.1,

given a speciﬁc management feature, interface types

are deﬁned via a general-to-speciﬁc pattern. In fact,

as we can see in Figure 3a, two interface types are

present: a general interface type (Test), which is de-

ﬁned for testing purposes, and a speciﬁc interface type

(TestDB), which is an extension of the former for test-

ing database components. Similarly, Figure 3b shows

two interface type deﬁnitions: a general interface type

for backup purposes and a speciﬁc interface type for

backing up database components.

All these additional interface types must be in-

cluded in node type deﬁnitions, which is why we also

extended the normative node type hierarchy in order

to support management features. For the sake of clar-

ity, Figure 4 depicts a node type deﬁnition and a few

policy type deﬁnitions included in our TOSCA Sim-

CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science

100

to sc a . in t er f ac e s . nod e . Tes t :

ve rs i on : 1

de s cr i pt i on : >

TO SC A ma n ag e me n t in t er f ac e ty pe for t es t in g

ge ne r ic c o mp o ne n ts

to sc a . in t er f ac e s . nod e . Te st DB :

de r iv e d_ f r om : t os ca . i nt e rf a ce s . no de . Te st

ve rs i on : 1

de s cr i pt i on : >

TO SC A ma n ag e me n t in t er f ac e ty pe for t es t in g

da tab as e c om p on e nt s

op e ra t io n s :

te s t _d b _ co n n ec t io n :

de s cr i pt i on : |

Ma n ag e me n t op e ra t io n to t es t the DB

co n ne c ti o n

no t if i c at i on s :

db _ c on n e ct i o n_ t e sti n g :

de s cr i pt i on : |

No t if i ca t i on to tr ig g er c o nn e ct i on t e st in g

(a) Test and TestDB interface types

to sc a . in t er f ac e s . nod e . St at e :

ve rs i on : 1

de s cr i pt i on : >

TO SC A ma n ag e me n t in t er f ac e ty pe for s av in g /

re s to rin g the s ta te of gen e ri c c om p on e nt s

to sc a . in t er f ac e s . nod e . St at e DB :

de r iv e d_ f r om : t os ca . i nt e rf a ce s . no de . S ta te

ve rs i on : 1

de s cr i pt i on : >

TO SC A ma n ag e me n t in t er f ac e ty pe for s av in g /

re s to rin g the st at e of dat a ba s e co m po n en t s

op e ra t io n s :

db _ fr eez e :

de s cr i pt i on : |

Ma n ag e me n t op e ra t io n to fre ez e DB sta te

db _t h aw :

de s cr i pt i on : |

Ma n ag e me n t op e ra t io n to t ha w D B s ta te

no t if i c at i on s :

db _ s ta t e _f r ee z i ng :

de s cr i pt i on : |

No t if i ca t i on to tr ig g er DB sta te f r ee z in g

db _ s ta t e_ t h aw i n g :

de s cr i pt i on : |

No t if i ca t i on to tr ig g er DB sta te t h aw in g

(b) State and StateDB interface types

Figure 3: Illustrative interface type deﬁnitions for Testing and Backup features.

ple Proﬁle extension. In particular, as we can see in

Figure 4a, the Database.Managed node type extends

the normative Database node type by adding TestDB

and StateDB interfaces (see Figure 3) for testing and

backup purposes. Policy types are also deﬁned in or-

der to specify the targeted node types and the actions

to perform in relation to management features, when

speciﬁc events are triggered. In particular, policy trig-

gers are linked to notiﬁcation events from the targeted

node types’ management interfaces. Similar to inter-

face types, policy types are deﬁned via a general-to-

speciﬁc pattern as well. As we can see in Figure 4a,

two general policy types are present: Testable and

Freezable for testing and backup purposes, respec-

tively. By contrast, Figure 4b shows two speciﬁc pol-

icy types: TestableDB and FreezableDB for testing

and backing up database components, respectively.

In summary, while normative interface types and

node types provide sufﬁcient deployment capabilities,

the current version of the TOSCA standard is not well

equipped with management features. In order to ﬁll

this gap, we propose to deﬁne: management interface

types, which get to be extended depending on a com-

bination of management features and node type cate-

gories, managed node types, which extend normative

node types and include these management interfaces,

and management policy types, which deﬁne the oper-

ations to execute on the targeted node types based on

management features. The complete set of extended

types is fully TOSCA-compliant, since it is valid ac-

cording to the grammar and rules deﬁned in the stan-

dard, and can be further enriched with additional man-

agement features.

3.3 Management Workﬂow Generation

As mentioned in Section 3.1, the application architect

models a TOSCA application model according to in-

terface types, node types and policy types included

in a TOSCA Simple Proﬁle extension. By apply-

ing this approach, the application model is automat-

ically enriched with management capabilities, which

the TOSCA Processor (see Figure 2) leverages to gen-

erate management workﬂows based on policies and

interface operations deﬁned on nodes. Policies are

the focal point of the entire process, as they specify

the targeted nodes and the actions triggered depend-

ing on management features.

The strategy of generation of management work-

ﬂows depends on management features. In case of

the backup feature a parallel strategy is adopted, since

every stateful component can be backed up indepen-

dently; in case of the testing feature two strategies

are viable: a) parallel strategy and b) sequential strat-

Automated Generation of Application Management Workﬂows using TOSCA Policies

101

tos c a . no d es . D at a ba s e . M an a ge d :

de r i v ed _f r om : t o sca . n ode s . Da t ab a se

de s c r ip t i o n : >

Ex t en si o n of t h e to s ca . n o des . Dat a ba s e n ode t ype w ith

sp e ci f ic m a na ge m en t i nt er f ac e s

in t er fa c es :

Te s tDB :

typ e : t osc a . in t er f ac es . n ode . T e st D B

op e ra ti o ns :

te st _ d b _ c on ne ct i o n :

de s c r ip t i o n : |

Ma n ag em e nt o p er at i on t o test D B c o nn e ct io n

no ti f ic at i o n s :

db _c on n e c t i o n _t es ti ng :

de s c r ip t i o n : |

No t i f ic at i on to t r ig g er co nn e ct io n t e st i ng

St a te D B :

typ e : t osc a . in t er f ac es . n ode . S tat eDB

op e ra ti o ns :

db _ fr ee z e :

de s c r ip t i o n : |

Ma n ag em e nt o p er at i on t o fr e eze DB st a te

db _ th a w :

de s c r ip t i o n : |

Ma n ag em e nt o p er at i on t o de f ro s t DB s tat e

no ti f ic at i o n s :

db _s t a t e _ fr ee zi n g :

de s c r ip t i o n : |

No t i f ic at i on to t r ig g er D B sta t e f re e zi n g

db _s t a t e_ th aw i n g :

de s c r ip t i o n : |

No t i f ic at i on to t r ig g er D B sta t e t ha w ing

tos c a . p o li c ie s . T e st a bl e :

de r i v ed _f r om : t o sca . pol i ci e s . R o o t

de s c r ip t i o n : >

The T OSC A P o lic y T y p e for te s ti n g T OSC A n o des o r gr o ups

of no d es .

tos c a . p o li c ie s . F r ee za b le :

de r i v ed _f r om : t o sca . pol i ci e s . R o o t

de s c r ip t i o n : >

The T OSC A P o lic y T y p e for fr eez in g / t ha w in g T O SCA no d es

or g r oup s of n o des .

(a) Database node type, Testable and Freezable policy types

tos c a . p o li c ie s . T e st ab l eD B :

de r i v ed _f r om : t o sca . pol i ci e s . T es t ab l e

de s c r ip t i o n : >

The T OSC A P o lic y T y p e for te s ti n g T OSC A d a ta ba s e n ode s .

ta r ge t s :

- t osc a . node s . Dat aba se . M an a ge d

tr i gg e rs :

db _c on ne ct io n_ te st i n g _ t r i g g e r :

de s c r ip t i o n : |

The t ri g ge r k i cks i n when co nn e ct io n t e st i ng get s

no t if i ed

eve n t : d b_ c o n n e c t io n_ te st i n g

ac t ion :

- c a l l_ op e r a ti on : t osc a . in t er f a c es . n ode . T est D B .

te st _ d b _ c on ne ct i o n

tos c a . p o li c ie s . F r e e za b l e DB :

de r i v ed _f r om : t o sca . pol i ci e s . F re e za b l e

de s c r ip t i o n : >

The T OSC A P o lic y T y p e for fr eez in g / t ha w in g T O SCA

da t ab a se no d es .

ta r ge t s :

- t osc a . node s . Dat aba se . M an a ge d

tr i gg e rs :

db _s ta te _f r e e z i n g _ t r i g g er :

de s c r ip t i o n : |

The t ri g ge r k i cks i n when D B sta t e f re e zi n g g ets

no t if i ed

eve n t : d b _ s t a te _f re e z i ng

ac t ion :

- c a l l_ op e r a ti on : t osc a . in t er f a c es . n ode . S ta t eD B .

db _ fr ee z e

db _s ta te _ t h a w i n g _ t r ig ge r :

de s c r ip t i o n : |

The t ri g ge r k i cks i n when D B sta t e t ha w in g ge t s

no t if i ed

eve n t : d b _ s ta te _t h a w i n g

ac t ion :

- c a l l_ op e r a ti on : t osc a . in t er f a c es . n ode . S ta t eD B .

db _ th a w

(b) TestableDB and FreezableDB policy types

Figure 4: Illustrative node type and policy type deﬁnitions for Testing and Backup features.

egy. Components can be either tested in isolation with

the parallel strategy or tested consecutively following

node dependencies with the sequential strategy.

The parallel generation of Backup workﬂows

works as shown in Figure 5. In general, considering

more than one Freezable policies (see Figure 4a), a

new workﬂow is generated where more than one paths

can trigger the workﬂow instantiation by means of an

event-based gateway. Each path consists of a mes-

sage intermediate event, which is linked to a notiﬁca-

tion event from the targeted nodes’ State interface (see

Figure 3b), and a parallel multi-instance subprocess,

whose number of instances depends on the number of

target nodes the policy is applied to. A service task in

the subprocess executes the action of the policy trig-

ger, which enacts the actual backup.

Figure 6 shows how Testing workﬂows are gener-

ated. Firstly, a workﬂow is generated for each node

type. Secondly, a distinction is made between nodes

without dependencies and nodes with dependencies.

The former are tested in isolation, while the latter can

be either tested in isolation or tested sequentially ac-

cording to node dependencies. In the ﬁrst case (see

Figure 6a), considering more than one testing opera-

tions, a new workﬂow is generated where more than

one paths can trigger the workﬂow instantiation by

means of an event-based gateway. Each path consists

of a message intermediate event, which is linked to a

notiﬁcation event from the targeted nodes’ Test inter-

face (see Figure 3a), and a parallel multi-instance sub-

process, whose number of instances depends on the

number of target nodes the policy is applied to. A ser-

vice task in the subprocess executes the action of the

policy trigger, which enacts the actual testing. Finally,

a message end event marks the end of the workﬂow.

In the second case (see Figure 6b), a new workﬂow

is generated where either a message start event, com-

ing from the targeted nodes’ Test interface notiﬁca-

tions, or a parallel multi-instance receive task, waiting

for notiﬁcations from node requirements under test,

triggers the workﬂow instantiation. A parallel multi-

instance subprocess is then activated depending on the

number of target nodes the policy is applied to. A ser-

vice task in the subprocess executes the action of the

CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science

102

Figure 5: Parallel strategy for Backup workﬂows.

policy trigger enacting the actual testing. Finally, a

message end event marks the end of the workﬂow.

4 PROTOTYPE VALIDATION

In this section, we ﬁrst discuss the implementation

of a prototype and then corroborate the working be-

haviour of our approach by applying both testing and

backup management features on our motivation sce-

nario (see Figure 1).

4.1 System Overview

To validate our approach, we implemented a proto-

type based on the open-source TORCH (Tomarchio

et al., 2021). TORCH is a TOSCA-based frame-

work which deploys and orchestrates VM-based and

container-based applications on top of different cloud

providers. In order to do so, TORCH transforms a

TOSCA application model into an equivalent BPMN

workﬂow and dataﬂow model, which a BPMN en-

gine leverages to enforce the operations speciﬁed in

the model.

Figure 7 shows the multi-layered framework ar-

chitecture of TORCH. The Application Speciﬁcation

Layer consists of two components: the Dashboard,

which is the front-end component, and the TOSCA

Modeller, which guides the user to sketch application

requirements. The Orchestration Layer comprises the

TOSCA Processor component, which is in charge of

validating, parsing and converting TOSCA applica-

tion templates into BPMN plans, and the BPMN En-

gine component, which is responsible for instantiat-

ing and orchestrating such BPMN plans. The Service

Binding Layer manages the orchestration of applica-

tion resources and services.

The proposed approach for the automated gen-

eration of management workﬂows (see Section 3)

is based on the extension of the TOSCA Proces-

sor (see Figure 7), which consists of three compo-

nents: TOSCA-Parser, BPMN-Generator and BPMN-

Validator. The TOSCA-Parser provides means to

load, parse and validate a TOSCA service template

and create the corresponding dependency graph. The

BPMN-Generator creates a BPMN plan depending on

a parsed service template and its dependency graph.

The BPMN-Validator validates an automatically gen-

erated plan against the BPMN speciﬁcation. Further

details about these components can be found in (Cal-

caterra et al., 2017; Calcaterra et al., 2018).

As mentioned above, the TOSCA Processor was

extended in order to support the automatic generation

of holistic management workﬂows. Speciﬁcally, sev-

eral novelties were introduced in the TOSCA-Parser

and the BPMN-Generator. As regards the TOSCA-

Parser, it was extended in order to provide an ad-hoc

parsing of node properties and artifacts, custom in-

terfaces, interface operations and notiﬁcations, policy

triggers. As for the BPMN-Generator, since it was

originally conceived to generate provisioning plans

based on the TOSCA dependency graph, it was ex-

tended in order to provide support for the generation

of management plans based on TOSCA policies. In

particular, while the original BPMN-Generator was

only capable of generating workﬂows depending on

node dependencies, the extended BPMN-Generator

is capable of generating workﬂows even when there

are no explicit node dependencies. For instance, it

can support both sequential and parallel strategies for

workﬂow generation.

Automated Generation of Application Management Workﬂows using TOSCA Policies

103

(a) Nodes without dependencies

(b) Nodes with dependencies

Figure 6: Parallel and sequential strategies for Testing workﬂows.

Service Binding

Layer

Service

Broker

Service

Broker

Service

Registry

Service

Registry

Orchestration

Layer

Application

Specification

Layer

Dashboard

TOSCA Modeller

BPMN Engine

TOSCA Processor

Enterprise

Service Bus

Enterprise

Service Bus

Service

Connectors

Service

Connectors

Figure 7: TORCH - Framework architecture.

4.2 Case Study

Based on the motivation scenario introduced in Sec-

tion 2.3, we discuss two different management fea-

tures, namely Testing and Backup. By applying our

approach, the motivating scenario is automatically en-

riched with test and backup operations by means of

feature-speciﬁc node types and policy types. The

added operations are shown in Figure 8. With ref-

erence to the backup feature, we can see that the

mysql database node includes the StateDB interface.

With regard to the testing feature, every node contains

a speciﬁc interface for testing purposes. By way of il-

lustration, we can observe that the mysql server and

mysql dbms nodes include the TestCompute and Test-

DBMS interfaces, respectively.

Based on the approach for the management work-

ﬂow generation in Section 3.3, Figure 9 shows the

Backup workﬂow for the mysql database node in

the motivation scenario. Given a FreezableDB pol-

icy targeting a Database.Managed node (see Fig-

ure 4b), a new workﬂow is generated where the

CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science

104

mysql_database

Database.Managed.MySQL

Properties

●

name

●

user

●

password

●

port

Capabilities

Endpoint.Database

Requirements

Container

host: mysql_dbms

mysql_dbms

DBMS.Managed.MySQL

Properties

●

port

●

root_password

Capabilities

Container

Requirements

Container

host: mysql_server

mysql_server

Compute

Capabilities

Container

OperatingSystem

wordpress_wa

WebApplication.Managed.WordPress

Properties

●

context_root

Requirements

Container

host: apache_ws

Endpoint.Database

database: mysql_database

Root

php: php_sc

ConnectsTo

php_sc

SoftwareComponent.Managed.PHP

Capabilities

Root

Requirements

Container

host: app_server

apache_ws

WebServer.Managed.Apache

Capabilities

Container

Requirements

Container

host: app_server

Compute

Capabilities

Container

OperatingSystem

HostedOn

TestCompute

TestDBMS

test_ping

test_ssh_connection

test_ping

test_ssh_connection

test_dbms_connection

TestDB

test_db_connection

StateDB

db_freeze

db_thaw

TestWS

test_ws_connection

TestSC

test_sc_installation

TestWA

test_wa_connection

app_server

Type your text

Figure 8: Management-oriented TOSCA application model of a WordPress scenario.

db state freezing message start event, coming from

the StateDB interface notiﬁcations, triggers the work-

ﬂow instantiation. A parallel multi-instance subpro-

cess is then activated depending on the number of tar-

get nodes the policy is applied to. In this case there

is only one target node (i.e. mysql database). The

db freeze service task in the subprocess executes the

action of the policy trigger, which enacts the actual

database backup.

Figure 10 shows exemplifying Testing workﬂows

for the mysql server and app server nodes (Figure

10a) and the mysql dbms node (Figure 10b) in the

motivation scenario. In contrast with the strategy of

generation of Backup workﬂows, the strategy of gen-

eration of Testing workﬂows can take node dependen-

cies into account. In particular, a distinction is made

between nodes having no dependencies, such as Com-

pute nodes, and nodes having dependencies, such as

DBMS nodes.

In the ﬁrst case (see Figure 10a), given a Testable-

Compute policy targeting a Compute node, two paths

are generated where either the compute test ping

message intermediate event or the compute test ssh

message intermediate event, coming from the Test-

Compute interface notiﬁcations, triggers the work-

ﬂow instantiation by means of an event-based gate-

way. Regardless of the path being activated, a paral-

lel multi-instance subprocess is then instantiated de-

pending on the number of target nodes the policy is

applied to. In this case there are two target nodes (i.e.

mysql server and app server). Either the test ping

service task or the test ssh connection service task

executes the action of the policy trigger, which en-

acts the actual Compute testing. Finally, the com-

pute tested message end event marks the end of the

workﬂow.

In the second case (see Figure 10b), given

a TestableDBMS policy targeting a DBMS node,

a new workﬂow is generated where either the

dbms connection testing message start event, com-

ing from the TestDBMS interface notiﬁcations, or

the await test notiﬁcations parallel multi-instance re-

ceive task, waiting for notiﬁcations from node re-

quirements under test (i.e. mysql server), triggers the

workﬂow instantiation. A parallel multi-instance sub-

process is then activated depending on the number

of target nodes the policy is applied to. In this case

there is only one target node (i.e. mysql dbms). The

test dbms connection service task in the subprocess

executes the action of the policy trigger, which enacts

the actual DBMS testing. Finally, the dbms tested

message end event marks the end of the workﬂow.

Automated Generation of Application Management Workﬂows using TOSCA Policies

105

Figure 9: Database Backup workﬂow for a WordPress scenario.

5 RELATED WORK

The topics of policy-based automation and applica-

tion management have gained popularity in business-

oriented and research projects (Tomarchio et al.,

2020). This section provides a brief overview on a

few works that exploited policies, TOSCA or similar

approaches for application management.

In (Alexander et al., 2017) the authors presented

TOSCAMP, an end-to-end cloud orchestration solu-

tion based on TOSCA and CAMP, which introduces

extensions to CAMP to allow for multi-cloud applica-

tion orchestration through declarative policies. Even

though this work leveraged policies for application or-

chestration, no holistic management was considered.

In (Pierantoni et al., 2020) the authors introduced Mi-

CADO, a cloud orchestration framework to deploy

and manage TOSCA-based applications in the cloud.

An extensible set of TOSCA policies was also elabo-

rated to manage deployment, performance, scalability

and security requirements of applications.

In (Caballer et al., 2018) the authors presented

INDIGO-DataCloud, a cloud orchestration platform

to orchestrate TOSCA-based applications with com-

plex topologies and operational requirements (e.g.

auto-scaling resources) across heterogeneous cloud

infrastructures. In (Kumara et al., 2021) the authors

proposed the SODALITE platform to support the de-

ployment, execution, monitoring and policy-based

runtime adaptation of TOSCA-based applications on

heterogeneous cloud-edge infrastructures. In (Cankar

et al., 2020) the authors presented xOpera, an orches-

trator capable of enacting application deployment and

addressing autoscaling in a policy-based fashion by

using TOSCA standard templates. All the aforemen-

tioned works dealt with application deployment and

policy-based management. Nevertheless, no support

for holistic management was provided.

In (Wurster et al., 2018) the authors presented a

modelling concept to annotate a deployment model

with deployment tests. Tests are automatically run af-

ter deployment to verify that the application is work-

ing properly. Limitations of the proposal include the

fact that the deployment system must provide a ba-

sic set of plugins and be extensible with custom plu-

gins from arbitrary sources. In addition, the approach

features no other holistic management except testing.

In (Harzenetter et al., 2020) the authors introduced

an approach to terminate an application in its current

state and restart it in the same state again. Freeze

plans and defrost plans are automatically generated

in order to save and restore the state of stateful com-

ponents. Limitations of the proposal include the as-

sumption that a stateful component type must be an-

notated to indicate that it will hold a state between

requests. Besides, the approach features no other

holistic management except state backup and recov-

ery. In (Harzenetter et al., 2019) the authors proposed

a concept to automatically generate executable man-

agement workﬂows based on the application deploy-

ment model. The modelled components are enriched

with component-speciﬁc management operations and

a management workﬂow gets generated to orchestrate

such operations. However, the approach suffers from

some limitations. To provide new management fea-

tures, on the one hand, the workﬂow generation must

be extended with a corresponding plugin and, on the

other one, domain experts have to implement man-

agement operations in new component types.

6 CONCLUSION

The ever-growing interest in cloud computing has fos-

tered a business landscape, where application provi-

sioning and management have become a key factor for

the competitiveness of cloud providers. Although a

number of automated orchestration frameworks have

appeared, holistic application management regarding

diverse components distributed across multiple het-

erogeneous environments is still mostly unsupported.

In this paper, we presented an approach for the

CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science

106

(a) Compute test

(b) DBMS test

Figure 10: Illustrative Testing workﬂows for a WordPress scenario.

automated generation of holistic management work-

ﬂows by enriching TOSCA application models with

reusable TOSCA node types and policy types. The

main effort was devoted to the application model de-

scription based on a TOSCA extension and the fol-

lowing management workﬂow generation. A proto-

type implementation and a case study were also dis-

cussed to showcase the viability of the proposal.

Future work will focus on two research directions.

On the one hand, more and more management opera-

tions will be under examination to be included in our

TOSCA extension. On the other hand, supplemen-

tary strategies besides sequential and parallel work-

ﬂow generation will be investigated.

REFERENCES

Alexander, K., Lee, C., Kim, E., and Helal, S. (2017). En-

abling end-to-end orchestration of multi-cloud appli-

cations. IEEE Access, 5:18862–18875.

Bellendorf, J. and Mann, Z.

A. (2018). Cloud Topology and

Orchestration Using TOSCA: A Systematic Literature

Review. In Kritikos, K., Plebani, P., and de Paoli,

F., editors, Service-Oriented and Cloud Computing,

pages 207–215. Springer International Publishing.

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

Cloud services orchestration: A comparative study of

existing approaches. In IEEE 28th International Con-

ference on Advanced Information Networking and Ap-

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

Caballer, M., Zala, S., Garc

ıa,

A. L., Molt

o, G., Fern

andez,

P. O., and Velten, M. (2018). Orchestrating Complex

Application Architectures in Heterogeneous Clouds.

Journal of Grid Computing, 16(1):3–18.

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

O. (2017). Combining TOSCA and BPMN to En-

able Automated Cloud Service Provisioning. In Pro-

ceedings of the 7th International Conference on Cloud

Computing and Services Science (CLOSER 2017),

pages 159–168, Porto (Portugal).

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

O. (2018). A framework for the orchestration and

provision of cloud services based on tosca and bpmn.

Automated Generation of Application Management Workﬂows using TOSCA Policies

107

In Ferguson, D., Mu

noz, V. M., Cardoso, J., Helfert,

M., and Pahl, C., editors, Cloud Computing and Ser-

vice Science, pages 262–285, Cham. Springer Interna-

tional Publishing.

Cankar, M., Luzar, A., and Tamburri, D. A. (2020). Auto-

scaling using tosca infrastructure as code. In Muccini,

H., Avgeriou, P., Buhnova, B., Camara, J., Caporus-

cio, M., Franzago, M., Koziolek, A., Scandurra, P.,

Trubiani, C., Weyns, D., and Zdun, U., editors, Soft-

ware Architecture, pages 260–268, Cham. Springer

International Publishing.

Delaet, T., Joosen, W., and Vanbrabant, B. (2010). A sur-

vey of system conﬁguration tools. In Proceedings of

the 24th International Conference on Large Installa-

tion System Administration, LISA’10, page 1–8, USA.

USENIX Association.

Dikaiakos, M. D., Katsaros, D., Mehra, P., Pallis, G., and

Vakali, A. (2009). Cloud Computing: Distributed

Internet Computing for IT and Scientiﬁc Research.

IEEE Internet Computing, 13(5):10–13.

Flexera (2021). Flexera 2021 State of the Cloud Re-

port. https://info.ﬂexera.com/CM-REPORT-State-of-

the-Cloud. Last accessed on 30-11-2021.

Harzenetter, L., Breitenb

ucher, U., K

epes, K., and Ley-

mann, F. (2020). Freezing and defrosting cloud ap-

plications: automated saving and restoring of running

applications. SICS Software-Intensive Cyber-Physical

Systems, 35(1):101–114.

Harzenetter, L., Breitenb

ucher, U., Leymann, F., Saatkamp,

K., Weder, B., and Wurster, M. (2019). Auto-

mated Generation of Management Workﬂows for Ap-

plications Based on Deployment Models. In 2019

IEEE 23

International Enterprise Distributed Ob-

ject Computing Conference (EDOC), pages 216–225.

IEEE.

Kumara, I., Mundt, P., Tokmakov, K., Radolovi

c, D.,

Maslennikov, A., Gonz

alez, R. S., Fabeiro, J. F., Quat-

trocchi, G., Meth, K., Di Nitto, E., Tamburri, D. A.,

Van Den Heuvel, W.-J., and Meditskos, G. (2021). So-

dalite@rt: Orchestrating applications on cloud-edge

infrastructures. Journal of Grid Computing, 19(3):29.

Leite, L., Rocha, C., Kon, F., Milojicic, D., and Meirelles, P.

(2019). A survey of devops concepts and challenges.

ACM Comput. Surv., 52(6).

Marston, S., Li, Z., Bandyopadhyay, S., Zhang, J., and

Ghalsasi, A. (2011). Cloud computing — the business

perspective. Decision Support Systems, 51(1):176 –

189.

Morris, K. (2016). Infrastructure as Code: Managing

Servers in the Cloud. O’Reilly Media, Inc., 1st edi-

tion.

OASIS (2007). Web Services Business Process Exe-

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

open.org/committees/wsbpel/. Last accessed on 30-

11-2021.

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: 30-11-2021.

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

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

Proﬁle-YAML/v1.3. Last accessed on 30-11-2021.

OMG (2011). Business Process Model and Notation

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

Last accessed on 30-11-2021.

Pierantoni, G., Kiss, T., Terstyanszky, G., DesLauriers, J.,

Gesmier, G., and Dang, H.-V. (2020). Describing and

processing topology and quality of service parameters

of applications in the cloud. Journal of Grid Comput-

ing, 18(4):761–778.

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.

Toffetti, G., Brunner, S., Bl

ochlinger, M., Spillner, J., and

Bohnert, T. M. (2017). Self-managing cloud-native

applications: Design, implementation, and experi-

ence. Future Generation Computer Systems, 72:165–

179.

Tomarchio, O., Calcaterra, D., Di Modica, G., and Maz-

zaglia, P. (2021). Torch: a tosca-based orchestrator

of multi-cloud containerised applications. Journal of

Grid Computing, 19(5).

Tomarchio, O., Calcaterra, D., and Modica, G. D. (2020).

Cloud resource orchestration in the multi-cloud land-

scape: a systematic review of existing frameworks.

Journal of Cloud Computing, 9(49).

Weerasiri, D., Barukh, M. C., Benatallah, B., Sheng, Q. Z.,

and Ranjan, R. (2017). A Taxonomy and Survey

of Cloud Resource Orchestration Techniques. ACM

Comput. Surv., 50(2):26:1–26:41.

Wurster, M., Breitenb

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

(2018). Modeling and Automated Execution of Ap-

plication Deployment Tests. In Proceedings of the

IEEE 22nd International Enterprise Distributed Ob-

ject Computing Conference (EDOC), pages 171–180.

IEEE Computer Society.

CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science

108