modelling the behaviour of management operations in cloud

Modelling the Behaviour of ManagementOperations in Cloud-based Applications?

Antonio Brogi, Andrea Canciani, Jacopo Soldani, and PengWei Wang

Department of Computer Science, University of Pisa, Italy

Abstract. How to flexibly manage complex applications over hetero-geneous clouds is one of the emerging problems in the cloud era. TheOASIS Topology and Orchestration Specification for Cloud Applications(TOSCA) aims at solving this problem by providing a language to de-scribe and manage complex cloud applications in a portable, vendor-agnostic way. TOSCA permits to define an application as an orchestra-tion of nodes, whose types can specify states, requirements, capabilitiesand management operations — but not how they interact each another.

In this paper we first propose how to extend TOSCA to specify thebehaviour of management operations and their relations with states, re-quirements, and capabilities. We then illustrate how such behaviour canbe naturally modelled, in a compositional way, by means of open Petrinets. The proposed modelling permits to automate different analyses,such as determining whether a deployment plan is valid, which are itseffects, or which plans allow to reach certain system configurations.

1 Introduction

Available cloud technologies permit to run on-demand distributed software sys-tems at a fraction of the cost which was necessary just a few years ago. On theother hand, how to flexibly deploy and manage such applications over heteroge-neous clouds is one of the emerging problems in the cloud era.

In this perspective, OASIS recently released the Topology and OrchestrationSpecification for Cloud Applications (TOSCA [19,20]), a standard to supportthe automation of the deployment and management of complex cloud-basedapplications. TOSCA provides a modelling language to specify, in a portable andvendor-agnostic way, a cloud application and its deployment and management.An application can be specified in TOSCA by instantiating component types, byconnecting a component’s requirements to the capabilities of other components,and by orchestrating components’ operations into plans defining the deploymentand management of the whole application.

Unfortunately, the current specification of TOSCA [19] does not permit todescribe the behaviour of the management operations of an application. Namely,it is not possible to describe the order in which the management operations of

? This work has been partly supported by the EU-FP7-ICT-610531 project SeaClouds.

a component must be invoked, nor how those operations depend on the require-ments and affect the capabilities of that component. As a consequence, the ver-ification of whether a plan to deploy an application is valid must be performedmanually, with a time-consuming and error-prone process.

In this paper, we first propose a way to extend TOSCA to specify the be-haviour of management operations and their relations with states, requirements,and capabilities. We define how to specify the management protocol of a TOSCAcomponent by means of finite state machines whose states and transitions areassociated with conditions on (some of) the component’s requirements and ca-pabilities. Intuitively speaking, those conditions define the consistency of com-ponent’s states and constrain the executability of component’s operations to thesatisfaction of requirements.

We then illustrate how the management protocols of TOSCA components canbe naturally modelled, in a compositional way, by means of open Petri nets [2,14].This allows us to obtain the management protocol of an arbitrarily complex cloudapplication by combining the management protocols of its components. Theproposed modelling permits to automate different analyses, such as determiningwhether a deployment plan is valid, which are its effects, or which plans allowto reach certain system configurations.

The rest of the paper is organized as follows. Sect. 2 introduces the neededbackground (TOSCA and open Petri nets), while Sect. 3 illustrates a scenariomotivating the need for an explicit, machine-readable representation of man-agement protocols. Sect. 4 describes how TOSCA can be extended to specifythe behaviour of management operations, how such behaviour can be naturallyand compositionally modelled by means of open Petri nets, and how the pro-posed modelling permits to automate different types of analysis. Related workis discussed in Sect. 5, while some concluding remarks are drawn in Sect. 6.

2 Background

2.1 TOSCA

TOSCA [19] is an emerging standard whose main goals are to enable (i) thespecification of portable cloud applications and (ii) the automation of their de-ployment and management. In this perspective, TOSCA provides an XML-basedmodelling language which allows to specify the structure of a cloud applicationas a typed topology graph, and deployment/management tasks as plans. Moreprecisely, each cloud application is represented as a ServiceTemplate (Fig. 1),which consists of a TopologyTemplate and (optionally) of management Plans.

