## 3 Background
### Topology and Orchestration Specification for Cloud Applications (TOSCA)  
The description of a cloud application's topology and its deployment and configuration is a complex task that cloud vendors address by adopting different approaches and technologies, such as the Amazon AWS CloudFormation [32] or the Heat Orchestration Template (HOT)) [30], the template format based on the YAML (YAML Ain't Markup Language) [33] markup language, which is supported by Heat [29] the orchestration engine of the OpenStack cloud platform [16].  
In this context, in order to pursue the harmonization of existing approaches, the Organization for the Advancement of Structured Information Standards (OASIS) has proposed TOSCA (Topology and Orchestration Specification for Cloud Applications), a standard language for describing cloud-based service orchestration [13; 34].  
TOSCA defines a YAML-based specification for describing an IT service in terms of both its computing infrastructure and the required procedures for deploying, instantiating, executing and managing the service. The standard also specifies a packaged file format, namely Cloud Service Archive (CSAR), which allows one to store in the same package the YAML service description and the set of software artifacts (e.g., OS virtual images, libraries, scripts, DMBSs installation files, middleware, application software in executable form, etc.) that actually implement the service. The CSAR package is given as input to the _TOSCA Engine_, which is responsible for processing the YAML description so, overseeing the deployment of several artifacts composing the IT service, and orchestrating the execution of the related managing procedures.  
In TOSCA a _service_ is specified in terms of a _Service Template_, which is a YAML description, which completely specifies the service structure and its related characteristics. A service template includes the following elements:  
* **Topology template**, which is the most relevant component of a service template, as it describes the structure of a service in terms of its building blocks. The service structure is specified by the use of a direct graph in which nodes represent the building blocks of a service (e.g., servers, network interfaces, virtual images, databases, etc.), and edges represent the relationships between nodes (e.g., deployment relationship, connection relationship, etc.). According to a hierarchical structure, in TOSCA nodes and relationships are, in turn, further specified by the use of _node templates_ and _relationship templates_, respectively.
* **Node type and relationship type**, as in TOSCA each element must be associated with a type. Indeed, node templates and relationship templates are typed by node type and relationship type, respectively, which provide the characterization of properties and interfaces of each TOSCA topological element. The Service template contains a separate description of node types and relationship types to facilitate their reuse.
* **Life cycle operations**, as TOSCA addresses the operational management of a service, the Service Template also includes the specification of executable artifacts (e.g., scripts) implementing the several operations executed by the TOSCA engine to handle the service during its life cycle (deployment, execution, 'undeployment', configuration, etc.).  
As the use of TOSCA allows the specification of vendor-agnostic service orchestration, in this work, TOSCA is used as a reference notation for specifying reusable and interoperable service descriptions.  
A detailed description of the TOSCA standard is beyond the scope of this paper. Interested readers are referred to the official documentation.