Institute of Architecture of Application Systems, University of Stuttgart, Germany {lastname, breitenbuecher}@iaas.uni-stuttgart.de,

zimmerml@studi.informatik.uni-stuttgart.de

Unified Invocation of Scripts and Services for Provisioning, Deployment, and Management of

Cloud Applications Based on TOSCA

Johannes Wettinger, Tobias Binz, Uwe Breitenbücher, Oliver Kopp, Frank Leymann, and Michael Zimmermann

These publication and contributions have been presented at CLOSER 2014

http://closer.scitevents.org

© 2014 SciTePress. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the SciTePress.

@inproceedings{Wettinger2014,      author        =  {Johannes  Wettinger  and  Tobias  Binz  and  Uwe  Breitenb{\"u}cher  and  

Oliver  Kopp  and  Frank  Leymann  and  Michael  Zimmermann},      title          =  {Unified  Invocation  of  Scripts  and  Services  for  Provisioning,  

Deployment,  and  Management  of  Cloud  Applications  Based  on  TOSCA},      booktitle  =  {Proceedings  of  the  4th  International  Conference  on  Cloud  

Computing  and  Service  Science,  CLOSER  2014,      3-­‐5  April  2014,  Barcelona,  Spain},  

   year            =  {2014},      pages          =  {559-­‐-­‐568},      publisher  =  {SciTePress}  }  

:

Institute of Architecture of Application Systems

Unified Invocation of Scripts and Services for Provisioning, Deployment,and Management of Cloud Applications Based on TOSCA

Johannes Wettinger, Tobias Binz, Uwe Breitenbucher,Oliver Kopp, Frank Leymann, and Michael Zimmermann

Institute of Architecture of Application Systems, University of Stuttgart, Universitatsstraße 38, Stuttgart, Germany{lastname, breitenbuecher}@iaas.uni-stuttgart.de, zimmerml@studi.informatik.uni-stuttgart.de

Keywords: Management Plans, Management Operations, Script Invocation, Unified Interface, TOSCA, DevOps

Abstract: There are several script-centric approaches, APIs, and tools available to implement automated provisioning,deployment, and management of applications in the Cloud. The automation of all these aspects is key forreducing costs. However, most of these approaches are script-centric and provide proprietary solutionsemploying different invocation mechanisms, interfaces, and state models. Moreover, most Cloud providersoffer proprietary Web services or APIs to be used for provisioning and management purposes. Consequently,it is hard to create deployment and management plans integrating several of these approaches. The goal ofour work is to come up with an approach for unified invocation of scripts and services without handling eachproprietary interface separately. A prototype realizes the presented approach in a standards-based manner usingthe Topology and Orchestration Specification for Cloud Applications (TOSCA).

1 INTRODUCTION

Automated provisioning, deployment, and manage-ment of Cloud applications are key enablers to reducecosts of their operation (Leymann, 2009). However,it is hard to implement automated processes for man-aging applications in production after the actual de-velopment is finished. The main reason is that keyaspects for operating an application in production werenot considered during development. The idea of Dev-Ops (development & operations) aims to eliminate thebarrier between developers and operations personnel(Humble and Molesky, 2011). Consequently, a highlyautomated management environment has to be estab-lished during development already to continuouslydeploy and manage new iterations of an applicationto different environments (e.g., development, test, andproduction).

When automating such deployment and manage-ment processes there are typically a number of buildingblocks involved: (i) different Cloud providers exposeproprietary APIs to provision and manage resourcessuch as storage and virtual machines. (ii) Several toolssuch as Chef (Nelson-Smith, 2011) originating in theDevOps community provide a means to automaticallydeploy application components on top of the Cloudresources provisioned before. The DevOps communityalso publicly offers reusable artifacts to be used for the

deployment of particular application components. (iii)Custom scripts (e.g., Unix shell scripts) may be imple-mented to manage the application during runtime (e.g.,adding new users).

However, it is hard to combine these buildingblocks because the invocation mechanisms of Web ser-vices/APIs, scripts, and other plans involved in theseautomated processes differ significantly and the major-ity of them is not standards-based (Breitenbucher et al.,2013). The main goal of our work is to address thisdeficit by creating a management bus to provide a uni-fied invocation interface hiding all the technical detailsof the employed management technologies. This inter-face is used by management plans implementing thelogic required to automate a particular managementtask. The main contributions of our work are outlinedin the following. We present:

• Concepts for unified invocation of different kindsof scripts (e.g., used for deployment) and differentAPIs (e.g., used for provisioning).

• Architecture and prototype of a unified invocationbus and interface to be used by management plansbased on the Topology and Orchestration Specifi-cation for Cloud Application (TOSCA) (OASIS,2013).

• Evaluation based on an end-to-end open sourcetoolchain to show that plans get simpler and the

number of specific “wrappers” used for invokingcertain scripts and services are reduced.

The remaining of this paper is structured as fol-lows: Section 2 outlines the currently existing issuesand limitations we address in our work. We presentTOSCA as an emerging standard for managing Cloudapplications in Section 3 because major parts of ourwork is based on it. Section 4 discusses the notion ofa management plan and the orchestration of manage-ment operations using plans. Our concepts regardingthe unified invocation approach are presented in Sec-tion 5, followed by an evaluation of this approach inSection 6. Finally, we discuss some related work inSection 7 and conclude this paper in Section 8.

2 PROBLEM STATEMENT

Regarding the state of the art of provisioning and de-ployment of Cloud applications, several approachesemerged in the last few years. Some of the most popu-lar approaches today are based on tools originating inthe DevOps community such as Chef (Nelson-Smith,2011), Puppet (Loope, 2011), CFEngine (Zamboni,2012), and Juju1. Delaet et al. (2010) survey andcompare some of the technical aspects of these toolsin more detail. The main purpose of these tools isautomating the installation and configuration of appli-cation components on physical and virtual machines.This is the reason why they are often called configu-ration management tools. To implement deploymentlogic for application components such as a Web serveror a database, scripting languages are used. As an ex-ample, Chef uses a domain-specific language (Guntheret al., 2010) based on Ruby to implement deploymentand management operations. In case of Chef, these op-eration implementations are called recipes, bundled incookbooks2. Since each tooling uses different conceptsfor developing, managing, and invoking managementoperations, it is hard to combine them in order to au-tomate the deployment of a certain application stack.Such a stack typically consists of several components,some of which are hosted on others (e.g., a PHP ap-plication hosted on on an Apache HTTP Server) andconnected to each other (e.g., an application is con-nected to a database). We further refer to such a stackas an application topology.

The hard-to-realize interoperability of these ap-proaches would make a lot of sense because the com-munities affiliated with these tools provide plenty ofreusable management operations such as cookbooks

1Juju: http://juju.ubuntu.com2Cookbooks: http://community.opscode.com/cookbooks

provided by the Chef community and charms3 offeredby the Juju community. These operations can be usedto implement deployment plans automating the de-ployment of whole application stacks consisting ofdifferent components. Especially components that arecommonly used as middleware such as the ApacheHTTP Server can be deployed by parameterizing theseoperations. As an example for the deployment of a typ-ical stack, a publicly available Juju charm can be usedto create a MySQL database cluster, an already avail-able Chef recipe may be used to create an instance ofthe Apache HTTP Server, whereas the deployment of aparticular PHP application is implemented by a customUnix shell script. As of today, however, the orchestra-tion of these operations is limited to the boundary of asingle ecosystem, including its operations, its tooling,and its community.

Another limitation of the approaches described be-fore is their limited management view on applicationtopologies. Since an application typically is not amonolithic block, there are several application com-ponents involved that are related to each other. Someof these tools provide a means to model topologiesand stacks such as the Juju GUI4 and Amazon WebServices’ OpsWorks5, but most of them do not. Thislimited management view, mostly focusing on singlemore or less isolated parts of a topology, makes it hardto manage large and distributed applications. Relationsbetween components are only modeled implicitly andare typically hard-wired in the operations’ implemen-tation. However, especially the relations are importantfor management to understand the dependencies andpossible side effects of a management action. Whatthese tools miss anyhow is a portable and standards-based approach to specify such topologies. This isanother reason why the orchestration of different oper-ation types is hard to implement because if there is ameans to model an application topology it is limited toa single ecosystem. Furthermore, different approachesown different state models where properties are storedfollowing a certain structure. A central and overarch-ing state model is required to access these data in aunified manner.

The provisioning of resources such as storage orvirtual machines in the Cloud is another key aspectin this context. This is typically the first step of a de-ployment process because a machine is required to berunning to deploy and manage application componentson it. In addition, provisioning of resources is a funda-mental part of many management tasks. For example,to scale an application, additional resources must be

3Juju Charms: http://jujucharms.com4Juju GUI: http://juju.ubuntu.com/resources/juju-gui5AWS OpsWorks: http://aws.amazon.com/opsworks

provisioned. There are standardization and unificationefforts going on such as OpenStack (Pepple, 2011) andDeltacloud6 to provide a unified API for provisioningtasks across different Cloud providers. However, inpractice there are still lots of different APIs such asthe Google Compute Engine API7, the Amazon WebServices API8, and Baremetalcloud’s API9 to namea few. Consequently, in a multi-cloud managementscenario where application components are distributedacross different Cloud providers (e.g., for resiliencepurposes), it is hard to combine them because of theirdifferent APIs.

The goal of our work is to address the issues de-scribed before by presenting an approach for creatingoverarching plans orchestrating different kinds of op-erations and APIs. Furthermore, plans, covering bothdeployment and runtime management of Cloud appli-cations, should be able to access a holistic topologymodel covering the whole automatically deployed ap-plication stack.

We present the most important concepts of theTopology and Orchestration Specification for CloudApplications in the next section. The purpose of usingthis emerging standard in our work is to specify ap-plication topologies and package them together withcorresponding management plans in a portable man-ner.

3 TOSCA

The Topology and Orchestration Specification forCloud Applications (TOSCA) (OASIS, 2013) enablesthe definition of application topologies including theirapplication components, the relations between them,and the resources where they are hosted on such asVMs. It is an emerging standard supported by a num-ber of prominent industry partners such as IBM andHewlett-Packard to enable the portable definition oftopology models. Figure 1 shows a TOSCA-basedtopology model for SugarCRM10, an open source cus-tomer relationship management software. The Sug-arCRM application topology is used by the TOSCAinteroperability subcommittee11 as an example for dif-ferent vendors to check whether their TOSCA runtimeenvironment is compliant to the specification. Thetopology model is a graph consisting of nodes thatrepresent both application components (Apache HTTP

6Deltacloud: http://deltacloud.apache.org7http://cloud.google.com/products/compute-engine8AWS API: http://aws.amazon.com/documentation9Baremetalcloud: http://www.baremetalcloud.com

10SugarCRM: http://www.sugarcrm.com11SugarCRM Interop Topology: http://goo.gl/C6pqRd

Server, SugarCRM App, etc.) and infrastructure re-sources (VM 1, VM 2). These nodes are linked byrelationships to express that a particular node is hostedon another one (e.g., SugarCRM App is hosted onApache HTTP Server) and to specify a connectionbetween two nodes (e.g., application connects to thedatabase).

SugarCRM App SugarCRM DB

Apache HTTP Server + PHP

VM 1 (Ubuntu Linux)

VM 2 (Ubuntu Linux)

MySQL Database Server

connects to

hosted on hosted on

hosted on hosted on

connect() install()

provision() provision()

install() install()

install() Script

IA

WAR IA

WAR IA

Script IA

Script IA

Script IA

Script IA

Figure 1: SugarCRM topology model.

Each node and relationship can have managementoperations attached. For instance, a VM node has aprovision operation defined that is in charge of provi-sioning a new VM. Furthermore, nodes representingapplication components typically own an install oper-ation to install and configure a particular applicationcomponent. Operations can also be attached to re-lationships as it the case for the connect operationattached to the relationship wiring the application withthe database. However, at this level an operation is stillan abstract modeling construct. To make it executable,an implementation artifact (IA) needs to be attachedto each operation that implements the operation. Asan example, a WAR file exposing a Web service couldbe attached to the provision operation of a VM node.This WAR file is then deployed to a servlet containerprovided by the TOSCA runtime environment. Oncethe operation is invoked, a request is sent to the Webservice performing the actions required to create a newVM. Another example is to attach a Unix shell scriptto the install operation of an application componentnode. When the operation is invoked, the script getscopied to the target VM and then is executed there.If several IAs are attached to a single operation, it isassumed that all of them implement the same logicbased on different technologies. The TOSCA runtimeenvironment is free to pick one of them to perform theoperation.

In addition to defining the topology model and im-plementing the IAs, plans need to be written such as abuild plan to create new instances of such a topologymodel. A plan basically defines the order of opera-tion invocations to achieve a certain management goal(Binz et al., 2012). BPMN4TOSCA (Kopp et al., 2012)proposes TOSCA-specific modeling constructs to be

used in plans based on BPMN (OMG, 2011). TOSCAfurther defines a packaging format called Cloud Ser-vice Archive (CSAR) to deliver all ingredients belong-ing to a particular topology model such as IAs, plans,and the topology model itself as a single file, a CSAR.

The following Section 4 outlines the notions ofmanagement plans and management operations as wellas how they work together. These are the fundamentalsfor the concepts we describe later.

4 MANAGEMENT PLANSAND OPERATIONS

Management logic is implemented on different levels:script-centric artifacts provided by the DevOps com-munity (Wettinger et al., 2013) typically implementthe installation and configuration of application com-ponents such as an Apache HTTP Server or a PHPmodule on a physical or virtual machine (VM). Sincethe nature of these artifacts is relatively fine-grained,specifying low-level management tasks that need to beperformed, we refer to these artifacts as managementoperations. They are typically designed in a way toperform a configurable “atomic” management actionsuch as installing an Apache HTTP Server or adding anew user account to an application. These operationsfocus on the deployment of application components aswell as their management at runtime such as changingthe configuration of a particular component:

Management Operations automate managementactions that are considered “atomic”, i.e., it does notmake sense to split them up further to achieve a certainlow-level management goal.

(Management Operations) (Management Operations)

Scale-out Component Y (Management Plan)

Scale-out Component X (Management Plan)

Scale-out Application (Management Plan)

Invocation

Figure 2: Plans orchestrate plans and operations.

A particular management operation may, for in-stance, represent a script performing a particular man-agement action on a VM. However, it could also be aninvocation of a service or an API offered by a Cloudprovider, for instance, to provision new resources suchas VMs. In order to enable the orchestration of severalmanagement operations, for instance, to deploy a com-plete application topology, more coarse-grained plans

are required. We refer to these plans as managementplans:

Management Plans control the invocation of man-agement operations and other management plans.They specify the proper ordering of the invocationsas well as handling the input and output of each invo-cation.

As mentioned in the definition before, plans mayalso be used to combine existing plans and operations,so plans can be positioned on different levels as shownin Figure 2. As an example, a scalable application typi-cally consists of several components that are deployedin a distributed manner. In order to scale such an ap-plication in or out, some of the components need to bescaled according to the current workload. There couldbe a management plan for each component that realizesits scale-out. A plan on this level (e.g., implementedas a Ruby script) may invoke operations (e.g., Chefrecipes) to reconfigure deployed instances that belongto this particular component of the application as wellas operations to create and configure new instances toenable the scale-out. Moreover, an overarching man-agement plan (e.g., realized as a workflow) could beimplemented to invoke individual management plansfor each component involved in the scale-out process.Finally, management plans enable multi-cloud manage-ment scenarios: a particular plan may invoke differentoperations for resources distributed across differentCloud providers such as installing a database on a VMat provider A and installing an application server on aVM at provider B. Furthermore, such a managementplan can use APIs and services (management opera-tions) exposed by different providers to provision newresources such as storage or a VM.

Actually, management plans are very similar toworkflows and business processes. Binz et al. (2012)describe how to use existing workflow technology andstandards such as the Business Process Model andNotation (BPMN) (OMG, 2011) and the Business Pro-cess Execution Language (BPEL) (OASIS, 2007) toimplement and execute management plans. The recur-sive character of management plans, i.e., orchestratingexisting management plans by another managementplan, is similar to how BPEL deals with Web services:a BPEL workflow is not limited to invoking existingWeb services. It can also be exposed as a new Webservice that can then be invoked by another BPELworkflow, possibly as subprocess (Kopp et al., 2010).The distinction of management logic in plans and oper-ations is similar to how workflows are typically distin-guished: low-level workflows (similar to operations)are often referred to as micro flows (Manolescu andJohnson, 2001) that can be orchestrated by “real” work-flows (similar to plans).

By implementing management plans as workflowsbased on established standards such as BPMN orBPEL, the plans’ portability is improved. Existinggeneral-purpose workflow engines can be used to ex-ecute these plans. Moreover, the plans inherit theproperties of workflows such as recoverability andcompensation as discussed by Binz et al. (2012).

To enable the portability of management oper-ations, domain-specific languages (DSLs) such asthe Ruby-based DSL used by the Chef community(Gunther et al., 2010) can be used. These languagesprovide platform-independent abstractions for typicallow-level management and deployment actions suchas installing a particular software package, writing aconfiguration file, or setting file permissions.

Again similar to workflows, there are different fla-vors of plans and operations: management logic canbe implemented in an imperative or in a declarativemanner. Whereas a declarative implementation onlyspecifies what actions have to be performed, an imper-ative implementation additionally describes how theseactions need to be performed. As an example, a declar-ative management operation may define a set of soft-ware packages that need to be installed. The imperativevariant would further define how to install these pack-ages. Imperative management plans based on work-flows can be realized using BPMN or BPEL. However,there are also declarative workflow languages (Pesicand van der Aalst, 2006) available that could be usedto implement declarative management plans. For man-agement operations, the very same distinction exists:some of the DevOps tools such as Puppet provide adeclarative domain-specific language, whereas Chefrecipes, for instance, can be implemented using botha declarative (Ruby-based domain-specific language)and an imperative approach (plain Ruby). Further-more, Unix shell scripts as for instance used by severalJuju charms are a typical example for imperative man-agement operations because their logic encapsulatesseveral system commands that exactly define whataction to perform and how to perform this action. Con-ceptually, there is no limitation to combining plans andoperations of different flavors. As a result, an impera-tive management plan could invoke several declarativeplans and operations or vice versa.

In the following section we present concepts for astandards-based approach to tackle the problems out-lined in Section 2. Furthermore, we come up with anarchitecture and a prototype that realizes these con-cepts based on TOSCA.

5 UNIFIED INVOCATION INTER-FACE FOR PLANS

As outlined in Section 2 it is difficult to combine differ-ent management operations such as Chef recipes, Unixshell scripts, or certain provider APIs because eachof them has individual invocation mechanisms. Toaddress this issue the goals of our concepts presentedin this section are threefold:

1. Creating management plans has to be as simpleas defining the flow logic (e.g., a sequence) ofoperations of particular nodes or relationships ina TOSCA topology model. The technical detailsof invoking a particular operation are completelyhidden to such a management plan.

2. The number of implementation artifacts (IAs) cre-ated for a CSAR should be reduced as much aspossible. As an example, the CSAR should not de-liver an IA that implements the execution of scriptsof a certain kind, because this logic does not im-mediately belong to the application’s managementlogic and thus has to be provided by other means.

3. Different operations in a topology model can beimplemented using different kinds of IAs such asChef recipes, Unix shell scripts, or Juju charms.However, there should not be any dependency onadditional IAs (e.g., an IA exposed as Web serviceto execute a Chef recipe) to enable the executionand orchestration of such operations.

All these goals enable separation of concerns, sothat (i) a management plan focuses on the logic ofcombining operations properly, (ii) a CSAR containsartifacts and plans only related to the application itspecifies, and (iii) different kinds of IAs can be usedto implement a particular operation without changinghigher-level management plans.

To achieve these goals a unified invocation inter-face is required that can be used by plans to invoke op-erations without knowing what kind of IA or technol-ogy is used in the background. The unified invocationinterface is implemented based on OpenTOSCA (Binzet al., 2013), an open source TOSCA runtime environ-ment. OpenTOSCA is one of the core components ofan end-to-end toolchain to create and process TOSCAmodels. First, we outline how OpenTOSCA deals withplans, operations, and their invocation without such aninterface. Then, we describe how we improved Open-TOSCA addressing the issues we discussed before.

CSAR (topology & plans)

Plan

Cloud Provider B API

Cloud Provider A

API

VM …

API / Service Call CSAR Import Execution via SSH Connection

SOAP+HTTP

…

SSH

REST+HTTP

…

Cloud Provider B Management IA

Apache Server Install. Script IA

SSH

Cloud Provider A Management IA

PHP Module Install. Script IA

OpenTOSCA Runtime Environment HTTP

HTTP

Figure 3: Original architecture without a unified invocation interface for plans.

5.1 Original Architecture ofOpenTOSCA

Figure 3 shows a simplified overview of the architec-ture of OpenTOSCA. It further outlines the process ofcreating an instance of a particular application topol-ogy specified by a CSAR as it is currently implementedwithout the issues in mind we mentioned before. Theinitial step is to import a CSAR to the runtime environ-ment, so that new instances can be created based on themodel described in the CSAR. In addition to the actualtopology model, the CSAR further contains all con-figuration and management plans as IAs and TOSCAmanagement plans (Binz et al., 2012). We assume thateach CSAR contains an overarching build plan speci-fying which operations of nodes and relationships inthe topology have to be invoked in which order. Thisplan is executed by the OpenTOSCA runtime environ-ment to build a new instance of the topology describedin the model.

When the plan invokes a particular operation thecorresponding implementation artifact (IA) is executed.Some IAs may be implemented as SOAP-based Webservices in Java (WAR files), others may be imple-mented as Unix shell scripts or Chef recipes. Whenimporting a CSAR, all implementation artifacts thathave to run in the local OpenTOSCA managementenvironment are deployed. For instance, the IAs pro-viding Web services implemented in Java are hostedon a local Java servlet container that is part of theOpenTOSCA runtime environment. We refer to theseIAs as local IAs. OpenTOSCA further supports localIAs providing RESTful Web services implemented inJava. All other IAs such as script IAs are obviously notdeployed locally because they need to be executed onthe target VMs remotely. Therefore, we refer to theseIAs as remote IAs. Plans are bound to local IAs, so thecorresponding plan and IAs are hard-wired. This factdecreases the portability and reusability of plans.

The sample plan outlined in Figure 3 depicts sev-eral management operations that are performed in a

multi-cloud management scenario. These represent asubset of operations required to create a new instanceof the SugarCRM application topology described inSection 3. (i) The plan uses the local Cloud Provider AManagement IA to interact with the API of provider A.The same applies to the Cloud Provider B ManagementIA for provider B. However, the invocation interfacesdiffer (SOAP+HTTP vs. REST+HTTP). Consequently,the plan needs to be aware of the interfaces’ idiosyn-crasies in terms of invocation, passing input data, andreceiving the result of the execution. (ii) Furthermore,the plan invokes operations implemented by script IAs(Unix shell scripts) such as the Apache Server Installa-tion Script IA. Since these scripts need to be executedremotely on a target VM at the provider, there are twooptions to deal with remote execution: the plan itselfcould implement the management logic for copyingthe scripts to the target machine using SSH, setting in-put and environment variables accordingly, performingthe execution, and retrieving its output. Alternatively,a local wrapper IA such as an SSH Unix Shell ScriptInvoker IA could be implemented and packaged with aCSAR. This IA would expose the management logicfor handling the execution of a certain type of script(Unix shell scripts) as Web service to be used by theplan. The second option is typically necessary in casethe plan is implemented as workflow, e.g., based onBPEL, because such workflows cannot establish SSHconnections without proprietary extensions.

Both options for executing remote IAs such asscripts pollute plans and CSARs with managementlogic that does not belong to the application’s manage-ment logic and should therefore be provided by themanagement environment. In this case, such manage-ment logic can be reused by different CSARs. Fur-thermore, plans need to deal with different invoca-tion mechanisms such as SOAP+HTTP, REST+HTTP,and SSH-based script execution. Thus, plans can getcomplex even if the application topology is relativelysimple.

Script

Manager

Cloud Provider B API

Cloud Provider A

API

VM …

API / Service Call CSAR Import Execution via SSH Connection

SOAP+HTTP

…

SSH

REST+HTTP

…

Cloud Provider B Mgmt. IA

Apache Install. Script IA

SSH

Cloud Provider A Mgmt. IA

PHP Mod. Install. Script IA

OpenTOSCA Runtime Environment HTTP

HTTP

Operation Invoker

SOAP Plugin

Script Plugin

REST Plugin

U

Un

ified In

terface

Plan

CSAR (topology & plans)

Figure 4: Improved architecture providing a unified invocation interface for plans.

5.2 Improved Architecture with UnifiedInvocation Interface

Based on the state of OpenTOSCA without a unifiedinvocation interface presented before, Figure 4 out-lines how we improved OpenTOSCA’s architecture toprovide a unified invocation interface to plans. Thus,we implemented an additional component, namely theOperation Invoker acting as a bus in the sense of a ser-vice bus (Chappell, 2004). This component provides aunified interface to plans to invoke operations. In con-trast to the original architecture outlined in Figure 3,the plan does only communicate with the single unifiedinterface of the Operation Invoker. Technically, theunified interface is implemented as SOAP-based Webservice. However, it could alternatively or additionallymake the interface accessible through a RESTful Webservice or any other communication protocol.

The unified interface enables loose coupling be-tween plans and IAs. When a particular operation iscalled through the Operation Invoker, it checks whatkind of IA is available to execute the operation. Then,it checks whether there is a plugin registered that canexecute IAs of the given type (e.g., an IA of type SOAPor of type REST). In case there is a corresponding plu-gin, this plugin gets invoked, which itself invokes thecorresponding IA. The Operation Invoker is extensibleby adding plugins to it enabling OpenTOSCA to pro-cess any kind of IA. These plugins are implementedusing OSGi12.

Leitner et al. (2009) and De Antonellis et al. (2006)present solutions similar to the Operation Invoker inorder to dynamically invoke different kinds of Web ser-vices. However, these solutions are limited to serviceinvocation and do not consider the execution of arbi-trary executables such as scripts on a VM. In case ofdeploying and managing Cloud applications, serviceinvocations do typically only cover provisioning tasks,e.g., creating a new VM. The actions to install and

12OSGi: http://www.osgi.org

configure application components on the VM are typi-cally implemented as scripts. We discussed this fact inSection 2, especially in the context of the tools such asChef or Puppet originating in the DevOps community.Thus, it is essential for the Operation Invoker and theunified invocation interface that it provides a meansto manage and monitor the execution of scripts. To beable to easily combine different kinds of scripts suchas Chef recipes or Unix shell scripts the OperationInvoker has to deal with their individual invocationmechanisms and their way of handling input and out-put.

We decided to create the Script Plugin to enablethe Operation Invoker to deal with IAs that are im-plemented as scripts. However, the actual logic fordealing with the idiosyncrasies of different types ofscripts is realized by a separate reusable component,namely the Script Manager, which is used by the Op-eration Invoker’s Script Plugin. When a plan invokesan operation that is implemented as a script, the Ser-vice Invoker calls the Script Manager and passes thereferences to the script files, some meta informationsuch as the type of the script, and the context such asthe properties of the node of which the particular op-eration belongs to. The following XML listing showsan example for a message that is created by the ScriptPlugin when a plan invokes the install operation of theSugarCRM App node:

1 <Definitions ...

2 targetNamespace="http://www.opentosca.org/script"

3 xmlns="http://.../tosca"

4 xmlns:toscaBase="http://.../toscaBaseTypes"

5 xmlns:s="http://www.opentosca.org/script">

6

7 <ArtifactTemplate ... type="toscaBase:ScriptArtifact">

8 <Properties>

9 <toscaBase:ScriptArtifactProperties ...>

10 <ScriptLanguage>sh</ScriptLanguage>

11 <PrimaryScript>scripts/install.sh</PrimaryScript>

12 </toscaBase:ScriptArtifactProperties>

13 </Properties>

14 <ArtifactReferences>

15 <ArtifactReference reference="scripts/install.sh" />

16 </ArtifactReferences>

17 </ArtifactTemplate>

18

19 <s:ArtifactContext>

20 <!-- OpenTOSCA’s RESTful API to access CSAR content -->

21 <Files url="http://localhost/.../CSARs/SugarCRM/" />

22

23 <Operation>

24 <InputParameter name="licenseKey" type="string">

25 DUMMY_KEY

26 </InputParameter>

27 <OutputParameter name="stdout" type="string" />

28 </Operation>

29

30 <Node>

31 <!-- properties of SugarCRM App node -->

32 <NodeProperties nodeTypeName="SugarCRMApp">

33 <!-- admin password, app settings, etc. -->

34 </NodeProperties>

35

36 <!-- properties of server node on which the

37 SugarCRM App node is hosted -->

38 <HostProperties nodeTypeName="UbuntuLinuxServer">

39 <!-- public DNS address, SSH credentials, etc. -->

40 </HostProperties>

41 </Node>

42 </s:ArtifactContext>

43 </Definitions>

This message is then sent to the Script Manager.First, the script files (line 15) are retrieved from Open-TOSCA’s RESTful API endpoint (line 21). Second, theScript Manager establishes, for instance, an SSH con-nection to copy the script files to the target VM, to setthe corresponding environment variables, to executethe scripts, and to retrieve the result of the execution.The Operation Invoker’s Script Plugin uses a RESTfulAPI provided by the Script Manager to monitor the sta-tus of the execution and to finally retrieve the output topass it back to the plan through the unified invocationinterface. Such a message is structured as shown inthe following XML listing:

1 <body>

2 <status>completed</status>

3 <output>

4 <param>

5 <name>stdout</name>

6 <type>string</type>

7 <value>SugarCRM installed successfully</value>

8 </param>

9 </output>

10 </body>

We evaluated our concepts based on the improvedarchitecture of OpenTOSCA to show that our solutionproposal can be implemented in practice to addressthe issues outlined in Section 2. The following sectiondiscusses the evaluation in more detail.

6 EVALUATION

Based on the topology of SugarCRM described in Sec-tion 3 we show that the concepts and the improvedarchitecture presented in the previous Section 5 canbe implemented in practice to address the issues dis-cussed in Section 2. The overarching build plan tocreate new instances of SugarCRM is implemented us-ing BPEL (OASIS, 2007). The main reason for usingstandards-based workflow languages as proposed inTOSCA is to benefit from the workflows’ advantagessuch as recoverability and to reuse existing workflowengines for plan execution. However, the plan’s imple-mentation does not rely on any unique feature of BPEL.If certain workflow properties such as recoverabilityor compensation are not required for a particular planit could also be implemented, for instance, using ascripting language such as Ruby or Python.

For evaluation purposes we created two CSARsincluding a build plan for each of them: (i) the originalone does not use the Operation Invoker at all, so thebuild plan directly invokes Web services provided bylocal IAs bound to certain operations. The IAs’ imple-mentation is part of the CSAR. Consequently, a localwrapper IA was created to copy scripts on VMs and ex-ecute these scripts because a BPEL plan cannot do thisdirectly. (ii) The improved CSAR’s build plan invokesall operations through the Operation Invoker, meaningthere is no direct dependency to any IA. Furthermore,there is no IA needed to invoke scripts because thistask is delegated to the Script Manager. By using theOperation Invoker for each operation invocation cen-tralized monitoring can be implemented because allinput and output is going through a central component.Table 1 summarizes the evaluation results showing that(i) the complexity (measured as the number of XMLelements in the BPEL plan) of the improved CSAR’sbuild plan is lower, so plan creation gets simplified byusing the Operation Invoker. This is mainly becausemany low-level actions such as copying scripts to thetarget machine do not appear in the plan. (ii) In con-trast to the original CSAR the improved one does notrequire a special IA for invoking scripts because the

Table 1: Evaluation Results

CSARs: Original Improved

Complexity of build plan (num-ber of XML elements)

563 161

Wrapper IA for script invocation yes no

IAs exchangeable withoutchanging plans

no yes

Operation Invoker uses the Script Manager for thispurpose. (iii) IAs can be arbitrarily exchanged in caseof the improved CSAR because the plan only pointsto the operations that need to be invoked. Then, theOperation Invoker deals with the IAs and invokes themaccordingly.

7 RELATED WORK

Invoking Web services dynamically by using somekind of unified invocation interface was discussed be-fore (Leitner et al., 2009; De Antonellis et al., 2006).These approaches do not consider the invocation ofarbitrary management operations such as Chef recipesor Unix shell scripts. However, their invocation is ofutmost importance in case of creating managementplans because many operations such as installing andconfiguring application components are implementedas scripts. In the field of multi-cloud research there isrelated work (Petcu et al., 2011; Moscato et al., 2011;Sampaio and Mendonca, 2011) proposing conceptsand architectures to talk to different Cloud providersusing a unified API. Only some of them (Liu et al.,2011) marginally consider the invocation of scriptson VMs in the target Cloud. Most of the time it isassumed that application components are bundled anddeployed as virtual image files, e.g., using OVF.

In terms of provisioning resources such as VMs,libraries (e.g., jclouds13 and fog14) enable the abstrac-tion of specific Cloud provider APIs. However, theirfunctionality is limited to provisioning tasks and theycan only be used in a programmatic manner. Conse-quently, a standards-based plan (e.g., based on BPELor BPMN) cannot use such libraries directly without awrapper exposing the libraries’ functionality as Webservices. Beside these libraries, approaches such ascloud-init15 can be used to run scripts on a VM whenit gets started. This may work for the initial deploy-ment of application components. However, arbitrarymanagement operations such as a database backup thatneed to be performed later cannot be covered by thisapproach.

Some DevOps approaches can also perform pro-visioning actions. However, they are either bound tospecific Cloud providers such as AWS OpsWorks16,or they are mainly used as a command-line tool suchas Chef’s knife17 and Juju18. Beside the DevOps tools

13jclouds: http://jclouds.incubator.apache.org14fog: http://fog.io15cloud-init: http://launchpad.net/cloud-init16AWS OpsWorks: http://aws.amazon.com/opsworks17Knife: http://docs.opscode.com/knife.html18Juju: http://juju.ubuntu.com

such as Chef or Puppet, there is another category oftools emerging. These are in particular platform-as-a-service (PaaS) frameworks such as Cloud Foundry19.Their goal is to provide an integrated environment,namely a PaaS environment (Mell and Grance, 2011),for deploying and running applications and all theirmanagement processes. However, standards such asTOSCA are not considered there.

8 CONCLUSIONS ANDFUTURE WORK

The unified invocation interface presented in Section 5cleanly decouples overarching management plans (e.g.,the application’s build plan) from their underlying man-agement operations (e.g., IAs implemented as Chefrecipes and Unix shell scripts). The Script Managerused to invoke management operations implementedas scripts can be arbitrarily extended to support theexecution of any kind of scripts. This enables reusingexisting management operations published by the Dev-Ops community that can be embedded into CSARs toimplement certain operations. Finally, IAs exposingSOAP-based or RESTful Web services (e.g., to provi-sion a new VM) can also be invoked by a plan throughthe Operation Invoker without binding the plan to acertain Web service. As a result, management plans fo-cus on the actual orchestration of different operationsand thus do not have any dependency on particularIAs or scripts. Our evaluation presented in Section 6confirmed that this approach can be implemented inpractice. Furthermore, the complexity of plans can benotably decreased.

In terms of future work we aim to extend our pro-totype in two dimensions: (i) extending the ScriptManager to process a wide range of existing manage-ment operations (Puppet, Juju, etc.) and (ii) exposingthe Operation Invoker’s unified interface as RESTfulWeb service to make it directly usable for scripts imple-mented in Ruby, Python, etc. This enables the imple-mentation of plans based on scripting languages as analternative to workflows. Provisioning libraries suchas jclouds mentioned in Section 7 can be wrapped asIAs to be reused in different CSARs for provisioningtasks.

ACKNOWLEDGEMENTS

This work was partially funded by the BMWi projectCloudCycle (01MD11023).

19Cloud Foundry: http://cloudfoundry.org

REFERENCES

Binz, T., Breitenbucher, U., Haupt, F., Kopp, O., Leymann,F., Nowak, A., and Wagner, S. (2013). OpenTOSCA -A Runtime for TOSCA-based Cloud Applications. InProceedings of 11th International Conference on Service-Oriented Computing (ICSOC’13), volume 8274 of LNCS,pages 694–697. Springer Berlin Heidelberg.

Binz, T., Breiter, G., Leymann, F., and Spatzier, T. (2012).Portable Cloud Services Using TOSCA. Internet Com-puting, IEEE, 16(3):80–85.

Breitenbucher, U., Binz, T., Kopp, O., Leymann, F., and Wet-tinger, J. (2013). Integrated Cloud Application Provision-ing: Interconnecting Service-centric and Script-centricManagement Technologies. In Proceedings of the 21st

International Conference on Cooperative Information Sys-tems (CoopIS 2013).

Chappell, D. A. (2004). Enterprise Service Bus. O’Reilly.

De Antonellis, V., Melchiori, M., De Santis, L., Mecella, M.,Mussi, E., Pernici, B., and Plebani, P. (2006). A layeredarchitecture for flexible Web service invocation. Software:Practice and Experience, 36(2):191–223.

Delaet, T., Joosen, W., and Vanbrabant, B. (2010). A Surveyof System Configuration Tools. In Proceedings of the24th Large Installations Systems Administration (LISA)conference.

Gunther, S., Haupt, M., and Splieth, M. (2010). UtilizingInternal Domain-Specific Languages for Deployment andMaintenance of IT Infrastructures. Technical report, VeryLarge Business Applications Lab Magdeburg, Fakultat furInformatik, Otto-von-Guericke-Universitat Magdeburg.

Humble, J. and Molesky, J. (2011). Why Enterprises MustAdopt Devops to Enable Continuous Delivery. Cutter ITJournal, 24(8):6.

Kopp, O., Binz, T., Breitenbucher, U., and Leymann, F.(2012). BPMN4TOSCA: A Domain-Specific Languageto Model Management Plans for Composite Applications.In Business Process Model and Notation, volume 125 ofLecture Notes in Business Information Processing, pages38–52.

Kopp, O., Eberle, H., Leymann, F., and Unger, T. (2010).The Subprocess Spectrum. In Proceedings of the BusinessProcess and Services Computing Conference: BPSC 2010,volume P-177 of Lecture Notes in Informatics, pages 267–279. Gesellschaft fur Informatik e.V. (GI).

Leitner, P., Rosenberg, F., and Dustdar, S. (2009). Daios:Efficient Dynamic Web Service Invocation. Internet Com-puting, IEEE, 13(3):72–80.

Leymann, F. (2009). Cloud Computing: The Next Revo-lution in IT. In Photogrammetric Week ’09. WichmannVerlag.

Liu, T., Katsuno, Y., Sun, K., Li, Y., Kushida, T., Chen,Y., and Itakura, M. (2011). Multi cloud managementfor unified cloud services across cloud sites. In CloudComputing and Intelligence Systems (CCIS), 2011 IEEEInternational Conference on, pages 164–169.

Loope, J. (2011). Managing Infrastructure with Puppet.O’Reilly Media, Inc.

Manolescu, D.-A. and Johnson, R. E. (2001). Micro-Workflow: A Workflow Architecture Supporting Composi-tional Object-oriented Software Development. Universityof Illinois at Urbana-Champaign.

Mell, P. and Grance, T. (2011). The NIST Definition ofCloud Computing. National Institute of Standards andTechnology.

Moscato, F., Aversa, R., Di Martino, B., Fortis, T., andMunteanu, V. (2011). An analysis of mosaic ontologyfor cloud resources annotation. In Computer Science andInformation Systems (FedCSIS), 2011 Federated Confer-ence on, pages 973–980.

Nelson-Smith, S. (2011). Test-Driven Infrastructure withChef. O’Reilly Media, Inc.

OASIS (2007). Web Services Business Process ExecutionLanguage (BPEL) Version 2.0.

OASIS (2013). Topology and Orchestration Specificationfor Cloud Applications (TOSCA) Version 1.0, CommitteeSpecification 01.

OMG (2011). Business Process Model and Notation(BPMN) Version 2.0.

Pepple, K. (2011). Deploying OpenStack. O’Reilly Media.

Pesic, M. and van der Aalst, W. M. (2006). A DeclarativeApproach for Flexible Business Processes Management.In Business Process Management Workshops, pages 169–180. Springer.

Petcu, D., Craciun, C., Neagul, M., Lazcanotegui, I., andRak, M. (2011). Building an interoperability api for skycomputing. In High Performance Computing and Simu-lation (HPCS), 2011 International Conference on, pages405–411.

Sampaio, A. and Mendonca, N. (2011). Uni4cloud: Anapproach based on open standards for deployment andmanagement of multi-cloud applications. In Proceedingsof the 2Nd International Workshop on Software Engineer-ing for Cloud Computing, SECLOUD ’11, pages 15–21.ACM.

Wettinger, J., Behrendt, M., Binz, T., Breitenbucher, U.,Breiter, G., Leymann, F., Moser, S., Schwertle, I., andSpatzier, T. (2013). Integrating Configuration Man-agement with Model-Driven Cloud Management Basedon TOSCA. In Proceedings of the 3rd InternationalConference on Cloud Computing and Services Science(CLOSER). SciTePress.

Zamboni, D. (2012). Learning CFEngine 3: AutomatedSystem Administration for Sites of Any Size. O’ReillyMedia, Inc.