The TopologyTemplate is a typed directed graph that describes the topo-logical structure of the composite cloud application. Its nodes (NodeTemplates)model the application components, while its edges (RelationshipTemplates)model the relations between those application components. NodeTemplates andRelationshipTemplates are typed by means of NodeTypes and Relationship-Types, respectively. A NodeType defines (i) the observable properties of an appli-cation component C, (ii) the possible states of its instances, (iii) the requirements

192 PNSE’15 – Petri Nets and Software Engineering

Fig. 1. TOSCA ServiceTemplate.

needed by C, (iv) the capabilities offered by C to satisfy other components’requirements, and (v) the management operations of C. RelationshipTypesdescribe the properties of relationships occurring among components. Syntacti-cally, properties are described by PropertiesDefinitions, states by Instance-States, requirements by RequirementDefinitions (of certain Requirement-Types), capabilities by CapabilityDefinitions (of certain CapabilityTypes),and operations by Interfaces and Operations.

On the other hand, Plans enable the description of application deploymentand/or management aspects. Each Plan is a workflow that orchestrates the op-erations offered by the application components (i.e., NodeTemplates) to address(part of) the management of the whole cloud application1.

2.2 (Open) Petri nets

Before providing a formal definition of open Petri nets (Def. 2), we recall thedefinition of Petri nets just to introduce the employed notation. We instead omitto recall other very basic notions about Petri nets (e.g., marking of a net, firingof transitions, etc.) as they are well-know and easy to find in literature [18].

Definition 1. A Petri net is a tuple P = 〈P, T, •·, ·•〉 where P is a set of places,T is a set of transitions (with P ∩ T = ∅), and •·, ·• : T → 2P are functionsassigning to each transition its input and output places.

According to [2], an open Petri net is an ordinary Petri net with a distin-guished set of (open) places that are intended to represent the interface of thenet towards the external environment, meaning that the environment can put orremove tokens from those places. In this paper, we will employ a subset of openPetri nets, where transitions consume at most one token from each place, andwhere the environment can both add/remove tokens to/from all open places.

Definition 2. An open Petri net is a pair Z = 〈P, I〉, where P = 〈P, T, •·, ·•〉is an ordinary Petri net, and I ⊆ P is the set of open places. The places in P \Iwill be referred to as internal places.1 A more detailed and self-contained introduction to TOSCA can be found in [7].

A. Brogi et al: Modelling the Behaviour of Management Operations 193

3 Motivating scenario

Consider a developer who wants to deploy and manage the web services Send-SMS and Forex on a TOSCA-compliant cloud platform. She first describes herservices in TOSCA, and then selects the third-party components (i.e. NodeTypes)needed to run them. For instance, she indicates that her services will run on aTomcat server installed on an Ubuntu operating system, which in turn runs on anAmazonEC2 virtual machine. Fig. 2 illustrates the resulting TopologyTemplate,

Fig. 2. Motivating scenario.

according to the Winery graphical notation [15]. For the sake of simplicity, andwithout loss of generality, in the following we focus only on the lifecycle interface[7] of each NodeType instantiated in the topology (i.e., the interface containingthe operations to install, configure, start, stop, and uninstall a component).

Suppose that the developer wants to describe the automation of the de-ployment of the SendSMS and Forex services by writing a TOSCA Plan. SinceTOSCA does not include any representation of the management protocols of(third-party) NodeTypes, developers may produce invalid Plans. For instance,while Fig. 3 illustrates three seemingly valid Plans, only the third is a valid

(a) An invalid BPMN plan.

(b) Another invalid BPMN plan.

(c) A valid BPMN plan.

Fig. 3. Deployment Plans.


plan. The other Plans cannot be considered valid since (a) Tomcat’s Configureoperation cannot be executed before Tomcat is running, and (b) Tomcat cannotbe installed when the Ubuntu operating system is not running.

While the validity of Plans can be manually verified, this is a time-consumingand error-prone process. In order to enable the automated verification of thevalidity of Plans, TOSCA should be extended so as to permit specifying thebehaviour of and the relations among NodeTypes’ management operations.

4 Modelling management protocols

