INTRODUCTION Cloud computing has seen an immense rise in recent years, both in new technologies being released as in subsequent use by industry. The use of resources spread across the globe in an on-demand scalable manner, tied to pay-as-you-grow payment schemes, has made the Cloud very attractive. However in part due to this rapid growth, limitations are showing in the majority of Cloud-enabling technologies. More specifically, they lack the capability of providing a standardized view on similar resources served by different providers or through different Cloud middleware solutions [2]. This results in an inability to migrate applications across different platforms without investing high cost and time. As per [3], this is called the vendor lock-in problem and in order to resolve it, each component of an application, their relationships and management configurations must be encoded in a portable, standardized and a machine readable format. To this end, TOSCA -- the Topology and Orchestration Specification for Cloud Applications (Version 1.0) [1] was released. This standard offers a structured (XML based) language that defines different components of an application and relations between them using an application topology while capturing all management tasks in management plans. The main motivation behind this document is to provide an informational overview of TOSCA to people who are new to the recent developments in the field. As such, this document contains a description of a representative set of works in literature that made contributions to TOSCA. TOSCA objectives TOSCA is an OASIS standard which was mainly designed to address the automation, portability and interoperability aspects of complex cloud applications, i.e., applications composed of multiple services. TOSCA provides automatic deployment, termination and a multitude of other management facilities [3]. It binds all the different components of an application with their specified relations and provides an informative, standardized, and portable structure to achieve its main goal of automatic management and deployment of composite applications. The objectives of TOSCA can further be divided into different sub goals [7] which are stated as follows: 1. Automated deployment and management of composite applications: Automated deployment and management of complex applications possessing multiple (possibly distributed) services, is a major concern as well as demand of the IT enterprise, because manual management is a tedious and often a faulty process. In order to achieve the desired objectives, TOSCA aims at capturing the knowledge of the application developer formally. More specifically, TOSCA captures the information about the internals using a topology template and management plans, where the topology template provides an abstract view of an application’s structure, while the management plans help achieve automated deployment and management by defining different workflows. 2. Portability of application descriptions and their management: One of the major problems with cloud applications today is that some of the existing technologies do not support the migration of an application from one cloud provider to the other. This is mainly due to the fact that migration of applications between heterogeneous environments requires rebuilding some of the management functionalities. Sometimes it may even lead to re-implementation of some components of an application [3, 7]. These problems that arise due to application migration, thus render it as a highly cost ineffective process. According to [9,10,11], encoding of an application’s topology and its management plans in a self-contained way is one of the steps facilitated by TOSCA to resolve the issue of portability and deliver better results when compared to the existing solutions. Moreover, TOSCA provides a generic way to describe the application topology of composite cloud applications and leverages portable workflow languages to ensure portability of deployment and management plans [5]. Note that, TOSCA facilitates provisioning of the portability of an application and its management descriptions, and not the portability of the actual application itself. 3. Interoperability and reusability of application components: Interoperability is the ability to establish effective communication between different components of an application, under some well-defined set of rules (protocols). TOSCA provides interoperability by describing dependencies between various components of an application [3]. Moreover as discussed above, TOSCA allows packaging of an application in a self-contained way, thus further facilitating a standardized approach to reuse these applications in other complex ones. The TOSCA Service Template As discussed above TOSCA aims to provide various management facilities in order to reduce the complexity of composite applications. TOSCA provides an XML-based modelling language which encodes an application as a “Service Template” [1, 4]. In other words, the Service Template should be interpreted by a TOSCA-complaint environment, which in turn operates different cloud services and manages their instances [5], as shown in Figure 1. It consists of a typed topology graph called the Topology Template and their management tasks defined using different Management Plans. More specifically, the topology template is a multi-component cloud service representation which captures the relations between different nodes (here nodes are different components that constitute a service). On the other hand, management plans provide scale up, scale down and other strategies for different application components. We will discuss this in the following sections of this article. To summarize, the TOSCA Service Template broadly defines two separate parts to denote the structure of a Cloud application: a) Topology Template: A topology template can be understood as a congregation of different node templates and relationship templates, all of which collectively define a cloud application (flow) using a graph. Each node is represented by a node template whereas the relationship between two nodes is represented by a relationship template. Each node template belongs to a node type and similarly the relationships between different nodes can also belong to various relationship types. Both node types and relationship types are reusable entities. In other words, the application components and their relations are represented by means of typed “Node and Relationship Templates” [7]. Figure 2 presents the Topology template involving some of the components of a sample cloud application -- MakeMyHome (a more detailed Topology template shown in Figure 6), using the node and relationship templates. This application provides the ability to search for commercial / residential properties with the objective to fulfill the majority of the requirements of a customer. By means of this example, readers of this article should get a clear idea about the difference between Node Template, Relationship Template, Node Type, Relationship Type and other management operations. Each application component / constituent is represented by a node template with its corresponding node type in parenthesis. For example, “Apache Tomcat” that represents a node template, is one of the components of this application with “Web-server” as its node type (Tomcat is a specific type of web-server providing different functionalities). Similarly, the “Apache HTTP server” could also be one of the node template with the node type as “Web-server”. Moving ahead, “Ubuntu 12.04 LTS” represents a node template for the “Operating System” node type. Note that Mac, Windows 2013 Server can also replace Ubuntu as node types for the operating system node template. Figure 1: TOSCA Service Template defines the structure of a complex cloud Application [1]. Figure 2: Topology template of sample application, where nodes are components / constituents of an application and edges represents the relationship between these components [10]. A node template specifies the occurrence of a node type as a component / constituent / building block of an application [1]. Both node and relationship templates are typed and preserve some set of type-specific properties (for example integer (int) and floating point (float) data-types for different type of variables in C or in any other programming language) with the type templates while retaining instance specific properties with the node template itself. The three conceptual layers in figure 3, namely – (1) types (2) templates and (3) instances better define this behavior. 1) Type defines the reusability of component with its specific properties, which is further used to construct the application topology by templates. Node type is the major building block of a service and it maintains the definition of implementation artifacts and deployment artifacts for different components. Artifacts represent the content needed to realize a deployment and management operation of an application component [7]. Artifacts represents any type of content for example executable programs, scripts, libraries etc. 2) Instance layer depends on the runtime of TOSCA and represents instances of the component and relationship defined by templates [3]. Similar to the description of node templates and types, we now provide a description of relationship templates and its types. All four components of our MakeMyHome application, in Figure 2, are connected to each other with the relation “hosted on”, which specifies a relationship type. As an example: the Ubuntu 12.04 LTS components of our application (of node type Operating System) is hosted on an Amazon EC2 server (of node type Virtual Server), represented by the relationship template “UbuntuOnEC2” which is of relationship type “hosted on”. Similarly, the Tomcat webserver is hosted on the operating system together with the war file by which the application is deployed, again represented by a relationship of type “hosted on”. Although, this example presents relationships of a specific singular type, it is possible to define many other relationship types between different components of an application, viz. installed on, depends on, deployed on etc. Figure 3: Different levels of TOSCA concepts [3, 5]. b) Management Plans: Organizations that develop cloud applications, seek efficient management processes for these applications. Typically, most of the organizations learn how to manage their services on their own (e.g. how to efficiently operate these services, how to scale them up/down). In specific cases, scripts are also designed for some of the frequently used components in order to make their management easy and semi-automated. For example, a developer can create a bash script (in Linux) for compiling a huge library, which in turn prevents having to rewrite a large number of commands on a frequent basis. However, this may not be the most cost effective method, since sometimes migration of an application from one cloud provider to the other, requires rebuilding the application or even re-implementing some of the application components. This quickly becomes a complex task for applications consisting of a large number of components. To this end, TOSCA enables the developers to capture the frequently used management tasks as management plans, which in turn significantly decrease subsequent manual effort and facilitate automatic execution of applications and their deployment. TOSCA provides the ability to manage all the components of an application and obtain different models for best management practices. The main advantage of TOSCA management plans is that it facilitates production of portable plans so that a cloud service can easily migrate between different environments. This type of management practice significantly reduces management costs and provides better results. These plans are defined in terms of a workflow, which further aggregates the operations performed by various nodes in the application topology to provide a sequence of steps. Management plans describe the management operations associated with various components and relationships of an application. In addition, they also capture the sequence of operations involving different nodes and/or relationships of an application [OASIS 2010]. Further, as discussed above, the portability of workflow definition languages used to describe these management plans, allows for portable management of applications as well. Figure 4: Example of a Management Plan to deploy an Application in two steps [11] Usually, plans belongs to two broad types, namely (1) Build Plans – that help create an instance of a service template and (2) Termination Plans – that help destroy a service template instance. Theses build and termination plans include various strategies for scaling, deployment and termination of an application. Management plans also define a set of constraints that need to be satisfied. These constraints can for instance define the required response time for a query by a customer and the overall management budget for an application. Monitoring information required to achieve these different constrains are specified in the plans, for example detection of response time, resource utilization and throughput etc. Figure 4 presents a simple management plan to deploy an application in two steps, namely – (1) Installing Apache Tomcat on an Ubuntu operating system and (2) Deploying the application on the Tomcat server. TOSCA does not provide a new language for executing these plans. However, it uses existing workflow languages such as the Business Process Execution Language (BPML) and Business Process Model and Notation (BPMN, recommended workflow language for TOSCA management plans) [1, 3]. Each task of a defined plan, refers to a topology node (Figure 5). Each topology node (typed) may have interfaces, properties, requirements exposed to the management plans. Interfaces are in turn bound to a concrete implementation, for example implementation artifacts (scripts, executables etc.) and deployment artifacts (installable, images etc.). TOSCA Packaging TOSCA provides a service template that represents the overall structure of a complex composite cloud application and management plans to manage different components of an application. Different files are maintained such as implementation artifacts, deployment artifacts, Plans, XML schemas, scripts etc., in order to achieve the management functionalities of cloud applications. All these files need to be packaged together with the service template into the TOSCA archive called the “Cloud Service Archive (CSAR)” [OASIS 2012, 3]. CSAR provides a method to package an application in a self-contained way along with all of its management functionality. The TOSCA runtime environment provides support for TOSCA archives and is able to process (installing the application package) said archives. Figure 5 shows the structure of TOSCA archive. Figure 5: Packaging of all the files with service template into TOSCA archive called “CSAR” [11]. Example – TOSCA-enabled MakeMyHome application To make the preceding sections more clear, we present an example of a TOSCA-based application, the MakeMyHome application, with all its different components in Figure 6. The MakeMyHome application is an online platform for customers, which provides the capability to search for residential/commercial properties as per their requirements. This application mainly consists of two stacks, namely -- (1) Stack S1 that describes the web-framework of the application and (2) Stack S2, which describes the different properties stored in a MYSQL database. This database is accessible through a database connection made by the PHP application. The infrastructure layer of S1 consists of a “Virtual Machine” node type with node template “Amazon EC2 Server”. Ubuntu operating system, represented by node type “Operating System” with node template “Ubuntu 12.04 LTS” is hosted on this virtual machine (EC2 Server). A “webserver” node type with node template “Apache HTTPD Server” is installed on this operating system. Moreover, a node template “PHP Container” with node type “PHP Module” is installed on the Apache HTTPD Server. Node template “MakeMyHomeApp” with node type “PHP Application” implements the GUI of MakeMyHome application hosted on a PHP container. Figure 6: Example of TOSCA based topology template for “MakeMyHome” Application On the other side, the infrastructure layer of stack S2 describes the product data for our web-based application. It consists of a “Virtual Server” node type with node template “Amazon EC2 Server”. On this virtual server, a node type “Operating System” with node template “Ubuntu 12.04 LTS” is installed further. Moving ahead, a node template “MYSQL” is installed (maintains information about all the commercial/residential properties) on the Ubuntu 12.04 LTS operating system, which is represented by the node type “MYSQLRDBMS”. Node template “MakeMyHomeDB” with node type “MakeMyHomeDatabase” is deployed on this MYSQLDatabase. Finally, the “MakeMyHomeApp” application directly interacts with the “MYSQLDatabase” using a “DBConnection” to store the data into this database. The corresponding build plan of “MakeMyHome” is shown in Figure 7. A build plan helps in creating an instance of the service template and is responsible for deployment of both the software stacks (S1 and S2) mentioned above. The recommended workflow language for TOSCA management plans is BPMN, which supports parallel execution of tasks. This facilitates the deployment of both the software stacks in parallel. We first describe the steps for the deployment of S1. The first activity in order to deploy the stack S1 is to install the Ubuntu 12.04 operating system on the Amazon EC2 virtual server whose IP address is given by the input message of the build plan. To execute the build plan, the operator needs to know the IP address of the server and should hence mention it in the input message. Figure 7: Build Plan for TOSCA based “MakeMyHome” Application After installation of the operating system, the next step is to configure it by performing specific activities / actions, such as configuring the firewall rules etc. The next step involves installation of the Apache HTTPD Web Server on the Ubuntu OS, followed by the installation of the PHP Module on the Apache Web Server. Finally, the PHP Application is deployed on the PHP Container. The second branch supports, in parallel, the deployment of the second stack S2. We begin by acquiring an instance of the Ubuntu OS on the Amazon EC2 Server. Next, MYSQLDB, which contains the data for products, is installed on the Ubuntu operating system. The last step is to setup an endpoint for the PHP Application to seamlessly interact with the product database. Once both stacks are deployed, the PHP application is done with the deployment and the front end of this application is presented to the end-user. Conclusion In this article, we discussed about the OASIS standard, TOSCA -- Topology Orchestration Specification for Cloud Applications. We described the three main objectives of TOSCA and studied the Service Template provided by TOSCA. Next, an in-depth description of Service Template was provided, which further explained the Topology template and Management plans. The detailed study of the Topology template (with the description of Node Type, Node Template, Relationship Type, Relationship Template) and Management plans, further helped us clearly demarcate their objectives. Towards the end, we described TOSCA archives and studied the way in which different files are packaged into an application. To summarize, TOSCA is a mature standard with the capability to resolve major problems addressed in cloud (i.e Automatic deployment, portability etc.). The readers of this document are expected to gain basic understanding of TOSCA and its different features. At the end of this article there is a further reading section which should be helpful for users who want to know more about the TOSCA standard and its contributions to the field of cloud computing.
