WhitePaper TOSCA

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