While a TOSCA NodeType can be described by means of its states, requirements,capabilities, and management operations, there is currently no way to specifyhow management operations affect states, how operations or states depend onrequirements, or which capabilities are concretely provided in a certain state.

The objective of the next section is precisely to propose a way to extendTOSCA to specify the behaviour of management operations and their relationswith states, requirements, and capabilities.

4.1 Cloud-based application management protocols in TOSCA

Let N be a TOSCA NodeType, and let us denote its states, requirements, capa-bilities, and management operations with SN , RN , CN , and ON , respectively.

We want to permit describing whether and how the management operationsof N depend on other operations of the same node as well as on operations ofthe other nodes providing the capabilities that satisfy the requirements of N .

– The first type of dependencies can be easily described by specifying the re-lationship between states and management operations of N . More precisely,the order with which the operations of N can be executed can be describedby means of a transition relation T , that specifies whether an operation ocan be executed in a state s, and which state is reached by executing o in s.

– The second type of dependencies can be described by associating transitionsand states with (possibly empty) sets of requirements to indicate that thecorresponding capabilities are assumed to be provided. More precisely, therequirements associated with a transition t specify which are the capabili-ties that must be offered by other nodes to allow the execution of t. Therequirements associated with a state of a NodeType N specify which are thecapabilities that must (continue to) be offered by other nodes in order for Nto (continue to) work properly.

To complete the description, each state s of a NodeType N also specifies thecapabilities provided by N in s.

Definition 3. Let N = 〈SN , RN , CN , ON ,MN 〉 be a NodeType, where SN , RN ,CN , and ON are the sets of its states, requirements, capabilities, and manage-ment operations.MN = 〈s,R,C, T 〉 is the management protocol of N , where


– s ∈ SN is the initial state,– R is a function indicating, for each state s ∈ SN , which conditions on re-

quirements must hold (i.e., R(s) ⊆ RN , with R(s) = ∅)2,– C is a function indicating which capabilities of N are concretely offered in a

state s ∈ SN (i.e., C(s) ⊆ CN , with C(s) = ∅), and– T ⊆ SN × 2RN × ON × SN is a set of quadruples modelling the transition

relation (i.e., 〈s,H, o, s′〉 ∈ T means that in state s, and if condition H holds,o is executable and leads to state s′).

Syntactically, to describe MN we slightly extend the syntax for describing aTOSCA NodeType. Namely, we enrich the description of an InstanceState byintroducing the nested elements ReliesOn and Offers. ReliesOn defines R (ofDef. 3) by enabling the association between states and assumed requirements,while Offers defines C by indicating the capabilities offered in a state. Further-more, we introduce the element ManagementProtocol, which allows to specifythe InitialState s of the protocol, as well as the Transitions defining thetransition relation T .

The management protocols of the NodeTypes in the motivating scenario ofSect. 3 are shown in Fig. 4, where MWS is the management protocol for Web-Services,MS for Server,MOS for OperatingSystem, andMVM for Virtual-Machine. Consider for instance the management protocol MS of NodeType

MWS MOS

MS MVM

Fig. 4. Management protocols of the NodeTypes in our motivating scenario.

Server defining the Tomcat server. Its states SN are Unavailable (initial state),Stopped, and Working, the only requirement in RN is ServerContainer, theonly capability in CN is WebAppRuntime, and its management operations areSetup, Uninstall, Run, Stop, and Configure. States Unavailable and Stoppedare not associated with any requirement or capability. State Working instead2 Without loss of generality, we assume that the initial state of a management protocolhas no requirements and does not provide any capability.


specifies that the capability corresponding to the ServerContainer requirementmust be provided (by some other node) in order for Server to (continue to) workproperly. State Working also specifies that Server provides the WebAppRuntimecapability when in such state. Finally, all transitions (but those involving opera-tions Stop and Configure) constrain their firability by requiring the capabilitythat satisfies ServerContainer to be offered (by some other node).

Note that Def. 3 permits to define operations that have non-deterministiceffects when applied in a state (e.g., a state can have two outgoing transitionscorresponding to the same operation and leading to different states). This form ofnon-determinism is not acceptable in the management of a TOSCA application[7]. We will thus focus on deterministic management protocols, i.e. protocolsensuring deterministic effects when performing an operation in a state.

