The SePaDe System: Packaging Entire XaaS Layers for

Automatically Deploying and Managing Applications

alm

an K

epes, Uwe Breitenb

ucher and Frank Leymann

Institute of Architecture of Application Systems, University of Stuttgart, Stuttgart, Germany

Keywords:

Application Deployment, Application Management, Automation, Portability, TOSCA.

Abstract:

The multitude of cloud providers and technologies diminish the interoperability and portability of applications

by offering diverse and heterogeneous functionalities, APIs, and data models. Although there are integration

technologies that provide uniform interfaces that wrap proprietary APIs, the differences regarding the services

offered by providers, their functionality, and their management features are still major issues that impede

portability. In this paper, we tackle these issues by introducing the SePaDe System, which is a pluggable de-

ployment framework that abstracts from proprietary services, APIs, and data models in a new way: The system

builds upon reusable archive templates that contain (i) a deployment model for a certain kind of application

and (ii) all deployment and management logic required to provide deﬁned functionalities and management fea-

tures. Thus, by selecting appropriate templates, an application can be deployed on any infrastructure providing

the speciﬁed features. We validate the practical feasibility of the approach by a prototypical implementation

that is based on the TOSCA standard and present several case studies to evaluate its relevance.

1 INTRODUCTION

With the general acceptance of Cloud Computing,

problems related to availability of IT resources seem

to be diminished (Zhang et al., 2010). In Cloud Com-

puting, accessing compute, network, and storage ca-

pabilities can be categorized according to the NIST

(Mell and Grance, 2011) service models Software-

as-a-Service (SaaS), Platform-as-a-Service (PaaS),

and Infrastructure-as-a-Service (IaaS): SaaS deliv-

ers complete software applications from within the

cloud, while PaaS allows users to deploy their own

applications on already available, scalable, and con-

ﬁgurable hosting environments. IaaS allows a user to

instantiate and access virtual resources, such as vir-

tual machines and disks, which can be used to host the

users’ applications. While SaaS has the lowest man-

agement complexity, the complexity increases further

from PaaS to IaaS as more and more management

must be done by the user himself. For example, a user

does not have to manage the scalability of an SaaS

solution as this is done by the cloud provider’s infras-

tructure, whereas he has to explicitly specify scaling

rules when an application is hosted on an IaaS offer-

ing. Thus, depending on the users’ requirements, he

can select the most appropriate service model.

However, the multitude of vendors and their of-

ferings diminish the interoperability and portability of

applications with diverse and heterogeneous function-

ality, APIs, and data models. Although there are inte-

gration technologies that try to solve these issues on

the PaaS and IaaS layer by abstracting from propri-

etary APIs and data models (Hoare, 2016), the differ-

ences regarding (i) the services offered by providers,

(ii) their functionality, and (iii) their management fea-

tures are becoming increasingly challenging. Indeed,

such integration technologies help deploying appli-

cations on different clouds, but if required services,

functionalities, or management features are not pro-

vided by the selected provider, applications cannot

be deployed as desired. Thus, as the offerings of

providers cannot be conﬁgured arbitrarily and as there

are typically no natively-supported means to add re-

quired functionality or management features, this is

a serious portability problem—from the functional as

well as from the non-functional perspective.

In this paper, we tackle these issues. We in-

troduce the SePaDe System, which is a pluggable

deployment framework that abstracts from cloud

providers and technologies in a new way: instead

of providing uniﬁed interfaces that wrap proprietary

APIs and normalizing data models, which are the

typical approaches of integration technologies, the

SePaDe System builds upon the concept of searching,

626

Képes, K., Breitenbücher, U. and Leymann, F.

The SePaDe System: Packaging Entire XaaS Layers for Automatically Deploying and Managing Applications.

DOI: 10.5220/0006370206540663

In Proceedings of the 7th International Conference on Cloud Computing and Services Science (CLOSER 2017), pages 626-635

ISBN: 978-989-758-243-1

Custom *aaS Layer

APIs C

Services C

*aaS Layer 2

APIs 2

Services 2

Provider 2

Missing Application Portability

*aaS Layer 1

APIs 1

Services 1

Provider 1

App

Custom *aaS Layer

APIs C

Services C

*aaS Layer 1

APIs 1

Services 1

Provider 1

Custom Layers

*aaS Layer 2

APIs 2

Services 2

Provider 2

Layer Portability

*aaS Layer 1

APIs 1

Services 1

Provider 1

App

Custom *aaS Layer

APIs C

Services C

Figure 1: Overview of motivations for our work, ranging from issues of (i) missing application portability between different

*aaS providers, (ii) the need for custom functionality on top of *aaS providers, and (iii) the need for *aaS layers to be portable.

packaging and deploying Self-Manageable Applica-

tion Archive Templates (SMAART). SMAARTs are

reusable archives that contain (i) a deployment model

for a certain type of application on a certain infras-

tructure and (ii) all executables, e.g., shell scripts, re-

quired to deploy and manage the application to en-

able the functionalities and management features re-

quested. The goal of the system is to enable the user to

only specify the application ﬁles, the target infrastruc-

ture, and the desired features while the system auto-

