1 Introduction

Cloud applications may comprise many components with different technical dependencies and constraints, making their deployment and ongoing management complicated and error-prone [27]. Also, the interoperability between management tools has become challenging [4]. Thus, the need arose to describe cloud applications and related management tasks on a higher level of abstraction, in a standardized format. To address these issues, the Organization for the Advancement of Structured Information Standards (OASIS) published the Topology and Orchestration Specification for Cloud Applications (TOSCA) standard in 2013 [30]. TOSCA is a modeling language addressing the deployment and portability of applications, and the reusability of application components [2, 13]. The original TOSCA specification was based on XML; the simplified TOSCA profile, released in 2016, used YAML [32].

TOSCA describes (i) the structure of composite cloud applications as topology graphs and (ii) management plans for deploying and maintaining cloud applications. In topology graphs, nodes represent components, which include management operations e.g. for creating, configuring or starting the component [19]. The topology graph also contains relationships between components; e.g., a “hosted-on” relation indicates the allocation of virtual to physical components.

In imperative processing, a Management Plan defines the management operations and their execution order, using a workflow language such as Business Process Model and Notation [31] or Business Process Execution Language [29]. In declarative processing, no Management Plans are defined; instead, a runtime system infers the necessary steps for typical operations (e.g., deployment) from the application topology based on some conventions [5].

TOSCA has played various roles in different research approaches: some used TOSCA as part of a more general methodology, others extended the modeling capabilities of TOSCA or designed tools to manipulate TOSCA models. The multifaceted use of TOSCA and the growing number of relevant papers make it hard to track all related research. The aim of this paper is to give an overview of the use of TOSCA in the research community. We performed a systematic literature survey to devise a taxonomy of the main research topics that have been addressed in connection with TOSCA.

To identify relevant papers, we first used ScopusFootnote 1 with the search string "Topology and Orchestration Specification for Cloud Applications" AND (ABS(tosca) OR TITLE (tosca)). Here, ABS(tosca) OR TITLE (tosca) means that the word TOSCA must be contained in the abstract or title, ensuring that TOSCA is a main aspect of the paper. In addition, we are looking for the full term (Topology and Orchestration Specification for Cloud Applications) to exclude papers that use the word TOSCA in another meaning. We focused on the period 2012–2017, since the first TOSCA papers were published in 2012, and 2017 was the last full year until the time of writing. We found 89 papers. We excluded 6 very short papers (less than 4 pages). Using Google ScholarFootnote 2, we found 8 more papers that were not in Scopus but fit our search string. This led to a total of 91 papers. Afterwards, we read each paper and categorized it using open coding. By continuously refining our coding scheme, we built up a taxonomy in a bottom-up fashion. Finally, we analyzed the results to identify focal points of existing research and directions for further research.

2 Survey Results

Figure 1 presents the taxonomy that we developed based on the analyzed papers. On the highest level, we categorized the papers based on their main contribution regarding TOSCA. We identified the following categories:

  1. 1.

    Tools: papers describing a tool for TOSCA. Further categorization is possible based on the type of tool; in particular, this includes modeling tools, tools for deployment automation, and run-time environments.

  2. 2.

    Extension of language: approaches that extend the TOSCA language. The extension may relate to topologies, Management Plans, or both. Furthermore, extensions aiming at a visual notation also belong to this category.

  3. 3.

    Methodologies for manipulating TOSCA models: papers describing a methodology for processing TOSCA models. The identified sub-categories are: papers about processing TOSCA topology models, approaches that combine declarative and imperative processing, solutions to enforce some given policies, and verification of cloud orchestration.

  4. 4.

    Relation to other solutions: papers about a relation – comparison or conversion – between TOSCA and some other technique.

  5. 5.

    Usage of TOSCA: papers demonstrating the use of TOSCA. This includes case studies that showcase the practical applicability of TOSCA, papers about the contribution of TOSCA to DevOps, papers about the use of TOSCA in an IoT (Internet of Things) setting, as well as papers about the use of TOSCA models for testing purposes.

  6. 6.

    TOSCA introduction: papers that introduce TOSCA or some of the concepts within TOSCA.