Definition 4. Let N = 〈SN , RN , CN , ON ,MN 〉 be a NodeType. The manage-ment protocolMN = 〈s,R,C, T 〉 is deterministic if and only if

∀〈s1, H1, o1, s′1〉, 〈s2, H2, o2, s

′2〉 ∈ T : s1 = s2 ∧ o1 = o2 ⇒ s′1 = s′2

4.2 Modelling cloud-based application management protocols in(open) Petri nets

A (deterministic) management protocol MN of a NodeType N can be easilyencoded by an open Petri net. Each state of MN is mapped into an internalplace of the Petri net, and each capability and requirement of N is mapped intoan open place of the same net. Furthermore, each transition 〈s,H, o, s′〉 ofMN

is mapped into a Petri net transition t with the following inputs and outputs:

(i) The input places of t are the places denoting s, the requirements that areneeded but not already available in s (i.e., (R(s′) ∪ H) − R(s)), and thecapabilities that are provided in s but not in s′ (i.e., C(s)− C(s′)).

(ii) The output places of t are the places denoting s′, the requirements thatwere needed but are no more assumed to hold in s′ (i.e., (R(s)∪H)−R(s′)),and the capabilities that are provided in s′ but not in s (i.e., C(s′)−C(s)).

The initial marking of the obtained net prescribes that the only place initiallycontaining a token is that corresponding to the initial state s ofMN .

Definition 5. Let N = 〈SN , RN , CN , ON ,MN 〉 be a NodeType, with MN =〈s,R,C, T 〉. The management protocol MN is encoded into an open net ZN =〈PN , IN 〉, with PN = 〈PN , TN , •·, ·•〉 and IN ⊆ PN , as follows.

– The set PN of places contains a separate place for each state in SN , for eachrequirement in RN , and for each capability in CN .

– The set IN ⊂ PN of open places contains the places denoting the requirementsin RN and the capabilities in CN .

– The set TN contains a net transition t for each transition 〈s,H, o, s′〉 ∈ T .(i) The set •t of input places contains the place s, the places denoting the

requirements in (R(s′) ∪H) − R(s), and those denoting the capabilitiesin C(s)− C(s′).


(ii) The set t• of output places contains the place s′, the places denoting therequirements in (R(s) ∪H) − R(s′), and those denoting the capabilitiesin C(s′)− C(s).

The initial marking of ZN consists of only one token in place s.

The above definition ensures that the Petri net encoding of a management pro-tocol satisfies the following properties:

– There is a one-to-one correspondence between the marking of the internalplaces of the Petri net and the states of a management protocol. Namely,there is exactly one token in the internal place denoting the current state,and no tokens in the other internal places.

– Each operation can be performed if and only if all the necessary requirementsare available in the source state, and no capability required by any connectedcomponent is disabled in the target state.

Consider for instance the management protocolMS (Fig. 4), whose correspond-ing Petri net is shown in Fig. 5. Each state in MS is translated into an in-

Fig. 5. Example of Petri net translation.

ternal place (represented as a circle), while the ServerContainer requirementand the WebAppRuntime capability are translated into open places (representedas diamonds). Additionally, protocol transitions are translated into net transi-tions. For example, the transition 〈Stopped, {ServerContainer}, Run, Working〉is translated into a Petri net transition, whose inputs places are Stopped andServerContainer, and whose outputs places are Working and WebAppRuntime.

4.3 Analysis of cloud-based application management protocols

We now show how the Petri net modelling the management protocol of a TOSCATopologyTemplate (specifying a whole cloud-based application) can be obtained,in a compositional way, from the Petri nets modelling the management protocolsof the NodeTypes in such TopologyTemplate.

We first need to model (by open Petri nets working as a capability con-trollers) the RelationshipTemplates that define in a TopologyTemplate the


association between the requirements of a NodeTypes and the capabilities ofother NodeTypes. To do that, we first define an utility binding function thatreturns the set of requirements with which a capability is associated.

Definition 6. Let S be a ServiceTemplate, and let c be a capability offeredby a NodeType in S. We define b(c, S) = {r1, . . . , rn}, where r1, . . . , rn are therequirements connected to c in S by means of RelationshipTemplates.

