Skip to main content

A Petri Net-Based Approach to Model and Analyze the Management of Cloud Applications

  • Chapter
  • First Online:
Transactions on Petri Nets and Other Models of Concurrency XI

Part of the book series: Lecture Notes in Computer Science ((TOPNOC,volume 9930))

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.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 39.99
Price excludes VAT (USA)
  • Available as EPUB and PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 54.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Notes

  1. 1.

    A more detailed and self-contained introduction to TOSCA can be found in [10].

  2. 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. 3.

    A more detailed syntax for extended NodeTypes can be found in [7].

  4. 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. 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. 6.

    A more detailed discussion on existing approaches exploiting Petri nets for protocol engineering can be found in [13].

References

  1. de Alfaro, L., Henzinger, T.A.: Interface automata. In: Proceedings of ESEC/FSE-9, pp. 109–120. ACM (2001)

    Google Scholar 

  2. 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)

    Article  MathSciNet  MATH  Google Scholar 

  3. 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)

    Article  Google Scholar 

  4. 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)

    Google Scholar 

  5. 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)

    Chapter  Google Scholar 

  6. 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

    Chapter  Google Scholar 

  7. Brogi, A., Canciani, A., Soldani, J.: Modelling the behaviour of management operations in TOSCA. Technical report, University of Pisa, July 2015

    Google Scholar 

  8. 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)

    Google Scholar 

  9. 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)

    Google Scholar 

  10. 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)

    Google Scholar 

  11. 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)

    Article  Google Scholar 

  12. 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)

    Chapter  Google Scholar 

  13. Cheung, T.Y.: Petri nets for protocol engineering. Comput. Commun. 19(14), 1250–1257 (1996)

    Article  Google Scholar 

  14. Courtiat, J.P., Ayache, J.M., Algayres, B.: Petri nets are good for protocols. SIGCOMM Comput. Commun. Rev. 14(2), 66–74 (1984)

    Article  Google Scholar 

  15. Cosmo, R., Mauro, J., Zacchiroli, S., Zavattaro, G.: Aeolus: a component model for the cloud. Inf. Comput. 239, 100–121 (2014)

    Article  MathSciNet  MATH  Google Scholar 

  16. Diaz, M.: Modeling and analysis of communication and cooperation protocols using Petri net based models. Comput. Netw. 6(6), 419–441 (1982)

    MATH  Google Scholar 

  17. Fischer, J., Majumdar, R., Esmaeilsabzali, S.: Engage: a deployment management system. In: Proceedings of PLDI 2012, pp. 263–274. ACM (2012)

    Google Scholar 

  18. 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)

    Chapter  Google Scholar 

  19. 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)

    Chapter  Google Scholar 

  20. 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)

    Chapter  Google Scholar 

  21. 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)

    Google Scholar 

  22. Morgan, E.T., Razouk, R.R.: Interactive state-space analysis of concurrent systems. IEEE Trans. Software Eng. 10, 1080–1091 (1987)

    Article  Google Scholar 

  23. Murata, T.: Petri nets: properties, analysis and applications. Proc. IEEE 77(4), 541–580 (1989)

    Article  Google Scholar 

  24. OASIS: Topology and Orchestration Specification for Cloud Applications (2013). http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.pdf

  25. 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

  26. Paule, C., Eckert, H.: The NEt Simulation SYstem NESSY: Summary and Example. Ges. fur Mathematik u, Datenverarbeitung (1985)

    Google Scholar 

  27. 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)

    Article  Google Scholar 

Download references

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Jacopo Soldani .

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:

  1. (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}$$
  2. (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}$$
  3. (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.

  1. (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.

  2. (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:

    1. (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')\));

    2. (b)

      c is provided in \(s'\), but it is not provided in s (i.e., \(c \in \gamma (s') - \gamma (s)\));

    3. (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.

    1. (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 )\).

    2. (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)\).

    3. (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.

  3. (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

Reprints 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)

Publish with us

Policies and ethics