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