We now exploit function b to define capability controllers. On the one hand, thecontroller must ensure that once a capability c is available, the nodes exposingthe connected requirements r1, . . . , rn are able to simultaneously exploit it. Thisis obtained by adding a transition c↑ able to propagate the token from placec to places r1, . . . , rn (i.e., the input place of c↑ is c, and its output placesare r1, . . . , rn). On the other hand, the controller has also to ensure that thecapability is not removed while at least another node is actively assuming itsavailability (with a condition on a connected requirement). Thus, we introducea transition c↓ whose input places are r1, . . . , rn and whose output place is c.

Definition 7. Let S be a ServiceTemplate, and let c be a capability offered bya NodeType instantiated in S. Let r1, . . . , rn be the requirements exposed by thenodes in S such that b(c, S) = {r1, . . . , rn}. The controller of c is an open Petrinet Zc = 〈Pc, Ic〉, with Pc = 〈Pc, Tc, •·, ·•〉, defined as follows.

– The set Pc of places contains a separate place for the capability c and foreach requirement r1, . . . , rn.

– The set Ic coincides with Pc.– The set Tc contains only two Petri net transitions c↑ and c↓.• The input and output places of c↑ are the place c and the places r1, . . . , rn,respectively (i.e., •c↑ = {c} and c↑• = {r1, . . . , rn}).

• The input and output places of c↓ are the places r1, . . . , rn and the placec, respectively (i.e., •c↑ = {r1, . . . , rn} and c↑• = {c}).

The initial marking of Zc is empty (i.e., no place contains a token).

An example of controller (for a capability c connected to two requirements r1and r2) is illustrated in Fig. 6.

Fig. 6. Example of capability controller.

We can now compose the nets modelling the management protocols of the Node-Types instantiated in a ServiceTemplate’s topology by interconnecting themwith the above introduced controllers. The composition is quite simple: We justcollapse the open places corresponding to the same requirements/capabilities.


Definition 8. Let S be a ServiceTemplate. We encode S with an open Petrinet ZS = 〈PS , IS〉, where PS = 〈PS , TS , •·, ·•〉, as follows.

– For each node N in the topology of S, we encode its management protocolwith an open Petri net ZN obtained as shown in Def. 5.

– For each capability c exposed by a NodeTemplate in S, we create an openPetri net Zc (acting as its controller) as shown in Def. 7.

– We then compose the above mentioned nets by taking their disjoint unionand merging the places denoting the same requirement r or capability c.

The initial marking of ZS is the union of the markings of the collapsed nets.

For example, Fig. 7 shows the net obtained for the motivating scenario in Sect. 3.

The Petri net encoding of the management of a ServiceTemplate S, permitsus defining what is a valid plan according to such management. Essentially,thanks to the encoding of capability controllers and to the way we composethese controllers with management protocol encodings, the obtained net ensuresthat no requirement can be assumed to hold if the corresponding capabilityis not provided, and that no capability can be removed if at least one of thecorresponding requirements is assumed to hold. This permits to consider a planvalid if and only if it corresponds to a firing sequence in the net encoding of S.

Definition 9. Let S be a ServiceTemplate and let ZS = 〈PS , IS〉, with PS =〈PS , TS , •·, ·•〉, be the Petri net encoding of S. A sequential plan3 o1o2 . . . om isvalid if and only if there is a firing sequence t1t2 . . . tn in ZS from the initialmarking such that o1 · o2 · . . . · om = λ(t1) ·λ(t2) · . . . ·λ(tn), where · indicates theconcatenation operator4 and:

λ(t) =