Fig. 1.
figure 1

Taxonomy for categorizing the processed papers

Full size image

The following paragraphs describe some representative papers in each category of the taxonomy of Fig. 1, except for the category “TOSCA introduction.” (Due to space limitation we cannot describe all found papers in detail.)

(1) Tools. The Tools category consists of papers mainly presenting tools for describing, deploying, and instantiating cloud applications using TOSCA. Prototypes that only serve to evaluate an approach are not assigned to this category.

Kopp et al. present the web-based modeling tool Winery [23]. First, Winery includes the Topology Modeler, with which components can be combined to form an application topology. Second, Winery contains the Element Manager, which can be used to create, modify, and delete components. Kopp et al. propose an extension to Winery that can be used to model Management Plans [24].

Binz et al. describe OpenTOSCA, a runtime for imperative processing of TOSCA applications [1]. This tool executes the defined Management Plans respectively the operations described within the nodes. Wettinger et al. present an extension to OpenTOSCA in the form of a unified invocation interface [40].

Breitenbücher et al. present Vinothek, which offers the user an interface for providing an instance of an application [7]. For this purpose, the user is offered the set of applications without having to deal with the technical details.

Katsaros et al. also provide a tool to deploy and manage software components [21]. The execution environment TOSCA2Chef parses TOSCA documents and deploys the components described in OpenStack Clouds using the Opscode Chef configuration management software and BPEL processes.

(2) Extension of language. Brogi et al. extend TOSCA by means for specifying the behavior of the application components when executing the management operations defined in the nodes [9]. Considering the effects of the operations to be performed and the states that the components assume after execution, makes the validation of Management Plans possible. Breitenbücher et al. propose a visual notation to unify the presentation of nodes within the topology [8]. Kopp et al. extend the BPMN to provide direct access to the topology elements [22]. The extension, called BPMN4TOSCA, can be transformed into standards-compliant BPMN.

(3) Methodologies for manipulating TOSCA models. Various approaches have been proposed to work with TOSCA models. Some focus on the processing of topologies, whereas others also take Management Plans into account to enforce policies, to verify the orchestration of the components, or to combine declarative and imperative processing.

Processing of Topologies. Brogi and Soldani describe an approach that involves matching between individual Node Types and Service Templates [11, 12]. This matching allows sets of Node Types to be grouped together in a topology to reduce its complexity. In addition, proven combinations of Node Types can be reused in new application topologies. Service Templates which do not fit exactly can be adapted to create a template that matches exactly to a given node type.

Binz et al. observed that container components (e.g. virtual machines) are often underutilized by a single application component, so that additional components can be hosted by these containers [3]. For this purpose, the topologies from two applications that use the same container components are merged into one topology in which both applications retain their respective functionality. Saatkamp et al. present an approach for adapting the application topology when a provider specifies a new offer and certain components of the application need to be migrated to new container components [33].

Multiple approaches for topology completion were proposed, with the aim that an application developer only has to model the business-relevant components and the underlying infrastructure is automatically added. The approach of Hirmer et al. is based on a repository of nodes and relationships to fill in incomplete topologies [20]. Brogi et al. present an approach to collect information about suitable cloud offerings by crawling the network and storing their TOSCA representation in a repository [10]. This representation can be used by application developers to complete the topology. Soldani et al. propose TOSCAMart, an approach to reuse proven topologies in new environments [35]. The developer of a composite application defines a node in the topology that describes the requirements for the fragment being inserted. TOSCAMart then selects a solution suitable for these requirements from a repository of various existing topologies.

Combining Declarative and Imperative Processing. Breitenbücher et al. propose an approach that combines declarative and imperative processing to achieve hybrid processing [5, 6]. The defined application topologies are interpreted and finally, the associated Management Plans are generated. Calcaterra et al. present a similar approach, also based on interpreting a topology and providing the appropriate Management Plan [14].