matically deploys the application following these re-

quirements. We validate the practical feasibility by

a prototype based on the TOSCA standard (OASIS,

2013): By applying SePaDe to TOSCA, we add an

additional layer on top of TOSCA that enables users

to search suitable templates that can be used to au-

tomatically deploy given application ﬁles following

speciﬁed requirements. Moreover, we evaluate the

practical relevance of our approach with case studies

that show how different kinds of functionalities and

features that are not natively supported can be added

using the SePaDe System. Thus, besides increasing

the degree of portability, the proposed concept can be

also used to add new functionalities and features to

existing offerings in a reusable way. Please note that

our system does not replace existing technologies but

adds another layer of abstraction.

The remainder of this paper is structured as fol-

lows: In Section 2, we motivate our approach based

on the issue of portability. Afterwards, we present an

overview of the SePaDe System, its architecture, and

introduce the concept of SMAARTs in Section 3. We

present a TOSCA-based prototype in Section 4 while

Section 5 illustrates case studies. In Section 6 related

work is discussed, Section 7 concludes the paper and

outlines possible future work.

2 MOTIVATION &

STATE-OF-THE-ART

In this section, we discuss three motivating scenarios

that are difﬁcult to realize using state-of-the-art tech-

nologies (see scenarios in Figure 1).

2.1 Missing Application Portability

The application portability problem results from ven-

dors providing proprietary APIs, services, and data

models (see left side in Figure 1). As a result, de-

veloping applications on top of one provider’s APIs

raises the issue of vendor lock-in, which impedes

porting an application to another provider. Avail-

able integration technologies such as Nucleus (R

ock

and Kolb, 2016) tackle these issues by providing

generic APIs and data models that wrap proprietary

implementations. Also container technologies such as

Docker (Fink, 2014) tackle portability issues. How-

ever, these approaches do not solve portability issues

in general: if, for example, PaaS offerings of two dif-

ferent providers support deploying Docker contain-

ers, a container may be technically portable from a

functional point of view. However, if one provider of-

fers a required management feature, e.g., automated

scaling, that is not supported by the other provider,

the portability fails on the non-functional level. Thus,

de facto and de jure standards and technologies only

help partially regarding portability as they cannot sup-

port all variants that may be needed to get appli-

cations portable on the functional as well as on the

non-functional level. The same applies to integration

technologies: if one provider offers a service that is

not supported by another provider, an application is

The SePaDe System: Packaging Entire XaaS Layers for Automatically Deploying and Managing Applications

627

SePaDe System

SMAART Repository

I want to deploy this application…

Features

Auto-Scaling

with these features... on this infrastructure…

and I need these management operations.

Deploy()

PHP

Update()

Auto-Scaling

PHP

Deploy()

Update()

OpenStack

Ubuntu VM

Apache

PHP

PHP Module

OpenStack

Figure 2: Overview of the SePaDe approach.

not portable between these providers if this service is

mandatorily required.

2.2 Custom Layers

Deploying custom layers on top of existing resources

enables to use arbitrary hardware and eases the de-

ployment of applications on these (see middle in Fig-

ure 1). Applications can use available resources in a

transparent manner as they are developed on top of

chosen platforms, and, therefore, are not bound to a

speciﬁc environment. Especially within ﬁelds such as

the Internet of Things (Atzori et al., 2010), it is not

feasible to expect homogeneous resources. This trend

raises the need for portable platforms which can be

deployed on arbitrary resources. However, installing

and conﬁguring such layers is typically a complex,

knowledge-intensive, and time-consuming task that

requires automation. Our approach tackles this by en-

abling developers to build / reuse custom layers and to

ship them in automatically installable archives. This

enables to ship custom platforms which are highly

specialized for a particular domain.

2.3 Layer Portability

Enabling developers to use their preferred layers de-

creases the issue of vendor lock-in, e.g., when an ap-

plication is developed based on Cloud Foundry. By

making the platform portable, the application can be

migrated between different infrastructures, too (see

right side in Figure 1). However, if a provider does

not support all functions and features required by such

a platform, the same issue of portability raises up one

layer above. Nevertheless, bringing the whole plat-

form logic to where it is needed is one concept of our

approach. But in contrast to using a single portable

platform for this purpose, we present a generic ap-

proach that is not coupled to a certain platform tech-

nology, which enables selecting an appropriate imple-

mentation for the target environment.

3 THE SEPADE SYSTEM

In this section, we introduce the SePaDe System,

which is a pluggable deployment framework that ab-

stracts from cloud providers and technologies in a

completely new way. We ﬁrst present an overview of

the approach and detail the concepts in the following.

3.1 Overview of the Approach

The overall SePaDe approach is shown in Figure 2.

The SePaDe System enables users to deploy the appli-

cation automatically on a desired target infrastructure

without the need to deal with technical deployment

details. Thus, no technical expertise about deploy-

ment technologies such as Chef, virtualization tech-

nologies such as OpenStack, or cloud provider API

handling is required. Using the SePaDe System, the

user only has to specify the following information:

• Application ﬁles that shall be deployed as well as

the application’s type, for example, that the appli-

cation is implemented in PHP.

