Abstract
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, vendor-agnostic 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.
This work is an extended version of [8]. It has been partly supported by the EU-FP7-ICT-610531 project SeaClouds.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
A more detailed and self-contained introduction to TOSCA can be found in [10].
- 2.
Without loss of generality, we assume that the initial state of a management protocol has no requirements and does not provide any capability.
- 3.
A more detailed syntax for extended NodeTypes can be found in [7].
- 4.
The empty string \(\epsilon \) is the neutral element of \(\cdot \), hence controllers’ net transitions are ignored (as \(\lambda (t)=\epsilon \) when t denotes a \(c_{\uparrow }\) or \(c_{\downarrow }\) transition).
- 5.
A sequential trace for a Plan P is complete if and only if its first and last operation correspond to an initial and to a final activity of P.
- 6.
A more detailed discussion on existing approaches exploiting Petri nets for protocol engineering can be found in [13].
References
de Alfaro, L., Henzinger, T.A.: Interface automata. In: Proceedings of ESEC/FSE-9, pp. 109–120. ACM (2001)
Baldan, P., Corradini, A., Ehrig, H., Heckel, R.: Compositional semantics for open Petri nets based on deterministic processes. Math. Struct. Comput. Sci. 15(01), 1–35 (2005)
Billington, J., Wheeler, G.R., Wilbur-Ham, M.C.: PROTEAN: a high-level petri net tool for the specification and verification of communication protocols. IEEE Trans. Softw. Eng. 14(3), 301–316 (1988)
Billington, J., et al.: The petri net markup language: concepts, technology, and tools. In: van der Aalst, W.M.P., Best, E. (eds.) ICATPN 2003. LNCS, vol. 2679, pp. 483–505. Springer, Heidelberg (2003)
Bochmann, G.V., Sunshine, C.A.: A survey of formal methods. In: Green Jr., P.E. (ed.) Computer Network Architectures and Protocols. Applications of Communications Theory, pp. 561–578. Springer, Heidelberg (1982)
Brogi, A., Canciani, A., Soldani, J.: Modelling and analysing cloud application management. In: Dustdar, S., Leymann, F., Villari, M. (eds.) ESOCC 2015. LNCS, vol. 9306, pp. 19–33. Springer, Heidelberg (2015). http://dx.doi.org/10.1007/978-3-319-24072-5_2
Brogi, A., Canciani, A., Soldani, J.: Modelling the behaviour of management operations in TOSCA. Technical report, University of Pisa, July 2015
Brogi, A., Canciani, A., Soldani, J., Wang, P.: Modelling the behaviour of management operations in cloud-based applications. In: Moldt, D. (ed.) Proceedings of the International Workshop on Petri Nets and Software Engineering (PNSE 2015), CEUR Workshop Proceedings, vol. 1372, pp. 191–205. CEUR-WS.org (2015)
Brogi, A., Soldani, J.: Finding available services in TOSCA-compliant clouds. Science of Computer Programming 115–116, 177–198, Special Section on Foundations of Coordination Languages and Software (FOCLASA 2012), Special Section on Foundations of Coordination Languages and Software (FOCLASA 2013) (2016)
Brogi, A., Soldani, J., Wang, P.W.: TOSCA in a nutshell: promises and perspectives. In: Villari, M., Zimmermann, W., Lau, K.-K. (eds.) ESOCC 2014. LNCS, vol. 8745, pp. 171–186. Springer, Heidelberg (2014)
Buyya, R., Yeo, C.S., Venugopal, S., Broberg, J., Brandic, I.: Cloud computing and emerging IT platforms: vision, hype, and reality for delivering computing as the 5th utility. Future Gener. Comput. Syst. 25(6), 599–616 (2009)
Cheng, A., Esparza, J., Palsberg, J.: Complexity results for 1-safe nets. In: Shyamasundar, R.K. (ed.) FSTTCS 1993. LNCS, vol. 761, pp. 326–337. Springer, Heidelberg (1993)
Cheung, T.Y.: Petri nets for protocol engineering. Comput. Commun. 19(14), 1250–1257 (1996)
Courtiat, J.P., Ayache, J.M., Algayres, B.: Petri nets are good for protocols. SIGCOMM Comput. Commun. Rev. 14(2), 66–74 (1984)
Cosmo, R., Mauro, J., Zacchiroli, S., Zavattaro, G.: Aeolus: a component model for the cloud. Inf. Comput. 239, 100–121 (2014)
Diaz, M.: Modeling and analysis of communication and cooperation protocols using Petri net based models. Comput. Netw. 6(6), 419–441 (1982)
Fischer, J., Majumdar, R., Esmaeilsabzali, S.: Engage: a deployment management system. In: Proceedings of PLDI 2012, pp. 263–274. ACM (2012)
Kindler, E.: A compositional partial order semantics for Petri net components. In: Azéma, P., Balbo, G. (eds.) ICATPN 1997. LNCS, vol. 1248, pp. 235–252. Springer, Heidelberg (1997)
Kopp, O., Binz, T., Breitenbücher, U., Leymann, F.: Winery - modeling tool for TOSCA-based cloud applications. In: Basu, S., Pautasso, C., Zhang, L., Fu, X. (eds.) ICSOC 2013. LNCS, vol. 8274, pp. 700–704. Springer, Heidelberg (2013)
Lohmann, N.: Why does my service have no partners? In: Bruni, R., Wolf, K. (eds.) WS-FM 2008. LNCS, vol. 5387, pp. 191–206. Springer, Heidelberg (2009)
Lohmann, N., Fahland, D.: Where did i go wrong? In: Sadiq, S., Soffer, P., Völzer, H. (eds.) BPM 2014. LNCS, vol. 8659, pp. 283–300. Springer, Heidelberg (2014)
Morgan, E.T., Razouk, R.R.: Interactive state-space analysis of concurrent systems. IEEE Trans. Software Eng. 10, 1080–1091 (1987)
Murata, T.: Petri nets: properties, analysis and applications. Proc. IEEE 77(4), 541–580 (1989)
OASIS: Topology and Orchestration Specification for Cloud Applications (2013). http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.pdf
OASIS: TOSCA Simple Profile in YAML (2014). http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/TOSCA-Simple-Profile-YAML-v1.0.pdf
Paule, C., Eckert, H.: The NEt Simulation SYstem NESSY: Summary and Example. Ges. fur Mathematik u, Datenverarbeitung (1985)
Soldani, J., Binz, T., Breitenbcher, U., Leymann, F., Brogi, A.: ToscaMart: a method for adapting and reusing cloud applications. J. Syst. Softw. 113, 395–406 (2016)
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Appendix
Appendix
The objective of this appendix is to provide the properties of the Petri net encoding of a ServiceTemplate (see Definition 8) that are needed to prove its safeness (see Proposition 1). First, since each node \(N_i\) in a ServiceTemplate S can be in a unique state, exactly one of the internal places denoting its states contains one token, while the others contain no token. This holds at any given time, and thus in any marking that can be reached from the initial marking of the Petri net encoding of \({\mathcal {Z}}_S\). In short, (i) each internal place of the net encoding a ServiceTemplate contains at most one token. The same holds also for the open places modeling (ii) capabilities and (iii) requirements.
Lemma 1
Let S be a ServiceTemplate and let \({\mathcal {Z}}_S = \langle \mathcal {P}_S, I_S \rangle \), with \(\mathcal {P}_S = \langle P_S, T_S, {\bullet }\cdot , {\cdot \bullet }, M_0 \rangle \), be the Petri net encoding of S. Let also \(M\) be a marking reachable from the initial marking \(M_0\) of \({\mathcal {Z}}_S\). For each node \(N_i = \langle S_{N_i}, R_{N_i}, C_{N_i}, O_{N_i}, \mathcal {M}_{N_i} \rangle \) (with \(\mathcal {M}_{N_i} = \langle \overline{s}, \rho , \gamma , \tau \rangle \)) in S, the following properties hold:
-
(i)
\( \exists s' \in S_{N_i}. M(s') = 1 ~\wedge ~ \forall s \in S_{N_i} . s \ne s' \Rightarrow M(s) = 0 \) or, equivalently:
$$\begin{aligned} \Sigma _{s \in S_{N_i}} M(s) = 1 \end{aligned}$$ -
(ii)
Let s be the current state of a node \(N_i\) (i.e. \(s \in S_{N_i} \wedge M(s)=1\)). For any capability \(c \in C_{N_i}\), the number of tokens in the open places \(r_c\) and c is:
$$\begin{aligned} c \notin \gamma (s)&\Leftrightarrow M(c) + M(r_c) = 0\\ c \in \gamma (s)&\Leftrightarrow M(c) + M(r_c) = 1 \end{aligned}$$ -
(iii)
Let s be the current state of a node \(N_i\) (i.e. \(s \in S_{N_i} \wedge M(s)=1\)). For any requirement \(r \in R_{N_i}\) bound to a capability c (i.e., \(r \in b(c,S)\)), the number of tokens in the open places r and \(r_c\) is:
$$\begin{aligned} r \notin \rho (s)&\Leftrightarrow (M(r) = M(r_c) = 0) \vee (M(r) = M(r_c) = 1)\\ r \in \rho (s)&\Leftrightarrow M(r) = 0 \wedge M(r_c) = 1 \end{aligned}$$
Proof
The proofs for (i), (ii), and (iii) are listed below.
-
(i)
For each node \(N_i\), the places denoting its states are internal to \({\mathcal {Z}}_S\). Hence, their input and output transitions are not changed by the merge process, which in turn means that only the net transitions (encoding the protocol transitions) of the same node \(N_i\) can add/remove tokens to/from them. By construction, the above mentioned transitions always input exactly one token from an internal place and output exactly one token to an internal place (potentially the same). This guarantees that the total number of tokens in the internal places of a single node cannot change:
$$\begin{aligned} \Sigma _{s \in S_{N_i}} M(s) = \Sigma _{s \in S_{N_i}} M'(s), \end{aligned}$$where \(M'\) is a marking reached by firing a transition in \(M\). The above, along with the fact that the initial marking \(M_0\) of \({\mathcal {Z}}_S\) includes a token only in the places denoting the initial states of the nodes in S (i.e., for each node \(N_i\), \(\Sigma _{s \in S_{N_i}} M_0(s) = 1\)), implies that any sequence of firings starting from the initial marking will preserve exactly one token in the internal places denoting the states of each node.
-
(ii)
First, we show that the property holds in the initial marking \(M_0\) of \({\mathcal {Z}}_S\). According to the definition of management protocols (Definition 3), \(\gamma (\overline{s}) = \varnothing \), which means that (in order for the property to hold) the initial marking \(M_0\) of the open places must be empty (i.e., for each capability c, \(M(c) + M(r_c) = 0\)). This follows from the construction of \({\mathcal {Z}}_S\) (Definition 8), thus the property holds for \(M_0\). Since the property holds for the initial marking, we can prove that it holds for every reachable marking, by showing that no transition can invalidate the property. We will thus consider it as invariant. Consider the capability c of a node \(N_i\). The places mentioned in the property (i.e., c and \(r_c\)) are connected to the \(c_{\uparrow }\) and \(c_{\downarrow }\) transitions, and to the transitions of \(N_i\) that input/output a token to/from c. These are the only transitions that might affect the invariant, since the transitions connected to the requirements managed by the controller of c cannot change the marking of c nor that of \(r_c\). The \(c_{\uparrow }\) and \(c_{\downarrow }\) transitions cannot affect the invariant, since they do not change the total number of tokens in c and \(r_c\). This is because, whenever \(c_{\uparrow }\) fires, it removes one token from c, but it also adds one token to \(r_c\) (and to all of the other \(r_i\) places). Symmetrically, whenever \(c_{\downarrow }\) fires, it removes one token from \(r_c\) (and from each of the other \(r_i\) places), but it also adds one token to c. Thus, the only transitions that might invalidate the invariant are the transitions of the node \(N_i\) that input/output one token to/from c. Since all these transitions move a token from a state s to a state \(s'\), they can be classified as follows:
-
(a)
c is either provided in both s and \(s'\) or in neither of them (i.e., \(c \in \gamma (s) \cap \gamma (s') \vee c \notin \gamma (s) \cup \gamma (s')\));
-
(b)
c is provided in \(s'\), but it is not provided in s (i.e., \(c \in \gamma (s') - \gamma (s)\));
-
(c)
c is provided in s, but it is not provided in \(s'\) (i.e., \(c \in \gamma (s) - \gamma (s')\)).
Each of these cases is consistent with the property that we want to prove.
-
(a)
In the first case, transitions do not affect c at all, as (by construction) they are not even connected to c. They thus preserve the sum \(M(c) + M(r_c)\), as well as the truth value of \(c \in \gamma (\cdot )\).
-
(b)
In the second case, transitions lead to a state \(s'\) such that \(c \in \gamma (s')\), but they also add a token to c. If the invariant held before the transition (i.e., \(M(c) + M(r_c) = 0\) with \(M(s)=1 \wedge c \notin \gamma (s)\)), it also holds after the transition, because the sum becomes \(M(c) + M(r_c) = 1\) with \(M(s')=1 \wedge c \in \gamma (s)\).
-
(c)
The third case is precisely the opposite of the second one, since transitions lead to a state \(s'\) such that \(c \notin \gamma (s')\) and they remove a token from c. If the invariant held before the transition (i.e., \(M(c) + M(r_c) = 1\) with \(M(s)=1 \wedge c \in \gamma (s)\)), then it also holds after the transition. The sum indeed becomes \(M(c) + M(r_c) = 1\) with \(M(s')=1 \wedge c \notin \gamma (s)\).
In conclusion, since the invariant holds for \(M_0\) and none of the transitions can invalidate it, by induction (over the length of a firing sequence) it holds for any reachable marking.
-
(a)
-
(iii)
The proof of the property follows the same line as the one for (ii). Namely, the property can be proved to hold for any reachable marking by induction over the length of a firing sequence, by showing that it holds for the initial marking \(M_0\), and that none of the transitions can invalidate such property.
\(\square \)
Rights and permissions
Copyright information
© 2016 Springer-Verlag Berlin Heidelberg
About this chapter
Cite this chapter
Brogi, A., Canciani, A., Soldani, J., Wang, P. (2016). A Petri Net-Based Approach to Model and Analyze the Management of Cloud Applications. In: Koutny, M., Desel, J., Kleijn, J. (eds) Transactions on Petri Nets and Other Models of Concurrency XI. Lecture Notes in Computer Science(), vol 9930. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-662-53401-4_2
Download citation
DOI: https://doi.org/10.1007/978-3-662-53401-4_2
Published:
Publisher Name: Springer, Berlin, Heidelberg
Print ISBN: 978-3-662-53400-7
Online ISBN: 978-3-662-53401-4
eBook Packages: Computer ScienceComputer Science (R0)