How to flexibly manage complex applications over heterogeneous clouds is one of the emerging problems in the cloud era. The OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) aims at solving this problem by providing a language to describe and manage complex cloud applications in a portable, vendoragnostic way. TOSCA permits to define an application as an orchestration of nodes, whose types can specify states, requirements, capabilities and management operations - but not how they interact each another. In this paper we first propose how to extend TOSCA to specify the behaviour of management operations and their relations with states, requirements, and capabilities. We then illustrate how such behaviour can be naturally modelled, in a compositional way, by means of open Petri nets. The proposed modelling permits to automate different analyses, such as determining whether a deployment plan is valid, which are its effects, or which plans allow to reach certain system configurations.
Available cloud technologies permit to run on-demand distributed software systems at a fraction of the cost which was necessary just a few years ago. On the other hand, how to flexibly deploy and manage such applications over heterogeneous clouds is one of the emerging problems in the cloud era.
In this perspective, OASIS recently released the Topology and Orchestration
Specification for Cloud Applications (TOSCA [
Unfortunately, the current specification of TOSCA [
In this paper, we first propose a way to extend TOSCA to specify the behaviour of management operations and their relations with states, requirements, and capabilities. We define how to specify the management protocol of a TOSCA component by means of finite state machines whose states and transitions are associated with conditions on (some of) the component’s requirements and capabilities. Intuitively speaking, those conditions define the consistency of component’s states and constrain the executability of component’s operations to the satisfaction of requirements.
We then illustrate how the management protocols of TOSCA components can
be naturally modelled, in a compositional way, by means of open Petri nets [
The rest of the paper is organized as follows. Sect. 2 introduces the needed background (TOSCA and open Petri nets), while Sect. 3 illustrates a scenario motivating the need for an explicit, machine-readable representation of management protocols. Sect. 4 describes how TOSCA can be extended to specify the behaviour of management operations, how such behaviour can be naturally and compositionally modelled by means of open Petri nets, and how the proposed modelling permits to automate different types of analysis. Related work is discussed in Sect. 5, while some concluding remarks are drawn in Sect. 6. 2 2.1
TOSCA [
The TopologyTemplate is a typed directed graph that describes the topological 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 and RelationshipTemplates are typed by means of NodeTypes and RelationshipTypes, respectively. A NodeType defines (i) the observable properties of an application component C, (ii) the possible states of its instances, (iii) the requirements needed by C, (iv) the capabilities offered by C to satisfy other components’ requirements, and (v) the management operations of C. RelationshipTypes describe the properties of relationships occurring among components. Syntactically, properties are described by PropertiesDefinitions, states by InstanceStates, requirements by RequirementDefinitions (of certain RequirementTypes), capabilities by CapabilityDefinitions (of certain CapabilityTypes), and operations by Interfaces and Operations.
On the other hand, Plans enable the description of application deployment and/or management aspects. Each Plan is a workflow that orchestrates the operations offered by the application components (i.e., NodeTemplates) to address (part of) the management of the whole cloud application1.
Before providing a formal definition of open Petri nets (Def. 2), we recall the
definition of Petri nets just to introduce the employed notation. We instead omit
to recall other very basic notions about Petri nets (e.g., marking of a net, firing
of transitions, etc.) as they are well-know and easy to find in literature [
According to [
Consider a developer who wants to deploy and manage the web services
SendSMS and Forex on a TOSCA-compliant cloud platform. She first describes her
services 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 a
Tomcat server installed on an Ubuntu operating system, which in turn runs on an
AmazonEC2 virtual machine. Fig. 2 illustrates the resulting TopologyTemplate,
according to the Winery graphical notation [
Suppose that the developer wants to describe the automation of the deployment of the SendSMS and Forex services by writing a TOSCA Plan. Since TOSCA 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. plan. The other Plans cannot be considered valid since (a) Tomcat’s Configure operation cannot be executed before Tomcat is running, and (b) Tomcat cannot be installed when the Ubuntu operating system is not running.
While the validity of Plans can be manually verified, this is a time-consuming and error-prone process. In order to enable the automated verification of the validity of Plans, TOSCA should be extended so as to permit specifying the behaviour of and the relations among NodeTypes’ management operations. 4
While a TOSCA NodeType can be described by means of its states, requirements, capabilities, and management operations, there is currently no way to specify how management operations affect states, how operations or states depend on requirements, or which capabilities are concretely provided in a certain state.
The objective of the next section is precisely to propose a way to extend TOSCA to specify the behaviour of management operations and their relations with states, requirements, and capabilities. 4.1
Let N be a TOSCA NodeType, and let us denote its states, requirements, capabilities, and management operations with SN , RN , CN , and ON , respectively.
We want to permit describing whether and how the management operations of N depend on other operations of the same node as well as on operations of the other nodes providing the capabilities that satisfy the requirements of N . – The first type of dependencies can be easily described by specifying the relationship between states and management operations of N . More precisely, the order with which the operations of N can be executed can be described by means of a transition relation T , that specifies whether an operation o can 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 transitions and states with (possibly empty) sets of requirements to indicate that the corresponding capabilities are assumed to be provided. More precisely, the requirements associated with a transition t specify which are the capabilities that must be offered by other nodes to allow the execution of t. The requirements associated with a state of a NodeType N specify which are the capabilities that must (continue to) be offered by other nodes in order for N to (continue to) work properly.
To complete the description, each state s of a NodeType N also specifies the capabilities provided by N in s.
Definition 3. Let N = hSN , RN , CN , ON , MN i be a NodeType, where SN , RN , CN , and ON are the sets of its states, requirements, capabilities, and management operations. MN = hs, R, C, T i 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 requirements 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., hs, H, o, s0i ∈ T means that in state s, and if condition H holds, o is executable and leads to state s0).
Syntactically, to describe MN we slightly extend the syntax for describing a TOSCA NodeType. Namely, we enrich the description of an InstanceState by introducing the nested elements ReliesOn and Offers. ReliesOn defines R (of Def. 3) by enabling the association between states and assumed requirements, while Offers defines C by indicating the capabilities offered in a state. Furthermore, we introduce the element ManagementProtocol, which allows to specify the InitialState s of the protocol, as well as the Transitions defining the transition relation T .
The management protocols of the NodeTypes in the motivating scenario of Sect. 3 are shown in Fig. 4, where MWS is the management protocol for WebServices, MS for Server, MOS for OperatingSystem, and MVM for VirtualMachine. Consider for instance the management protocol MS of NodeType MWS
MS
MOS
MVM Server defining the Tomcat server. Its states SN are Unavailable (initial state), Stopped, and Working, the only requirement in RN is ServerContainer, the only capability in CN is WebAppRuntime, and its management operations are Setup, Uninstall, Run, Stop, and Configure. States Unavailable and Stopped are not associated with any requirement or capability. State Working instead 2 Without loss of generality, we assume that the initial state of a management protocol has no requirements and does not provide any capability. specifies that the capability corresponding to the ServerContainer requirement must be provided (by some other node) in order for Server to (continue to) work properly. State Working also specifies that Server provides the WebAppRuntime capability when in such state. Finally, all transitions (but those involving operations Stop and Configure) constrain their firability by requiring the capability that satisfies ServerContainer to be offered (by some other node).
Note that Def. 3 permits to define operations that have non-deterministic
effects when applied in a state (e.g., a state can have two outgoing transitions
corresponding to the same operation and leading to different states). This form of
non-determinism is not acceptable in the management of a TOSCA application
[
∀hs1, H1, o1, s01i, hs2, H2, o2, s02i ∈ T : s1 = s2 ∧ o1 = o2 ⇒ s01 = s02 4.2
A (deterministic) management protocol MN of a NodeType N can be easily encoded by an open Petri net. Each state of MN is mapped into an internal place of the Petri net, and each capability and requirement of N is mapped into an open place of the same net. Furthermore, each transition hs, H, o, s0i of MN 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 are needed but not already available in s (i.e., (R(s0) ∪ H) − R(s)), and the capabilities that are provided in s but not in s0 (i.e., C(s) − C(s0)). (ii) The output places of t are the places denoting s0, the requirements that were needed but are no more assumed to hold in s0 (i.e., (R(s)∪H)−R(s0)), and the capabilities that are provided in s0 but not in s (i.e., C(s0) − C(s)). The initial marking of the obtained net prescribes that the only place initially containing a token is that corresponding to the initial state s of MN . Definition 5. Let N = hSN , RN , CN , ON , MN i be a NodeType, with MN = hs, R, C, T i. The management protocol MN is encoded into an open net ZN = hPN , IN i, with PN = hPN , TN , •·, ·•i and IN ⊆ PN , as follows.
– The set PN of places contains a separate place for each state in SN , for each requirement in RN , and for each capability in CN . – The set IN ⊂ PN of open places contains the places denoting the requirements in RN and the capabilities in CN . – The set TN contains a net transition t for each transition hs, H, o, s0i ∈ T . (i) The set •t of input places contains the place s, the places denoting the requirements in (R(s0) ∪ H) − R(s), and those denoting the capabilities in C(s) − C(s0). (ii) The set t• of output places contains the place s0, the places denoting the requirements in (R(s) ∪ H) − R(s0), and those denoting the capabilities in C(s0) − C(s).
The above definition ensures that the Petri net encoding of a management protocol satisfies the following properties: – There is a one-to-one correspondence between the marking of the internal places 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 requirements are available in the source state, and no capability required by any connected component is disabled in the target state.
Consider for instance the management protocol MS (Fig. 4), whose corresponding Petri net is shown in Fig. 5. Each state in MS is translated into an internal place (represented as a circle), while the ServerContainer requirement and the WebAppRuntime capability are translated into open places (represented as diamonds). Additionally, protocol transitions are translated into net transitions. For example, the transition hStopped, {ServerContainer}, Run, Workingi is translated into a Petri net transition, whose inputs places are Stopped and ServerContainer, and whose outputs places are Working and WebAppRuntime.
We now show how the Petri net modelling the management protocol of a TOSCA TopologyTemplate (specifying a whole cloud-based application) can be obtained, in a compositional way, from the Petri nets modelling the management protocols of the NodeTypes in such TopologyTemplate.
We first need to model (by open Petri nets working as a capability controllers) the RelationshipTemplates that define in a TopologyTemplate the association between the requirements of a NodeTypes and the capabilities of other NodeTypes. To do that, we first define an utility binding function that returns the set of requirements with which a capability is associated. Definition 6. Let S be a ServiceTemplate, and let c be a capability offered by a NodeType in S. We define b(c, S) = {r1, . . . , rn}, where r1, . . . , rn are the requirements connected to c in S by means of RelationshipTemplates. We now exploit function b to define capability controllers. On the one hand, the controller must ensure that once a capability c is available, the nodes exposing the connected requirements r1, . . . , rn are able to simultaneously exploit it. This is obtained by adding a transition c↑ able to propagate the token from place c to places r1, . . . , rn (i.e., the input place of c↑ is c, and its output places are r1, . . . , rn). On the other hand, the controller has also to ensure that the capability is not removed while at least another node is actively assuming its availability (with a condition on a connected requirement). Thus, we introduce a 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 by a NodeType instantiated in S. Let r1, . . . , rn be the requirements exposed by the nodes in S such that b(c, S) = {r1, . . . , rn}. The controller of c is an open Petri net Zc = hPc, Ici, with Pc = hPc, Tc, •·, ·•i, defined as follows.
– The set Pc of places contains a separate place for the capability c and for each 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 place c, respectively (i.e., •c↑ = {r1, . . . , rn} and c↑• = {c}).
An example of controller (for a capability c connected to two requirements r1 and r2) is illustrated in Fig. 6.
We can now compose the nets modelling the management protocols of the NodeTypes instantiated in a ServiceTemplate’s topology by interconnecting them with the above introduced controllers. The composition is quite simple: We just collapse the open places corresponding to the same requirements/capabilities. Definition 8. Let S be a ServiceTemplate. We encode S with an open Petri net ZS = hPS, ISi, where PS = hPS, TS, •·, ·•i, as follows.
– For each node N in the topology of S, we encode its management protocol with an open Petri net ZN obtained as shown in Def. 5. – For each capability c exposed by a NodeTemplate in S, we create an open
Petri net Zc (acting as its controller) as shown in Def. 7. – We then compose the above mentioned nets by taking their disjoint union and 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, permits us defining what is a valid plan according to such management. Essentially, thanks to the encoding of capability controllers and to the way we compose these controllers with management protocol encodings, the obtained net ensures that no requirement can be assumed to hold if the corresponding capability is not provided, and that no capability can be removed if at least one of the corresponding requirements is assumed to hold. This permits to consider a plan valid 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 = hPS, ISi, with PS = hPS, TS, •·, ·•i, be the Petri net encoding of S. A sequential plan3 o1o2 . . . om is valid if and only if there is a firing sequence t1t2 . . . tn in ZS from the initial marking such that o1 · o2 · . . . · om = λ(t1) · λ(t2) · . . . · λ(tn), where · indicates the concatenation operator4 and: λ(t) = (
if t denotes a c↑ or c↓transition o if t denotes a management protocol transition hs, H, o, s0i 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:Deploy SendSMS: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 its sequential traces are valid. 4 The empty string is the neutral element of ·, hence controllers’ net transitions are ignored (as λ(t) = when t denotes a c↑ or c↓ transition). transition Tomcat:Configure cannot be fired. It indeed requires a token in the Working place, but that place is empty and it is not possible to add tokens to it without 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 the ServerContainer requirement, but that place is empty and it is not possible to add tokens to it without firing SoftwareContainer↑, which in turn cannot fire as it misses a token in the place denoting the Ubuntu’s SoftwareContainer capability (and no token can be added to such place without firing Ubuntu:Start).
It is important to observe that the correspondence between firing sequences
and 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 TOSCA
ServiceTemplate, as well as on the requirements that are satisfied and the
capabilities that are available, can be directly determined from the marking that
is reached performing the corresponding firing sequence. Additionally, various
classical notions in the Petri net context assume a specific meaning in the
context of TOSCA applications. For example the problem of finding whether there
is a plan which achieves a specific goal (e.g., bringing some components of an
application to specific states or making some capabilities available) can be reduced
in a straightforward way to the coverability problem [
Automating application management is a well-known problem in computer
science. With the advent of cloud computing, it has become even more prominent
because of the complexity of both applications and platforms [
A large body of research has been devoted to model interacting systems
by means of finite state machines, Petri nets, and other formal models [
A first attempt to master the complexity of the cloud is given by the
Aeolus component model [
To this end, TOSCA offers a rich type system permitting to match, adapt and
reuse existing solutions [
It is also worth highlighting that we could directly compose the finite state
machines specifying management protocols, and model valid plans as the
language accepted by the composite finite state machine. However, the size of the
latter grows exponentially with the number of application components. This
results in a high computational complexity, even if we exploit composition-oriented
automata (e.g., interface automata [
In this paper we have proposed an extension of TOSCA that permits to specify the behaviour of management operations of cloud-based applications, and their relations with states, requirements, and capabilities. We have then shown how the management protocols of TOSCA components can be naturally modelled, in a compositional way, by means of open Petri nets, and that such modelling permits 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 exponential time complexity in the worst case, they still constitute a significant improvement with respect to the state of the art, where the validity of deployment plans can be verified only manually, after delving through the documentation of application components. Please also note that our approach builds on top of, but is not limited to, TOSCA. It can be easily adapted to other stateful behaviour models of systems that describe states, requirements, capabilities, and operations.
We see different possible extensions of our work. We are currently working
on a prototype implementation of our approach, which includes a graphical user
interface to support the definition of valid TOSCA specifications that include
management protocols. The graphical user interface will compile the
management protocols of a TOSCA application into a PNML file [