• Management features that have to be provided au-

tomatically during operation, for example, that the

application shall be automatically scaled.

• Target infrastructure on which the application

shall be deployed, e.g., a certain OpenStack in-

stallation or a cloud provider such as Amazon.

• Required Management operations that can be trig-

gered manually, for example, that an operation

must be provided to update the application ﬁles.

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

628

The SePaDe System is connected to a SMAART

Repository that contains reusable archive templates

(SMAARTs) for deploying applications (see next sub-

section for details). Each of these SMAARTs can be

used to deploy a certain type of application on a spe-

ciﬁc type of infrastructure and provides a deﬁned set

of management features and operations. As this in-

formation is annotated to each SMAART, the system

can match this information with the speciﬁed user re-

quirements and selects an appropriate SMAART for

deploying the application ﬁles. All required deploy-

ment and management logic is contained in these

SMAARTs, which provides a pluggable deployment

approach as reusable archives for arbitrary target in-

frastructures and requirements that can be developed.

Thus, the SePaDe System itself is a generic technol-

ogy that only executes the deployment and manage-

ment logic contained in SMAARTs and is, therefore,

not bound to a certain technology. Using the sys-

tem, users just have to upload their application ﬁles

and to specify the desired infrastructure as well as the

required functionalities and features, and the system

selects an appropriate SMAART to automatically de-

ploy the application following these requirements.

3.2 Self-Manageable Application

Archive Templates (SMAARTs)

Our approach is based on application packages

called Self-Manageable Application Archive Tem-

plates (SMAARTs), which are reusable archive tem-

plates that contain (i) a deployment model for a cer-

tain type of application on a certain infrastructure,

e.g., to deploy a PHP application on OpenStack. In

addition, (ii) a SMAART contains generic executa-

bles, e.g., scripts, required to deploy and manage this

type of application in a way that deﬁned functionali-

ties and management features are provided. The idea

of SMAARTs is to put the user’s application ﬁles into

a suitable archive template that matches the user’s re-

quirements, which is then deployed automatically us-

ing a deployment system that is capable of invoking

the contained deployment and management executa-

bles. We present a possible standards-based realiza-

tion of this approach in Section 4. Thus, by select-

ing a suitable SMAART from the repository that ful-

ﬁlls the users requirements and putting the user’s ap-

plication ﬁles into it, arbitrary deployments on vari-

ous infrastructures can be wrapped. This allows the

reuse of available SMAARTs for a certain applica-

tion type, a set of requested features, the speciﬁed

target infrastructure, and required management oper-

ations. Moreover, the generic management executa-

bles in SMAARTs enable the automated management

Deployment

Model

Application

Type

1 1

supports

contains

Management

Operation

Name

0..n

Management

Feature

Name

implements

SMAART

Management

Executable

Path

0..1 1

implements

0..n

1 1

supports

0..n

Path

Injection

Target

Infrastructure

Type

1 1

specifies supports

Figure 3: Meta-Model of Self-Manageable Application

Archive Templates (SMAARTs).

of the deployed application on runtime. These are ei-

ther triggered automatically by the runtime or invoked

by a user to execute a certain management operation.

The meta-model of SMAARTs as an ER model is

shown in Figure 3. A SMAART has an Application

Type property that speciﬁes the type of applications it

can deploy on a certain Target Infrastructure, which

is speciﬁed by the Deployment Model. Moreover, this

model describes all components and their relation-

ships that are involved in this deployment. Manage-

ment operations specify operations that can be explic-

itly invoked, e.g., to undeploy the application, while

Management Features are built-in features that are en-

forced automatically, for example, automated scaling.

The Injection Target is speciﬁed by the Deployment

Model and deﬁnes the path in the archive template to

which the application ﬁles must be copied. Manage-

ment Executables implement operations or features

and expect the application ﬁles exactly at this path.

To implement the deployment and management

executables, the SMAART concept speciﬁes no re-

strictions: Both, using low-level technologies such as

scripts to implement these operations as well as using

high-level orchestration approaches such as workﬂow

technology may be used. Especially, workﬂow tech-

nology provides several standards such as BPEL (OA-

SIS, 2007b) that is already used for automating the

provisioning of applications (Breitenb

ucher et al.,

2014). Of course, the employed deployment system

The SePaDe System: Packaging Entire XaaS Layers for Automatically Deploying and Managing Applications

629

Deployment Model

Application Type:

PHP

Injection Target:

PHPApp

Management

Features:

Auto-Scaling

Apache2

Ubuntu

14.04

OpenStack

Management

Operations:

Target Infrastructure:

OpenStack

deploy()

update()

deploy.bpel update.bpel

Ubuntu

14.04

Apache2

Proxy

Balancer

PHP5

PHPApp

Credentials: […]

User: ubuntu

PW: ubuntu

Port: 80

…

Figure 4: Example of a SMAART.

has to support the chosen technology. We will present

how to realize these concepts in Section 4 based on

the OpenTOSCA ecosystem.

Figure 4 shows an example for the deployment of a

PHP application on OpenStack, which is both spec-

iﬁed by the Application Type and Target Infrastruc-

