An overview of the OASIS TOSCA standard:

Topology and Orchestration Specification for

Cloud Applications
Ankita Atrey, Hendrik Moens, Gregory Van Seghbroeck, Bruno Volckaert, Filip De Turck
IBCN-iMinds, Department of Information Technology
Gaston Crommenlaan 8/201, B-9050 Gent, Belgium
E-mail: [email protected]

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.

Further Readings
Beginners, who are interested in getting to know more about TOSCA can start with the official
documents on the TOSCA standard [1, 4]. The next suggestion in the reading order is to follow the works
that state the importance and main features of TOSCA [3, 5, 6, 7, 8 and 9]. Apart from these, there are
other works that present new innovations based on TOSCA [12-35]. All these works include an in-depth
description of TOSCA and provide a way to gain familiarity with TOSCA.
References
1. OASIS: TOSCA 1.0 (Topology and Orchestration Specification for Cloud Applications), Version
1.0. http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCAv1.0.pdf (2013)
2. M. Armbrust, A. Fox, R. Grith, A.D. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson, A.
Rabkin, I. Stoica, M. Zaharia. A view of cloud computing. Communications of the ACM, 53(4),
50-58, 2010.
3. T. Binz, U. Breitenbücher, O. Kopp, F. Leymann. TOSCA: Portable automated deployment and
management of cloud applications. In Advanced Web Services, pages 527-549, 2014.
4. OASIS: Topology and Orchestration Specification for Cloud Applications (TOSCA) Primer
Version 1.0. http://docs.oasis-open.org/tosca/toscaprimer/v1.0/tosca-primer-v1.0.pdf (2013)
5. T. Binz, G. Breiter, F. Leymann, T. Spatzier. Portable Cloud Services Using TOSCA. IEEE
Internet Computing, 16(3), 80-85, 2012.
6. P. Lipton. Escaping Vendor Lock-in with TOSCA, an emerging Cloud Standard for Portability.
CA Technology Exchange, 4, 49-55, 2013.
7. A. Brogi, J. Soldani, W.P. Wang. TOSCA in a Nutshell: Promises and Perspectives. In Service-
Oriented and Cloud Computing, pages 171-186, 2014.
8. TOSCA and OpenTOSCA: TOSCA Inroduction and OpenTOSCA Ecosystem Overview
www.iaas.uni-stuttgart.de/OpenTOSCA/indexE.php#videos
9. T. Binz, U. Breitenbucher, F. Haupt, O. Koop, F. Leymann, A. Nowak, S. Wagner. OpenTOSCA-
A Runtime for TOSCA-Based Cloud Applications, In ICSOC, 2013
10. J. Cardoso, T. Binz, U. Breitenbucher, O. Kopp, F. Laymann. Cloud Computing Automation
Integrating USDL and TOSCA, In: CAiSE, 2013 (www.slideshare.net/caise2013vlc/jorge-
cardoso-caiseusdltosca20130618c )
11. TOSCA and OpenTOSCA: TOSCA Introduction and OpenTOSCA Ecosystem Overview.
http://www.slideshare.net/OpenTOSCA/tosca-and-opentosca-tosca-introduction-and-opentosca-
ecosystem-overview
12. T. Binz, F. Leymann, D. Schumm. CMotion: A Framework for Migration of Applications into
and between Clouds. In SOCA, 2011
13. Leymann F (2011). Cloud Computing. it – Information Technology, 2011
14. Petcu D, Craciun C, Rak M (2011). Towards a Cross Platform Cloud API – Components for
Cloud Federation. In: CLOSER, SciTePress
15. U. Breitenbucher, T. Binz, O. Kopp, F. Leymann, D. Schumm. Vino4TOSCA: A Visual Notation
for Application Topologies Based on TOSCA, In OTM, 2012
16. O. Kopp, T. Binz, U. Breitenbucher, F. Leymann. BPMN4TOSCA: A Domain-Specific
Language to Model Management Plans for Composite Applications, In BPMN, 2012
17. T. Waizenegger, M. Wieland, T. Binz, U. Breitenbucher, F. Haupt, O. Kopp, F. Leymann, B.
Mitschang, A. Nowark, S. Wagner. Policy4TOSCA: A Policy- Aware Cloud Service
Provisioning Approach to Enable Secure Cloud Computing. In OTM, 2013
18. J. Wettinger, M. Behrendt, T. Binz, U. Breitenbucher, G. Breiter, F. Leymann, S. Moser, I.
Schwertle, T. Spatizer. Integrating Configuration Management with Model-Driven Cloud
Management Based on TOSCA, In CLOSER, 2013
19. O. Kopp, T. Binz, U. Breitenbucher, F. Leymann. Winery- A Modeling Tool for TOSCA-Based
Cloud Applications. In ICSOC, 2013
20. T. Binz, U. Breitenbucher, O. Kopp, F. Leymann. Automated Discovery and Maintenance of
Enterprise Topology Graphs, In SOCA, 2013
21. T. Binz, U. Breitenbucher, O. Kopp, F. Leymann, A. Weib. Improve Resource-Sharing through
Functionality-Preserving Merge of Cloud Application Topologies, In CLOSER, 2013
22. A. Brogi, J. Soldani. Matching Cloud Services with TOSCA, In ESOCC, 2013
23. F. Li, M. Vogler, M. Claebens, S. Dustdar. Towards Automated IoT Application Deployment by
a Cloud-based Approach, In SOCA, 2013
24. P. Hirmer, U. Breitenbucher, T. Binz, F. Leymann. Automatic Topology Completion of TOSCA-
based Cloud Applications, In Proceedings of CloudCycle Workshop, 2014
25. F. Haupt, F. Leymann, A. Nowak, S. Wagner. Lego4TOSCA: Composable Building Blocks for
Cloud Applications, In IEEE International Conference on Cloud Computing, 2014
26. U. Breitenbucher, T. Binz, K. Kepes, O. Kopp, F. Leymann, J. Wettinger. Combining Declarative
and Imperative Cloud Application Provisioning based on TOSCA, In IEEE International
Conference on Cloud Computing, 2014
27. J. Wettinger, T. Binz, U. Breitenbucher, O. Kopp, F. Leymann, M. Zimmermann. Unified
Invocation of Scripts and Services for Provisioning, Deployment, and Management of Cloud
Application Based on TOSCA, In CLOSER, 2014
28. S. Ristov, M. Kostoska, M. Gusev. P-TOSCA Portability Demo Case, In CloudNet, 2014
29. M. Gusev, M. Kostoka, S. Ristov. Cloud P-TOSCA Porting of N-tier Applications, In TELFOR,
2014
30. G. Breiter, M. Behrendt, M. Gupta, S. D. Moser, R. Schulze, l. Sippli, T. Spatzier. Software
defined environments based on TOSCA in IBM cloud implementations, In IBM Journal, 2014
31. J. Carrasco, J. Cubo, E. Pimental. Towards a Fliexible Deployment of Multi-Cloud Applications
Based on TOSCA and CAMP, In ESOCC, 2014
32. J. Wettinger, U. Breitenbucher, F. Leymann. Standards-based DevOps Automation and
Integration Using TOSCA, In IEEE/ACM International Conference on Utility and Cloud
Computation, 2014
33. U. Breitenbucher, T. Binz, O. Kopp, F. Leymann. Vinothek- A Self-Service Portal for TOSCA,
In Proceedings of the Central- European Workshop on Services and their Composition, ZEUS,
2015
34. A. Brogi, A. Canciani, J. Soldani, P. W. Wang. Modelling the Behaviour of Management
Operations in Cloud-based Applications, In PNSE, 2015
35. B. Ivanovska, S. Ristvo, M. Kostoska, M. Gusev. Using the P-TOSCA Model for Energy
Efficient Cloud, In MIPRO, 2015
36. M. Kostoska, A. Donevski, M. Gusev, S. Ristov. Porting an N-tier Application on Cloud using P-
TOSCA: A Case Study, In MIPRO, 2015