{ε if t denotes a c↑ or c↓transitiono if t denotes a management protocol transition 〈s,H, o, s′〉

It is easy to see now that plan (c) of Fig. 3 is valid since, for instance,

AmazonEC2:Start Container↑ Ubuntu:Install Ubuntu:Start SoftwareContainer↑Tomcat:Setup Tomcat:Run Tomcat:Configure WebAppRuntime↑ SendSMS:DeploySendSMS:Start Forex:Deploy Forex:Start

is a corresponding firing sequence for the Petri net in Fig. 7. Conversely, plans(a) and (b) in Fig. 3 are not valid as there are no corresponding firing sequences.Intuitively speaking, (a) is not valid since after firing, for instance,

AmazonEC2:Start Container↑ Ubuntu:Install Ubuntu:Start SoftwareContainer↑Tomcat:Setup

3 In Def. 9 we consider sequential plans. A workflow plan is valid if and only if all itssequential traces are valid.

4 The empty string ε is the neutral element of ·, hence controllers’ net transitions areignored (as λ(t) = ε when t denotes a c↑ or c↓ transition).


Fig. 7. Petri net encoding for the motivating scenario in Sect. 3.


transition Tomcat:Configure cannot be fired. It indeed requires a token in theWorking place, but that place is empty and it is not possible to add tokens to itwithout firing Tomcat:Run. On the other hand, (b) is not valid since after firing

AmazonEC2:Start Container↑ Ubuntu:Install

transition Tomcat:Setup cannot fire. It requires a token in the place denoting theServerContainer requirement, but that place is empty and it is not possible toadd tokens to it without firing SoftwareContainer↑, which in turn cannot fireas it misses a token in the place denoting the Ubuntu’s SoftwareContainer ca-pability (and no token can be added to such place without firing Ubuntu:Start).

It is important to observe that the correspondence between firing sequencesand valid plans can be exploited for many other purposes besides checking plans’validity. The effects of a plan on the states of the components of a TOSCAServiceTemplate, as well as on the requirements that are satisfied and the ca-pabilities that are available, can be directly determined from the marking thatis reached performing the corresponding firing sequence. Additionally, variousclassical notions in the Petri net context assume a specific meaning in the con-text of TOSCA applications. For example the problem of finding whether thereis a plan which achieves a specific goal (e.g., bringing some components of an ap-plication to specific states or making some capabilities available) can be reducedin a straightforward way to the coverability problem [18] on the associated Petrinet. Moreover, it is possible to consider as initial marking any other (reachable)marking so as to analyse maintenance plans (starting from non-initial states)besides deployment plans. Obviously, the very same properties and techniquesalso apply in this case. Finally, the Petri net is reversible [18] if and only if it isalways possible to (softly) reset the application. This is a very convenient prop-erty, because it guarantees that it is always possible to generate a plan for anyreachable goal from any application state.

5 Related work

Automating application management is a well-known problem in computer sci-ence. With the advent of cloud computing, it has become even more prominentbecause of the complexity of both applications and platforms [8]. This is wit-nessed by the proliferation of so-called configuration management systems, likeChef [9] or Puppet [21]. These systems provide a domain-specific language tomodel the desired configuration for a machine and employ a client-server modelin which a server holds the model and the client ensures this configuration is met.However, the lack of a machine readable representation of management protocolsof application components inhibits the possibility of automating verification oncomponents’ configurations and dependencies.

A large body of research has been devoted to model interacting systemsby means of finite state machines, Petri nets, and other formal models [4,11].Because of space limitations, we discuss next only the work more closely relatedto ours, tailored to to model the behaviour of cloud application management.


A first attempt to master the complexity of the cloud is given by the Aeo-lus component model [10]. The Aeolus model is specifically designed to describeseveral characteristics of cloud application components (e.g., dependencies, non-functional requirements, etc.), as well as the fact that component interfaces mightvary depending on the internal component state. However, the model only al-lows to specify what is offered and required in a state. Our approach insteadallows developers to clearly separate the requirements ensuring the consistencyof a state from those constraining the applicability of a management operation.This allows developers to easily express transitions where requirements are af-fecting only the applicability of an operation and not the consistency of a state(e.g., the transition 〈Unavailable, {ServerContainer}, Setup, Stopped〉 of themanagement protocolMS in Fig. 4). Such a kind of transitions cannot be easilymodelled in Aelous. Furthermore, Aelous and other emerging solutions like Juju[13] and Engage [12], differ from our approach since they are geared towardsthe deployment of cloud applications, thus not including also their maintenance.Additionally, Aelous, Juju, and Engage are currently not integrated with anycloud interoperability standard, thus limiting their applicability to only somesupported cloud platforms. Our approach, instead, intends to model the entirelifecycle of a cloud application component, and achieves cloud interoperabilityby relying on the TOSCA standard [19].

To this end, TOSCA offers a rich type system permitting to match, adapt andreuse existing solutions [7]. Since our proposal extends this type system, it canalso be exploited to refine existing reuse techniques, like [5,6,22]. Currently, thesetechniques are matchmaking and adapting (fragments of) existing Service-Templates to implement a desired NodeType by checking whether the featuresof the latter are all offered by the former. To overcome syntactic differences,ontologies may be employed to check whether two different names are denotingthe same concept. However, these techniques are behaviour-unaware: There is noway to determine whether the behaviour of the identified (fragment of) Service-Template is coherent with that of the desired NodeType. Since our approachpermits describing the behaviour of management operations, it can be exploitedto extend the aforementioned techniques to become behaviour-aware.

It is also worth highlighting that we could directly compose the finite statemachines specifying management protocols, and model valid plans as the lan-guage accepted by the composite finite state machine. However, the size of thelatter grows exponentially with the number of application components. This re-sults in a high computational complexity, even if we exploit composition-orientedautomata (e.g., interface automata [1]). On the other hand, with open Petri nets[2,14], we have a very simple composition approach, and the exponential growthonly affects the amount of reachable markings (instead of the size of the net). Asimpler composition approach is even more convenient since cloud applicationscan change over time. For instance, to add another web service to our motivat-ing scenario, our approach just requires to add the open Petri net encoding itsmanagement protocol, and to connect the open places denoting its requirementwith the corresponding c↑ and c↓ transitions. On the other hand, with an au-


tomata based approach, the composition would be much harder, as it requiresto compute the Cartesian product of the automatons’ states.

6 Conclusions

In this paper we have proposed an extension of TOSCA that permits to specifythe behaviour of management operations of cloud-based applications, and theirrelations with states, requirements, and capabilities. We have then shown howthe management protocols of TOSCA components can be naturally modelled, ina compositional way, by means of open Petri nets, and that such modelling per-mits to automate different analyses, such as determining whether a plan is valid,which are its effects, or which plans allow to reach certain system configurations.

Please note that, while some of those Petri-net analyses have an exponentialtime complexity in the worst case, they still constitute a significant improvementwith respect to the state of the art, where the validity of deployment plans can beverified only manually, after delving through the documentation of applicationcomponents. Please also note that our approach builds on top of, but is notlimited to, TOSCA. It can be easily adapted to other stateful behaviour modelsof systems that describe states, requirements, capabilities, and operations.

We see different possible extensions of our work. We are currently workingon a prototype implementation of our approach, which includes a graphical userinterface to support the definition of valid TOSCA specifications that includemanagement protocols. The graphical user interface will compile the manage-ment protocols of a TOSCA application into a PNML file [3], hence enabling toplug-in different PNML processing environments (e.g., LoLa, ProM, or WoPeD,just to mention some) to implement the analyses described in Sect. 4.3. We alsointend to improve the efficiency of the analyses by reducing the complexity ofthe nets that is due to the c↑ and c↓ transitions introduced by the controllers.Indeed the net encoding of a cloud application can be simplified by “folding"the controllers’ transitions (by modifying the transitions whose input/outputplaces contain a place representing capability c so that they are replaced by theplaces representing the requirements connected to c by means of Relationship-Templates). Another interesting direction for future work is to investigate theapplicability of more sophisticated fault diagnosis analyses (like [16,17]) to iden-tify the reasons why a plan may not be valid (besides just showing the pointsin which a plan may get stuck, as we currently do). Finally, we want to extendthe matchmaking and adaptation techniques we previously proposed [5,6,22] byincluding the behaviour information coming from management protocols (as il-lustrated in Sect. 5).

References

1. de Alfaro, L., Henzinger, T.A.: Interface automata. In: Proceedings of the 8thEuropean Software Engineering Conference / 9th ACM SIGSOFT InternationalSymposium on Foundations of Software Engineering. pp. 109–120. ESEC/FSE-9,ACM (2001)


2. Baldan, P., Corradini, A., Ehrig, H., Heckel, R.: Compositional semantics for openPetri nets based on deterministic processes. Mathematical Structures in ComputerScience 15(01), 1–35 (2005)

3. Billington, J., Christensen, S., Van Hee, K., Kindler, E., Kummer, O., Petrucci,L., Post, R., Stehno, C., Weber, M.: The Petri Net Markup Language: Concepts,technology, and tools. In: Proceedings of the 24th International Conference onApplications and Theory of Petri Nets. pp. 483–505. ICATPN’03, Springer (2003)

4. Bochmann, G.V., Sunshine, C.A.: A survey of formal methods. In: Computer Net-work Architectures and Protocols, pp. 561–578. Applications of CommunicationsTheory, Springer (1982)

5. Brogi, A., Soldani, J.: Matching cloud services with TOSCA. In: Advances inService-Oriented and Cloud Computing, CCIS, vol. 393, pp. 218–232. Springer(2013)

6. Brogi, A., Soldani, J.: Reusing cloud-based services with TOSCA. In: INFOR-MATIK 2014. LNI, vol. 232, pp. 235–246. Gesellschaft für Informatik (GI) (2014)

7. Brogi, A., Soldani, J., Wang, P.: TOSCA in a Nutshell: Promises and Perspectives.In: Villari, M., Zimmermann, W., Lau, K.K. (eds.) Service-Oriented and CloudComputing. LNCS, vol. 8745, pp. 171–186. Springer (2014)

8. Buyya, R., Yeo, C.S., Venugopal, S., Broberg, J., Brandic, I.: Cloud computingand emerging IT platforms: Vision, hype, and reality for delivering computing asthe 5th utility. Future Generation Computer Systems 25(6), 599 – 616 (2009)

9. Chef: Opscode. https://www.opscode.com/chef10. Di Cosmo, R., Mauro, J., Zacchiroli, S., Zavattaro, G.: Aeolus: A component model

for the cloud. Information and Computation 239(0), 100 – 121 (2014)11. Diaz, M.: Modeling and analysis of communication and cooperation protocols using

Petri net based models. Computer Networks 6(6), 419 – 441 (1982)12. Fischer, J., Majumdar, R., Esmaeilsabzali, S.: Engage: A deployment management

system. In: Proceedings of the 33rd ACM SIGPLAN Conference on ProgrammingLanguage Design and Implementation. pp. 263–274. PLDI ’12, ACM (2012)

13. Juju: DevOps distilled. https://juju.ubuntu.com14. Kindler, E.: A compositional partial order semantics for Petri net components. In:

Proceedings of ICATPN ’97. pp. 235–252. Springer-Verlag (1997)15. Kopp, O., Binz, T., Breitenbücher, U., Leymann, F.: Winery – Modeling Tool

for TOSCA-based Cloud Applications. In: Proceedings of the 11th InternationalConference on Service-Oriented Computing. Springer (2013)

16. Lohmann, N.: Why does my service have no partners? In: Bruni, R., Wolf, K. (eds.)Web Services and Formal Methods, LNCS, vol. 5387, pp. 191–206. Springer (2009)

17. Lohmann, N., Fahland, D.: Where did I go wrong? In: Business Process Manage-ment, LNCS, vol. 8659, pp. 283–300. Springer (2014)

18. Murata, T.: Petri nets: Properties, analysis and applications. Proceedings of theIEEE 77(4), 541–580 (1989)

19. OASIS: Topology and Orchestration Specification for Cloud Applications. http:

//docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.pdf (2013)20. OASIS: TOSCA Simple Profile in YAML. http://docs.oasis-open.org/tosca/

TOSCA-Simple-Profile-YAML/v1.0/TOSCA-Simple-Profile-YAML-v1.0.pdf (2014)21. Puppet: Puppet labs. https://puppetlabs.com22. Soldani, J., Binz, T., Breitenbücher, U., Leymann, F., Brogi, A.: TOSCA-MART:

A method for adapting and reusing cloud applications. Tech. Rep., University ofPisa (March 2015), http://eprints.adm.unipi.it/2331/1/SBBLB15_-_TR.pdf


modelling the behaviour of management operations in cloud

Documents