ture. The SMAART contains a deployment model

and associated BPEL workﬂow that implements the

deploy() operation: the Management Executable de-

ploy.bpel installs the needed components such as the

Apache2 HTTP server and the PHP modules on an

Ubuntu virtual machine, which it provisions before

on an OpenStack installation. The workﬂow extracts

conﬁgurations, such as the HTTP port to be used, out

of the deployment model. User-speciﬁc information,

for example, the account information of the Open-

Stack to be used, are passed to the workﬂow via in-

put parameters. Moreover, the SMAART contains an

executable update.bpel that implements the operation

to update() the deployed ﬁles. Both operations are

exposed in the form of the Management Operations

property. Thus, it deﬁnes supported management op-

erations that can be triggered by the system or the

user. Moreover, the SMAART also supports auto-

scaling, which is speciﬁed by the Management Fea-

tures property. In this example, installing and conﬁg-

uring auto-scaling is the responsibility of the deploy-

ment workﬂow. To enable the system to put the user’s

application ﬁles into the archive, the Injection Target

speciﬁes the path where the ﬁles need to be stored.

The generic deployment and management workﬂows

expect these application ﬁles exactly at this path.

3.3 SePaDe System & Matchmaking

In this section, we present the system architecture of

the SePaDe system (see Figure 5). The main func-

tionalities of the system are Selection, Packaging, and

Deployment, hence SePaDe. In the following, we de-

scribe how the system enables the deployment of ap-

plications with a suitable SMAART.

Users specify their requirements in the user inter-

face of the system. They enter (i) the application ﬁles

to be deployed and their Application Type, e.g., a PHP

Application, (ii) desired Management Features such

as auto-scaling, (iii) the Target Infrastructure, e.g.,

a certain OpenStack installation, and ﬁnally (iv) the

Management Operations they need, e.g., a deploy()

and an update() operation. Of course, the user

does not have to specify all of these requirements.

For example, if the user only requests a special ap-

plication type, features, and management operations

but no special infrastructure, multiple SMAARTs that

are based on different infrastructures are offered and

the user selects one of them based on his prefer-

ences. When such a request arrives at the system,

the SMAART Selector starts querying the SMAART

Repository for a suitable SMAART that matches these

inputs. To be a suitable SMAART, the following con-

ditions must be fulﬁlled:

• The entered Application Type must match the Ap-

plication Type of the candidate SMAART

• The entered Target Infrastructure must match the

supported Target Infrastructure of the candidate

• The entered Management Operations must be a

subset of the Management Operations supported

by the candidate SMAART

• The entered Management Features must be a sub-

set of the Management Features supported by the

candidate SMAART

Based on these matchmaking rules, the SMAART Se-

lector calculates a possible set of suitable SMAARTs

that fulﬁll the requested criteria and selects afterwards

one option from the set, e.g., based on different prices

if SMAARTs are available for different providers. If

no SMAART can be found, the application cannot be

deployed in the requested way. After this selection

step, the selected SMAART is passed to the SMAART

Packager together with the given application ﬁles.

This packager injects the passed application ﬁles to

the path speciﬁed by the Injection Target property

of the SMAART’s Deployment Model. Please note,

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

630

Package

PHP

OpenStack

Scaling

Deploy()

PHP

SMAART Repository

SMAART Selector

DeploySelect

Features

Auto-Scaling

Deploy()

Update()

OpenStack

SMAART Packager

PHP

User-specified

requirements

PHP

Apache

Ubuntu

PHP

OpenStack

Deployment System

Matchmaking

Figure 5: Overview of the SePaDe System Architecture.

all Management Executables in the SMAART expect

these ﬁles exactly there, thus, they can be executed

automatically after this injection.

Finally, the generated archive is shipped to a De-

ployment System that is capable of executing the Man-

agement Executables contained in the SMAART. To

deploy an instance of this archive, i.e., to deploy the

entered application ﬁles, the Deployment System in-

vokes the Management Executable that implements

the deploy() operation of the SMAART. Thus, this

operation must be provided by each SMAART.

4 A TOSCA-BASED PROTOTYPE

In this section, we describe how we validated our

approach using the TOSCA standard. We ﬁrst de-

scribe the standard in Section 4.1, afterwards we de-

scribe how we mapped our SMAART meta-model to

TOSCA in Section 4.2. In Section 4.3, we present our

prototype that implements the SePaDe concept based

on TOSCA CSARs and the open-source TOSCA en-

vironment OpenTOSCA (Binz et al., 2013).

4.1 An Introduction to TOSCA

In this section, we present an overview of the Topol-

ogy and Orchestration Speciﬁcation for Cloud Appli-

cations (TOSCA) (OASIS, 2013), which enables au-

tomating the deployment and management of appli-

cations. TOSCA is an OASIS standard that speci-

ﬁes a meta-model for modelling the structure of cloud

applications in the form of so-called Topology Tem-

plates. A Topology Template is a colored and at-

tributed graph wherein nodes represent the compo-

nents (Node Templates) of an application, and edges

their relationships (Relationship Templates). Both

Node and Relationship Templates are typed by Node

Types or Relationship Types, respectively, specifying