Policy Enforcement. Waizenegger et al. present a TOSCA runtime extension to enforce policies describing non-functional requirements, specifically security properties, such as the encryption of a database or the geographic positioning of privacy-related data [37, 38]. Policies can be defined using both single-node management operations and Management Plans.

Verification of Cloud Orchestration. Yoshida et al. describe an approach to the formal verification of TOSCA topologies that can be used to test the achievement of a target state in the declarative processing of the TOSCA model [42]. The execution of the management operation is described by a state transition system in which a state with a certain property is to be reached. Chareonsuk and Vatanawood use Model Checking to verify security properties for imperative processing [15]. The approach of Tsigkanos and Kehrer is about defining patterns and anti-patterns and finally checking their presence or absence in the topology of a service template so that quality aspects can be proven [36].

(4) Relation to other solutions. A comparison between TOSCA and the Heat Orchestration Template (HOT) is provided by Di Martino et al. [17]. HOT is the template format used to define the structure of an application for declarative processing by the OpenStack orchestrator Heat. The main difference between the two approaches is that HOT is declarative while TOSCA supports both declarative and imperative processing. Also, similarities are shown, for example, both provide a catalog of nodes and resources that can be composed to applications.

Yongsiriwit et al. address the interoperability of standards for describing cloud resources: TOSCA, Open Cloud Computing Interface (OCCI) and Cloud Infrastructure Management Interface (CIMI) [41]. For interoperability, ontologies are defined that describe the resources noted in each standard. In addition, an upper-level ontology is presented to describe cloud resources regardless of the used standards. Using inference rules, the special descriptions can be translated into this higher-level format and vice versa, which also allows the translation from one standard to another. Using the upper ontology, a knowledge base could be created, providing insights into relationships and possible inconsistencies.

(5) Usage of TOSCA. This category consists of approaches that use the existing TOSCA notation. Kostoska et al. present a case study of the use of TOSCA for specifying the University Management System iKnow [25]. This system offers professors and students a platform to exchange electronic information and provide electronic services. Besides a detailed description of node and relationship types, this paper also mentions the challenges of using TOSCA for the specification of this application.

A different domain for using TOSCA is the specification of Internet of Things (IoT) applications. Li et al. show how TOSCA can be used for an IoT application: an Air Handling Unit (AHU) that controls air circulation in modern buildings [26]. Da Silva et al. demonstrate the feasibility of defining IoT applications using TOSCA, in the context of different technologies [16]. In another paper, Da Silva et al. address the multitude of sensor data produced in IoT [34]. The authors describe how Complex Event Processing Systems can be deployed using TOSCA to process the incoming data and efficiently use network resources.

3 Discussion

Our survey shows the versatility of TOSCA: its use in different domains (also beyond cloud computing), for different purposes, in different phases of the service lifecycle, by different groups of users. This versatility is mainly due to (i) the possibility to define custom types for nodes, relationships, and capabilities and (ii) the possibility to define and manipulate partial topologies. However, this versatility also poses the risk of the proliferation of incompatible TOSCA dialects. Hence we expect that interoperability will play an increasingly important role.

Some further topics received limited attention so far and represent important targets for future research. First, given the enormous importance of security in cloud computing, it is striking that very few papers address it so far (although several authors mentioned it as future work [33, 41]). Also, TOSCA support for other related topics like data protection needs to be investigated [28]. Second, the topic of verification and validation (V&V) is also addressed by few papers. Given the importance of V&V, we expect to see more work on how TOSCA can be used to improve V&V. Third, partial topologies open many possibilities for optimization, from which only a little has been investigated, mainly in connection with cost minimization. Many other aspects of optimization, e.g., related to performance and reliability, are yet to be explored. Finally, TOSCA has been shown to be useful in areas such as IoT and DevOps [39]. We expect to see TOSCA being applied to new domains like network function virtualization [18] or fog and edge computing.