a template’s semantics. Node Types expose Man-

agement Operations to manipulate instances of these

types, e.g., a VSphere Node Type may expose op-

erations to start and stop virtual machines. Thus,

using these concepts various kinds of cloud infras-

tructures and technologies can be integrated as Node

Types. Further, both types deﬁne a set of Proper-

ties that represent conﬁgurations of instances. A rela-

tionship between components can represent arbitrary

types of relations speciﬁed by the corresponding Re-

lationship Type, e.g., a PHP Application Node Tem-

plate is hostedOn a Apache 2 Node Template. Thus,

as TOSCA’s type system is extensible, arbitrary ap-

plication structures of components and their relation-

ships can be modelled.

TOSCA deﬁnes two types of artifacts: Deploy-

ment Artifacts (DAs) implement the business func-

tionality of a Node Template, for example, a DA for a

PHP Application Node Template are the PHP ﬁles im-

plementing the application. The second type is called

Implementation Artifacts (IAs). IAs are used to im-

The SePaDe System: Packaging Entire XaaS Layers for Automatically Deploying and Managing Applications

631

1 <ServiceTemplate id="PHP_OpenStack" ...>

2 <Tags>

3 <Tag name="ApplicationType" value=

4 "{http://.../Types}PHP5Application"/>

5 <Tag name="InjectionTarget" value="DA12"/>

6 <Tag name="TargetInfrastructure" value=

7 "OpenStack-Liberty-12"/>

8 <Tag name="Features" value="AutoScaling"/>

9 </Tags>

10 <BoundaryDefinitions>

11 <Interfaces>

12 <Interface name="SePaDe-Lifecycle">

13 <Operation name="deploy">

14 <Plan planRef="BuildPlan"/>

15 </Operation>

16 <Operation name="update">

17 <Plan planRef="UpdatePlan"/>

18 ...

19 </BoundaryDefinitions>

20 <TopologyTemplate>

21 <NodeTemplates>

22 <NodeTemplate name="App" ...

Figure 6: TOSCA Service Template for SMAART.

plement the management operations deﬁned by Node

Types, e.g., . To orchestrate operations, TOSCA de-

ﬁnes the concept of Management Plans, which are ex-

ecutable workﬂow models that implement a certain

management functionality, e.g., the provisioning of

the entire application. All these elements are summa-

rized in a Service Template. Moreover, TOSCA de-

ﬁnes Cloud Service Archives (CSARs) to package all

the mentioned elements into a self-contained archive

ﬁle. Thus, TOSCA enables to embed all required soft-

ware and models into such CSARs, which can be ex-

ecuted by standard-compliant runtimes to deploy and

manage the application.

4.2 Mapping SePaDe to TOSCA

We map the SMAART meta-model (cf. Figure 3)

to TOSCA as follows. SMAARTs are realized as

TOSCA CSARs that contain a Service Template as

shown in listing 6. For modelling the Application

Type, Management Features, and Target Infrastruc-

ture supported by the SMAART, we used the concept

of Tag-elements that can be attached to TOSCA Ser-

vice Templates (lines 2-9). To realize the Deployment

Model of the SMAART meta-model, we use TOSCA

Topology Templates (lines 20-22). Management Op-

erations supported by the SMAART are modelled us-

ing the Boundary Deﬁnitions of a Service Template,

which contains interfaces that specify invokable oper-

ations (lines 10-19). Management Executables are re-

alized as Implementation Artifacts that implement the

operations exposed in the Boundary Deﬁnitions. The

Injection Target is modelled as a Tag, whose value

points to a Deployment Artifact’s name to which the

entered application ﬁles shall be attached. For at-

taching these ﬁles, only the referenced Deployment

Artifact’s ﬁle path property has to be updated. Us-

ing this injection mechanism, no Implementation Ar-

tifacts (i.e., Management Executables) are affected as

these only refer to Deployment Artifacts by name and

extract the ﬁle path property on runtime. Thus, the

injection is seamless and does not affect executables.

As a result, many concepts of SePaDe can be mapped

to the native meta-model of TOSCA. Thus applying

the SePaDes approach to TOSCA adds an additional

layer on top of TOSCA (based on the SMAART meta-

model) for searching suitable templates that can be

used to automatically deploy application ﬁles follow-

ing speciﬁed requirements.

4.3 Prototypical Implementation

In this section, we present our TOSCA-based proto-

type. We implemented the SePaDe concept into two

systems: We extended (i) the open-source TOSCA

modelling tool Winery

(Kopp et al., 2013) as well

as (ii) the open-source TOSCA runtime environment

OpenTOSCA

(Binz et al., 2013).

In the following, we describe the RESTful API

which was implemented inside the OpenTOSCA

Container to provide SePaDe’s functionality. The API

expects a single HTTP POST request with the fol-

lowing data: (i) the application ﬁle to be deployed,

(ii) an XML QName indicating a TOSCA Artifact-

Type which is the Application Type, (iii) a set of XML

QNames denoting TOSCA Node Types that serves

ﬁner selection, (iv) a single XML QName denoting

a TOSCA Node Type that serves as Target Infrastruc-

ture, (v) a set of strings stating the requested features

for the application. For (i), we expect a single ﬁle

which can range from archive ﬁles to binaries. This

ﬁle is typed through the QName of the TOSCA Ar-

tifact Type speciﬁed by (ii). For (iii), we expect a

possibly empty set of TOSCA Node Types speciﬁed

as XML QNames which indicates that the SMAART

to be selected must contain Node Templates of the

given Node Types. This enables a ﬁner-grained se-

lection of SMAARTs. Our approach enables the de-

ployment of applications on a target infrastructure and

environment speciﬁed by (iv) with a single QName

pointing to the desired target in the form of a Node

Type. This Node Type speciﬁes the infrastructure re-

quested, e.g., OpenStack, Raspberry Pi, or Amazon

AWS. As the last part, for (v) we expect an also pos-

sibly empty set of strings, which state requested Man-

https://projects.eclipse.org/projects/soa.winery

https://github.com/OpenTOSCA/container

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

632

Application Type:

PHP

Injection Target:

PHPApp

Management

Features:

Auto-Scaling

Apache2

Ubuntu

14.04

OpenStack

Management

Operations:

Target Infrastructure:

OpenStack

deploy()

scale-out()

Ubuntu

14.04

Apache2

Proxy

Balancer

PHP5

PHPApp

Application Type:

PHP

Injection Target:

PHPApp

Management

Features:

Auto-Scaling

Apache2

Raspberry Pi

Management

Operations:

Target Infrastructure:

Raspberry Pi

deploy()

scale-out()

Raspbian

Jessie

Apache2

Proxy

Balancer

PHP5

PHPApp

Apache2

New

Raspberry Pi

Raspbian

Jessie

PHP5

PHPApp

add-Pi()

Figure 7: Case studies showing a custom layer for PHP apps and make the layer portable on OpenStack and Raspberry Pi

agement Features of the SMAART. These strings are

then checked against the tags deﬁned inside TOSCA

Service Templates implementing our SMAART meta-

model. After sending such a request to the API, it will

search inside the back-end for suitable SMAARTs,

and after ﬁnding a suitable SMAART, the entered ﬁle

is injected and the resulting CSAR is deployed on

the OpenTOSCA container. To actually provision the

application, i.e., to execute the deploy() operation,

the user has to enter required input parameters into a

user interface, e.g., credentials for OpenStack or the

MAC-Addresses of the Raspberry Pis that have to be

used. Then OpenTOSCA executes the associated exe-

cutable for the deploy() operation, which is a BPEL

or BPMN workﬂow model in our prototype.

5 CASE STUDIES

How our system complements existing integration

technologies regarding the issue of application porta-

bility (Section 2.1) has been shown throughout the

paper: by specifying non-functional requirements re-

garding management features, our approach is capa-

ble of providing them. For example, the SMAART

(see Figure 4) used throughout the paper for deploy-

ing PHP applications on OpenStack shows how auto-

scaling can be provided regardless of the actually used

underlying system. To validate our concepts also re-

garding custom layers (Section 2.2) and layer porta-

bility (Section 2.3), we describe two case studies in

this section with the goal to provision a single PHP

application on different infrastructures with the means

of packaging a custom layer in different SMAARTs.

The SMAART on the left in Figure 7 resembles

our example SMAART from Figure 4, with the dif-

ference in available Management Operations. Here

we altered the package to expose a scale-out() in-

stead of an update() operation to show how we man-

age to scale applications on different infrastructures.

While in the example version of the SMAART users

can request an update of the applications’ topology

by executing update(), in this case the SMAART

is able to scale the PHP application by executing the

scale-out() operation. This is achieved with the

TOSCA Plan implementing the scale-out() oper-

ation, which at runtime can instantiate a new PHP

application stack on top of OpenStack, i.e., creating

new instances of the Ubuntu 14.04 virtual machine,

the Apache2 server, the PHP5 module, and the PH-

PApp application. After creating such a new stack the

scale-out() operation additionally adds the end-

point of the stack to the Proxy Balancer nodes’ con-

ﬁguration to serve arriving request to it, enabling the

overall application to serve more requests, thus scale.

To show that our approach enables layer portability

the second SMAART on the right in Figure 7 is also

usable for PHP applications and implements the same

Management Operations as the ﬁrst (deploy() and

scale-out()). Difference between the SMAARTs is

the underlying infrastructure the PHP application will

be hosted on, instead of an OpenStack cloud the right

SMAART enables the usage of Raspberry Pis as the

infrastructure. At the beginning of deploying such a

SMAART all relevant components for the PHP appli-

cation are installed, these components are analogous

to the OpenStack case, but instead of installing the

load balancer stack (Apache2 and Proxy Balancer)

and PHP application stack (Apache2, PHP5 and PH-

PApp) on two distinct Ubuntu 14.04 instances, they

are installed on the same initial Raspberry Pi at de-

The SePaDe System: Packaging Entire XaaS Layers for Automatically Deploying and Managing Applications

633

ployment time. After deployment the load balancer is

listening on the intended application port, e.g., port

80, and redirects requests to the application. As a

single Pi is not sufﬁcient to keep up with large re-

quest loads, the package exposes the add-Pi() opera-

tion. Users can use this operation to add additional re-

sources at runtime to the topology, which can then be

used by the scale-out() operation to scale the over-

all application. The add-Pi() operation will when

executed add a Raspberry Pi to the instance model,

i.e, by creating a new Raspberry Pi node (New Rasp-

berry Pi) and a node for its installed operating system

(Raspbian Jessie on the right in the topology). Prop-

erties of the created nodes are taken from the input of

the add-Pi() operation, containing information such

as the MAC and/or IP address and credentials. When

the system needs to scale, the scale-out() operation

would detect the new Raspberry Pi nodes (hardware

and os) and install a whole new stack of the PHP Ap-

plication, i.e., installing an Apache2, a PHP5 and a

PHPApp node and add the new PHP application end-

point to the Proxy Balancers’ conﬁguration.

In summary, we showed how to extend available

APIs with our approach to build custom layers by

making management operations portable. Addition-

ally, these case studies show layer portability by en-

abling the user to either deploy his PHP application

on an OpenStack cloud or on a physical Raspberry Pi.

6 RELATED WORKS

Related works are concepts that introduce a layer

on top of multiple PaaS providers, that reuse tem-

plates for cloud applications, and which allow users

to develop applications without committing to a spe-

ciﬁc provider. In summary most approaches solve

the challenges of PaaS platform interoperability by

deﬁning their own API on top of PaaS platforms.

Hoare (Hoare, 2016) studied state-of-the-art research

in PaaS interoperability and identiﬁed, beside the API

approaches, the use of techniques in the ﬁeld of the

semantic Web. Loutas et al. (Loutas et al., 2011) in-

troduce a PaaS Semantic Interoperability Framework

that contains descriptions of different PaaS platforms

to resolve interoperability issues. Yangui et al. (Yan-

gui et al., 2013) describe a method on how to use

the OASIS standard Service Component Architecture

(SCA) (OASIS, 2007a) as a model for composite ser-

vices. With these models a split into a set of services

is taking place, which are afterwards deployed to so-

called Micro-Containers which may already run in-

side one of the PaaS solutions. Yangui et al. argue that

these Micro-Containers must be implemented once to

be deployable into new PaaS environments, which in

return allows the set of services to be deployed on

those. R

ock et al. (R

ock and Kolb, 2016) tackle the

problem of API differences between PaaS providers

by introducing an abstract API on top. The general

concept behind the API is to use adapters for different

PaaS providers while the API itself exposes the ca-

pabilities of the environments as abstracted objects to

the user, e.g., ranging from a generic Service to an Ap-

plication. Similar to this is the Cloud4SOA platform

by D’Andria et al. (D’Andria et al., 2012), which is

also based on adapters for each supported PaaS plat-

form. In contrast to our approach, these works in-

troduce another API on top of the existing solutions,

which nevertheless binds the applications against a

particular interface. Our approach enables incorpo-

rating entire PaaS platforms inside a single SMAART,

which allows to use the desired platform. It also en-

ables installing platforms on bare metal, which ad-

ditionally reduces portability issues. Yamato et al.

(Yamato et al., 2014) introduce a Template Manage-

ment Server which stores OpenStack HOT Templates

for reuse by its users. The server enables user to cre-

ate, share, extract from running OpenStack resources

and update of templates to reﬂect changes in the en-

vironment. Additionally, the server is responsible

for instantiating the templates by creating virtual re-

sources inside the target OpenStack cloud. While this

approach leverages a similar idea as our paper, it is

limited to the OpenStack cloud, our approach can be

implemented for arbitrary technologies as shown by

the case studies. Another approach based around tem-

plates is presented by Gao et al. (Gao et al., 2012).

Templates in their approach are virtual machine im-

ages that incorporate different software packages and

services. Users can select an appropriate template

from a repository and use it to provision their services.

After such a request is made, the system selects ap-

propriate cloud resources based on criteria given by

the user to install the image and afterwards the ser-

vices to run on those resources. While this approach

is related to our method, it only deals with the de-

ployment on virtual machines, our approach also in-

corporates bare-metal and arbitrary *aaS resources.

Nguyen et al. (Nguyen et al., 2012) introduce the

Blueprints meta-model, which specify a cloud appli-

cation model according to basic properties, offerings,

implementation artifacts, resource requirements, vir-

tual architecture, etc. While a Blueprint allows speci-

fying ﬁne-grained information about a cloud applica-

tion enabling to select an appropriate blueprint from

a repository, these blueprints describe complete, de-

ployable cloud applications and are not intended for

reuse to deploy new applications.

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

634

7 CONCLUSIONS

In this paper, we presented an approach to deploy

arbitrary applications on arbitrary infrastructures by

leveraging the concept of templates. We showed in

case studies how the reuse of deployment models can

be enabled to deploy applications on heterogeneous

resources such as virtual machines, PaaS layers, and

also bare-metal machines. Further, our approach en-

ables developers to choose their preferred platform

and package their applications along with it in a single

archive. This enables to port applications from one

*aaS provider to another without the need to change

implementations as the needed platform API’s and

services can be shipped together with the application.

Our approach enables wrapping entire *aaS lay-

ers in a reusable manner and, thereby, allows to cope

with future challenges of growing ﬁelds such as IoT

and Fog Computing. One challenge of those ﬁelds

is to integrate local bare-metal resources with virtual

resources of the cloud, and enable applications to be

migrated between those resources. By enabling reuse

of proven SMAARTs to automatically deploy *aaS

layers on environments close to the “edge”, the com-

plexity of migrating applications from the traditional

cloud to these scenarios is signiﬁcantly reduced.

For future work, we plan to extend our approach

by generating SMAART archives in an automated

way, e.g., by determining the Application Type and

Implementation Placeholder of a deployment model.

Moreover, we plan to extend the approach to refer-

ence multiple infrastructures suitable to be used as

underlying resources for the deployment model.

ACKNOWLEDGEMENTS

This work was funded by the BMWi project Smar-

tOrchestra (01MD16001F).

REFERENCES

Atzori, L., Iera, A., and Morabito, G. (2010). The In-

ternet of Things: A survey. Computer networks,

54(15):2787–2805.

Binz, T., Breitenb

ucher, U., Haupt, F., Kopp, O., Leymann,

F., Nowak, A., and Wagner, S. (2013). OpenTOSCA

- A Runtime for TOSCA-based Cloud Applications.

In Proceedings of the 11

International Conference

on Service-Oriented Computing (ICSOC 2013), pages

692–695. Springer.

Breitenb

ucher, U., Binz, T., K

epes, K., Kopp, O., Leymann,

F., and Wettinger, J. (2014). Combining Declarative

and Imperative Cloud Application Provisioning based

on TOSCA. In International Conference on Cloud En-

gineering (IC2E 2014), pages 87–96. IEEE.

D’Andria, F., Bocconi, S., Cruz, J. G., Ahtes, J., and Zegi-

nis, D. (2012). Cloud4SOA: Multi-Cloud Applica-

tion Management Across PaaS Offerings. In Sym-

bolic and Numeric Algorithms for Scientiﬁc Comput-

ing (SYNASC), 2012 14th International Symposium

on, pages 407–414. IEEE, CPS.

Fink, J. (2014). Docker: a Software as a Service, Operating

System-Level Virtualization Framework. Code4Lib

Journal, 25.

Gao, W., Jin, H., Wu, S., Shi, X., and Yuan, J. (2012). Effec-

tively deploying services on virtualization infrastruc-

ture. Frontiers of Computer Science, 6(4):398–408.

Hoare, S. (2016). A study of the state-of-the-art of PaaS

Interoperability. In Proceedings of the 20th Interna-

tional Conference on Evaluation and Assessment in

Software Engineering, page 7. ACM.

Kopp, O., Binz, T., Breitenb

ucher, U., and Leymann, F.

(2013). Winery – A Modeling Tool for TOSCA-based

Cloud Applications. In Proceedings of the 11

Inter-

national Conference on Service-Oriented Computing

(ICSOC 2013), pages 700–704. Springer.

Loutas, N., Kamateri, E., and Tarabanis, K. (2011). A

Semantic Interoperability Framework for Cloud Plat-

form as a Service. In Cloud Computing Technology

and Science (CloudCom), 2011 IEEE Third Interna-

tional Conference on, pages 280–287. IEEE.

Mell, P. and Grance, T. (2011). The NIST Deﬁnition of

Cloud Computing.

Nguyen, D. K., Lelli, F., Papazoglou, M. P., and Heuvel,

W.-J. V. D. (2012). Blueprinting Approach in Support

of Cloud Computing. Future Internet, 4(1):322–346.

OASIS (2007a). SCA Assembly Model Speciﬁcation Version

1.00. Organization for the Advancement of Structured

Information Standards (OASIS).

OASIS (2007b). Web Services Business Process Execution

Language (WS-BPEL) Version 2.0. Organization for

the Advancement of Structured Information Standards

(OASIS).

OASIS (2013). Topology and Orchestration Speciﬁcation

for Cloud Applications (TOSCA) Version 1.0. Organi-

zation for the Advancement of Structured Information

Standards (OASIS).

ock, C. and Kolb, S. (2016). Nucleus – Uniﬁed Deploy-

ment and Management for Platform as a Service. Uni-

versity of Bamberg, Tech. Rep.

Yamato, Y., Muroi, M., Tanaka, K., and Uchimura, M.

(2014). Development of template management tech-

nology for easy deployment of virtual resources on

OpenStack. Journal of Cloud Computing, 3(1):7.

Yangui, S., Nasrallah, M. B., and Tata, S. (2013). PaaS-

independent approach to provision appropriate cloud

resources for SCA-based applications deployment. In

Semantics, Knowledge and Grids (SKG), 2013 Ninth

International Conference on, pages 14–21. IEEE.

Zhang, Q., Cheng, L., and Boutaba, R. (2010). Cloud com-

puting: state-of-the-art and research challenges. Jour-

nal of internet services and applications, 1(1):7–18.

The SePaDe System: Packaging Entire XaaS Layers for Automatically Deploying and Managing Applications

635