Model-driven Configuration Management
of Cloud Applications with OCCI
Fabian Korte
1
, St
´
ephanie Challita
2
, Faiez Zalila
2
, Philippe Merle
2
and Jens Grabowski
1
1
University of Goettingen, Institute of Computer Science, Goldschmidstraße 7, Goettingen, Germany
2
Inria Lille - Nord Europe & University of Lille, CRIStAL UMR CNRS 9189, France
Keywords:
Abstract:
To tackle the cloud-provider lock-in, the Open Grid Forum (OGF) is developing the Open Cloud Computing
Interface (OCCI), a standardized interface for managing any kind of cloud resources. Besides the OCCI Core
model, which defines the basic modeling elements for cloud resources, the OGF also defines extensions that re-
flect the requirements of different cloud service levels, such as IaaS and PaaS. However, so far the OCCI PaaS
extension is very coarse grained and lacks of supporting use cases and implementations. Especially, it does not
define how the components of the application itself can be managed. In this paper, we present a model-driven
framework that extends the OCCI PaaS extension and is able to use different configuration management tools
to manage the whole lifecycle of cloud applications. We demonstrate the feasibility of the approach by presen-
ting four different use cases and prototypical implementations for three different configuration management
tools.
1 INTRODUCTION
With the broad proliferation of cloud computing in
the industry and academia, many different cloud ser-
vice providers have emerged, that offer different ser-
vice levels and interfaces to the customer. This hete-
rogeneity of cloud provider interfaces makes it hard
to migrate applications between different cloud pro-
viders or combine different offerings. To tackle this
problem, three different strategies can be identified
in the literature: using code libraries that provide a
common Application Programming Interface (API)
for the different cloud provider APIs, e.g., Apache
jclouds
1 2
, or fog
3
, using techniques from model dri-
ven engineering (MDE) to decouple the cloud appli-
cations from the technical peculiarities of the different
target platforms, e.g., OCCIware (Parpaillon et al.,
2015), and SALOON (Quinton et al., 2016), and the
development of common standards, e.g., the Topology
and Orchestration Specification for Cloud Applicati-
ons (TOSCA)
4
, and the Open Cloud Computing In-
terface (OCCI) (Nyr
´
en et al., 2016). Of the two men-
tioned standardization approaches, TOSCA currently
1
http://www.jclouds.org
2
All URLs have been last retrieved on 01/03/2018.
3
http://fog.io
4
https://www.oasis-open.org/committees/TOSCA/
receives more attention by both the industry and rese-
arch community, but their focus is different and they
can be used complementarily (Glaser et al., 2017). In
this paper, we focus on OCCI, which is developed by
the Open Grid Forum (OGF) and aims to standardize
an API for the management of any kind of cloud re-
sources. The OCCI standard comprises several parts,
including the OCCI Core model and model exten-
sions for the Infrastructure-as-a-Service (IaaS) and
Platform-as-a-Service (PaaS) layers. Several imple-
mentations and use cases for the IaaS extension alre-
ady exist, that demonstrate its feasibility. However,
implementations and use cases for the PaaS extension
are rare. This might be due to the fact, that it only pro-
vides a very rough definition of cloud applications and
its components, that does not include how these cloud
applications can be configured and managed. Furt-
hermore, it does not explain how application com-
ponents are connected to the hosting infrastructure,
such as, which component gets deployed on which
virtual machine. To close these gaps, we demonstrate
a model-driven approach for the configuration mana-
gement of cloud applications using OCCI. Thereby,
we provide the following contributions to tackle the
identified shortcomings:
1. We propose an enhancement of the OCCI Plat-
form lifecyle definition by adding new de-
100
Korte, F., Challita, S., Zalila, F., Merle, P. and Grabowski, J.
Model-driven Configuration Management of Cloud Applications with OCCI.
DOI: 10.5220/0006693001000111
In Proceedings of the 8th International Conference on Cloud Computing and Services Science (CLOSER 2018), pages 100-111
ISBN: 978-989-758-295-0
Copyright
c
 2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

ployed/undeployed states to the application com-
ponents and new actions to transit between these
states,
2. we demonstrate how the OCCI model can be ex-
tended to enable the modeling of application com-
ponent placements on an hosting cloud infrastruc-
ture,
3. we provide a common framework for utilizing
OCCI for configuration management with diffe-
rent configuration management tools, and
4. show its feasibility by the means of different case
studies.
The remainder of this paper is structured as follows.
We introduce the OCCI model and the OCCIware tool
chain in Section 2. Afterwards, in Section 3, we dis-
cuss the open issues that exist with the current version
of OCCI related to the configuration management of
cloud applications. In Section 4, we introduce the
Model-Driven Configuration Management of Cloud
Applications with OCCI (MoDMaCAO) framework,
that aims to tackle these issues. To demonstrate the
feasibility of the provided framework, we discuss how
it can be applied to model different cloud applications
and implement their configuration management with
different configuration management tools in Section
5. We discuss related work in Section 6 and finally
conclude this paper and provide an overview on fu-
ture work in Section 7.
2 BACKGROUND
In the following, we provide a brief overview of OCCI
standard and OCCIware model-driven tool chain.
2.1 Open Cloud Computing Interface
The OCCI Core model (Nyr
´
en et al., 2016) is com-
posed of eight elements (grey boxes in Figure 1).
Category is the base type for all other classes and
provides the necessary identification mechanisms.
Categories can be uniquely identified by associa-
ted Uniform Resource Identifiers (URIs). They have
Attributes that are used to define the properties of
a certain class, e.g., the IP address of a virtual ma-
chine. Three classes are derived from Category:
Kind, Action, and Mixin. A Kind defines the type of
a cloud entity, e.g., a compute resource, and Mixins
define how an entity can be extended at runtime. Both
have Actions that define which behaviours can be
executed on an entity. The cloud entities themselves
are modeled by the class Entity, which provides the
base class for cloud Resources, e.g., virtual machi-
nes, and Links that define how the resources are con-
nected.
The OCCI Core model is accompanied with se-
veral extensions. The OCCI Platform extension (Met-
sch and Mohamed, 2016) defines the two speci-
alized Resources: Application and Component
and a new Link type ComponentLink (see Fi-
gure 3). The Application thereby represents the
user accessible part of the overall cloud applica-
tion. The Application itself is composed of several
Components, that implement its functionality, e.g.,
through microservices. Components can be linked
with help of ComponentLinks to establish a connecti-
ons between them.
An Application or Component can be in the state
Active, Inactive or Error. A transition from the
Inactive to the Active state can be triggered by cal-
ling the start action on the specific Application
or Component, and a transition from Active to
Inactive can be triggered by calling the stop action.
The Error state can be reached at any time, in case an
error occurs in the Application or Component.
2.2 OCCIware Tool Chain
OCCI has been proposed as a generic model and API
for managing any kind of cloud computing resour-
ces. However, OCCI suffers from the lack of a precise
definition of its concepts and a modeling framework
to model, verify, validate, document, deploy and ma-
nage OCCI artifacts. To resolve the first issue, a meta-
model from OCCI, named OCCIWARE METAMODEL
(see Figure 1), has been proposed in (Merle et al.,
2015) and enhanced in (Zalila et al., 2017). It defi-
nes a precise semantics of OCCI concepts and intro-
duces, among others, two key concepts: Extension
and Configuration. An OCCI Extension repre-
sents a specific application domain, e.g., inter-cloud
networking extension (Medhioub et al., 2013), infra-
structure extension (Metsch et al., 2016), platform
extension (Yangui and Tata, 2013; Yangui and Tata,
2014; Metsch and Mohamed, 2016), application ex-
tension (Yangui and Tata, 2014), etc. An OCCI
Configuration defines a running system. It repre-
sents an instantiation of one or several OCCI extensi-
ons. In addition, the OCCIWARE METAMODEL intro-
duces the Constraint notion allowing the cloud ar-
chitect to express business constraints related to each
domain. The constraints can be expressed on OCCI
kinds and mixins. Finally, the OCCIWARE METAMO-
DEL provides the FSM mechanism. This later allows
to describe the behavior of each OCCI kind/mixin as
a Finite State Machine (FSM).
Model-driven Configuration Management of Cloud Applications with OCCI
101

Figure 1: A subset of OCCIWARE METAMODEL.
To resolve the second issue, a model-driven tool
chain for OCCI, named OCCIWARE STUDIO, has
been proposed (Zalila et al., 2017). It is built ba-
sed on the OCCIWARE METAMODEL and proposed
as a set of plugins for the Eclipse IDE. OCCIWARE
STUDIO allows both cloud architects and users to en-
code OCCI extensions and configurations, respecti-
vely, graphically via the OCCI Designer tool, and
textually via the OCCI Editor tool. They can also
automatically verify the consistency of these extensi-
ons and configurations via the OCCI Validator tool.
In addition, OCCIWARE STUDIO provides a tool, na-
med Connector Generator, that generates the Java
code associated to an OCCI extension. This connec-
tor code must be completed by cloud developers to
implement concretely how OCCI CRUD operations
and actions must be executed on a real cloud infra-
structure. Later, this generated connector is deployed
on the OCCIware Runtime.
3 PROBLEM STATEMENT
As stated above, there are several use cases and im-
plementations of the OCCI Infrastructure extension
available, while the OCCI Platform extension has not
reached a widespread adoption yet. We identify the
following reasons for this situation:
• Incomplete Lifecycle Model (P1): The lifecycle
for the Component and Application resources as
defined in the OCCI specification is incomplete.
Components can either be inactive or active, but
the specification does not allow to model informa-
tion about the installation or configuration states,
• No Connection Between Infrastructure and
Platform Models (P2): The OGF provides two
separate OCCI extensions for the IaaS and PaaS
layers, but it misses to define the connection be-
tween them. According to the specification it is
hence not possible to connect a Component or
Application to a Compute resource of the OCCI
Infrastructure extension,
• No Support for Configuration Management
(P3): In the current version of the OCCI speci-
fication, it is not defined how Components and
Applications can be managed throughout their
lifecycle and if and how additional tooling, e.g.,
configuration management tools can be integrated
for this purpose,
• Lack of Use Cases and Implementations (P4):
The current version of the specification lacks of
any real-world use case for the application of the
Platform extension. Furthermore, no canonical
implementation is available.
To overcome these issues, we provide a framework
for modeling and managing cloud applications with
OCCI, which we will introduce in the next section.
4 MoDMaCAO
In the following, we will introduce the building
blocks of the MoDMaCAO framework and how they
tackle the problems identified above.
4.1 Overall Architecture
Figure 2: Overall Architecture.
The overall architecture of the proposed
MoDMaCAO framework and its contributions
are depicted in Figure 2. Our first contribution (1) is
to address P1 by enhancing of the OCCI Platform ex-
tension via additional lifecycle States and Actions.
Furthermore, we introduce a new Link Kind (2) to
be able to connect Components of the OCCI Plat-
form extension to Compute resources of the OCCI
CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science
102

Infrastructure extension (addressing P2). As a third
contribution (3), we define a new OCCI extension
to be able to model application components that are
managed with help of a configuration management
tool (addressing P3). We demonstrate the feasibility
of the defined extension by modeling four different
distributed cloud applications and finally provide a
framework for implementing model-driven confi-
guration management with different configuration
management tools (4), thereby addressing P4.
4.2 Enhanced OCCI Platform Lifecycle
Experimenting with the OCCI Platform extension in
real use-cases shows several hidden lacks. The OCCI
Platform extension provides only inactive, active,
and error states with two actions: start and stop.
This design assumes that a component is already in-
stalled and configured which might not be the case.
For instance, an application component, e.g., a soft-
ware component, like a database or an application
server, will first be installed (“deployed”), and con-
figured, prior to managing it (start/stop etc.). There-
fore, we argue that the lifecycle of the Component and
Application kinds is not expressive enough and does
not define all possible states of a resource (compare
P1). To resolve it, we propose an enhancement of the
OCCI Platform extension as shown in Figure 3.
Figure 3: Enhanced OCCI Platform kinds.
The different improvements are colored in blue.
We propose to add two additional states in the Status
enumeration type: undeployed and deployed. In
addition, we define three new actions for each kind:
configure, deploy, and undeploy. Finally, we
enhance the FSMs of both kinds by integrating the
new provided states and actions, and adding ele-
ven new transitions. Figure 4 shows the enhan-
ced FSM for Component and Application kinds.
Therefore, a Component/Application resource is
initially undeployed. Once the deploy action is
triggered, the resource is deployed. By trigge-
ring the configure action, the resource is confi-
gured and reaches the inactive state. Finally, a
Component/Application can reach the active state
by triggering the start action.
Figure 4: Enhanced OCCI Platform FSMs.
4.3 OCCI Placement Extension
Figure 5 depicts the definition of a new link kind
PlacementLink that addresses the missing con-
nection between the OCCI Platform extension and the
OCCI Infrastructure extension. A PlacementLink
has a Component resource as its source and a
Compute resource as its target, and hence allows to
model the placement of an application component on
a virtual machine.
Figure 5: New OCCI Placement Extension.
4.4 MoDMaCAO Modeling Framework
The MoDMaCAO modeling framework is based on
the OCCIware tool chain presented in Section 2.2 and
allows cloud architects to: (1) design abstract types
modeling cloud applications and their components,
(2) model configured instances of cloud applications
that use the defined abstract types , and (3) check the
validity of instances of cloud applications.
Firstly, as shown in Figure 6, the MoDMaCAO
modeling framework defines the following set of ab-
stract types:
Model-driven Configuration Management of Cloud Applications with OCCI
103

Figure 6: The MoDMaCAO Modeling Framework.
• The Application mixin type abstracts the no-
tion of cloud application. This mixin ap-
plies to OCCI Platform Application resour-
ces. A cloud application is composed of one
or more cloud application components as en-
forced by the OneOrMoreComponents constraint.
Then, modeling specific cloud applications requi-
res to design new mixin types inheriting from
Application, e.g., Cluster and ClientServer
types. These new types could define their own
attributes and constraints. For instance, a client-
server application has only one server compo-
nent (i.e., OnlyOneServer constraint) and some
client components (i.e., OneOrMoreClients con-
straint).
• The Cluster mixin type abstracts the notion of
clustered cloud application.
• The Component mixin type abstracts the no-
tion of cloud application component. This mixin
applies to OCCI Platform Component resour-
ces. Each component has an optional immuta-
ble modmacao.component.version attribute re-
presenting the version of the component used at
runtime, and must be placed on only one OCCI
Compute resource (i.e., OnlyOnePlacementLink
constraint). Then, modeling specific cloud appli-
cation components requires to define new mixin
types inheriting from Component, e.g., Client
and Server types. These new component types
can define their own attributes and constraints.
For instance, a server component has a network
port on which it listens to client requests (i.e.,
server.port immutable attribute) and a client
component must be connected to a server com-
ponent (i.e., OneServerDependency constraint).
• The Version data type defines the valid string pat-
tern for version values, i.e., <major>.<minor>.
• The Port data type defines the valid network port
values, i.e., range from 0 to 65535.
• The Dependency mixin type abstracts the
notion of dependency between two cloud
application components. This mixin ap-
plies to OCCI Platform ComponentLink
links. Both SourceMustBeComponent and
TargetMustBeComponent constraints enforce
that a dependency link connects two Component
instances. Then, modeling specific dependencies
requires to define new mixin types inheriting from
Dependency, e.g., InstallationDependency,
ExecutionDependency, and ServerDepen-
dency. These new types could define their
own attributes and constraints. For instance,
ServerDependency defines two constraints
enforcing the dependency source to be a client
component and the dependency target to be a
server component.
• The InstallationDependency mixin type ab-
stracts an installation dependency, i.e., the source
component could be deployed only when the tar-
get component is already deployed.
• The ExecutionDependency mixin type abstracts
an execution dependency, i.e., the source com-
ponent could be started only when the target
component is already started. For instance, the
ServerDependency type abstracts the execution
dependency from a client and a server component,
i.e., the client component can not start until the
server component is started.
Secondly, the MoDMaCAO modeling framework al-
lows architects to model configured instances of cloud
applications and their components. As illustration,
Figure 7 shows the model of a client-server applica-
tion composed of three client components (client1
to client3) and one server component (server) de-
ployed on four virtual machines (vm1 to vm4). OCCI
resources and links are represented by boxes in yel-
low and orange color, respectively. The application
resource is connected to the four component re-
sources via componentLinks. Each client com-
ponent is connected to the server component via a
ServerDependency link. The network port of the
server component is set to 8080. Each component is
placed on one virtual machine via a PlacementLink.
Finally, the architecture, the number of cores, the host
name, the speed, and the memory of each virtual ma-
chine are configured.
Thirdly, MoDMaCAO checks the validity
of cloud application configurations by evalu-
ating all the constraints defined by used ab-
stract types. For the client-server application,
MoDMaCAO evaluates that the Application
resource is connected to some Component resour-
ces (OneOrMoreComponents constraint), some
CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science
104

Figure 7: Modeling a Client/Server Application with MoDMaCAO.
client components (OneOrMoreClients), and
only one server component (OnlyOneServer),
all Component resources are placed on only one
Compute resource (OnlyOnePlacementLink),
each client is connected to one server
(OneServerDependency), the value of the network
port of the server component is in the valid range
(0 to 65535), each Dependency link connects two
Component resources (SourceMustBeComponent
and TargetMustBeComponent), and each
ServerDependency link connects a client to
a server component (SourceMustBeClient and
TargetMustBeServer). As long as a constraint
is false, the architect must correct its cloud appli-
cation configuration. When all the constraints are
true, the cloud application can be deployed by the
MoDMaCAO implementation framework.
4.5 MoDMaCAO Implementation
The MoDMaCAO implementation framework reali-
zes the whole provisioning – i.e., installation, confi-
guration then execution – of model-based cloud appli-
cation instances on top of diverse configuration ma-
nagement tools such as Ansible, Roboconf and Cloud
Automation by using model interpretation. As illus-
trated in Figure 8, this framework is split into two
main parts: a generic part independent of any con-
figuration management tool and a plugin part specific
to each supported configuration management tool, as
discussed in Section 5.2.
For the generic part, we used OCCIware Studio to
automatically generate the skeleton of the framework
from our three proposed OCCI extensions – enhanced
OCCI Platform, Placement, and MoDMaCAO – and
only implemented the five lifecycle actions – deploy,
undeploy, configure, start, and stop – of both
Application and Component kinds respecting their
Figure 8: MoDMaCAO Implementation Class Diagram.
finite state machine. The following paragraphs des-
cribe the key behaviour we implemented.
The implementation of Application orchestra-
tes the provisioning of all the components linked
to an application. When the state of an applica-
tion is undeployed, the implementation of deploy
computes the order in which all the application
components must be deployed according to their
InstallationDependency links. Components not
connected by InstallationDependency links are
deployed in parallel when components connected by
InstallationDependency links are deployed se-
quentially. For instance, the four components of
the client-server application shown in Figure 7 are
deployed in parallel because they have no installa-
tion dependencies. When the state is deployed,
the implementation of configure consists of con-
figuring all the application components in parallel.
When the state is inactive, the implementation of
start computes the order on which all the applica-
tion components must be started according to their
ExecutionDependency links. For instance in the
client-server application, the server component is
started before the three client components are started
in parallel. When the state is active, the implemen-
tation of stop consists of stopping all the application
Model-driven Configuration Management of Cloud Applications with OCCI
105

components in the reverse order of their starting. For
instance, client components are stopped in parallel be-
fore the server component is stopped. When the state
is inactive, the implementation of undeploy con-
sists of uninstalling all the application components in
the reverse order of their deployment.
The implementation of Component implements
the FSM of the Component kind and checks that the
Compute resource where the component is placed, is
already started before orchestrating the provisioning
of the component.
Finally, the generic part delegates the calls to the
plugin part specific to the used configuration ma-
nagement tool. Each plugin must implement the
ConfigurationManagementTool interface shown in
Figure 8. For instance, the implementation of
start(Application) called by the generic part
must finalize the starting of a given application after
all its components have been started. This implemen-
tation is specific to the used configuration manage-
ment tool.
5 EVALUATION
To evaluate the proposed approach, we selected four
different case studies that represent distributed cloud
applications. Furthermore, we demonstrate how our
approach can be easily adapted to different configu-
ration management tools by providing experimental
implementations for three different configuration ma-
nagement and cloud orchestration tools.
5.1 Case Studies
As case studies, we selected a distributed MongoDB
database
5
, the popular LAMP web-application stack
6
,
a distributed Cassandra database
7
and an Apache
Spark cluster
8
. Due to space constraints, we focus
on the description of the defined MongoDB extension
of MoDMaCAO, and we provide a configuration mo-
del that is conform to this extension. For the other use
cases, we give only a brief overview of the defined ex-
tensions. Full-sized configuration models using each
of these three remaining extensions can be found in
the supplemental material
9
.
5
https://www.mongodb.com/
6
https://help.ubuntu.com/community/ApacheMySQLPHP
7
http://cassandra.apache.org/doc/latest/
8
https://spark.apache.org/docs/latest/
9
https://github.com/occiware/MoDMaCAO
5.1.1 MongoDB
MongoDB is a NoSQL database that can be highly
scaled and is often used in cloud environments.
To achieve scalability, it supports the concept of
sharding, i.e., the decomposition of and distributed
storage of a data collection to several machines. Furt-
hermore, replication sets can be used, to provide re-
dundancy and high availability in case a machine ex-
periences a failure.
Figure 9: Modeling MongoDB with MoDMaCAO.
Figure 9 depicts how we specialize the mixin ty-
pes defined by the MoDMaCAO framework to be able
to model MongoDB clusters:
• The MongoDBComponent mixin type is the
base type for all other MongoDB-specific
Component mixin types. It defines the attributes
mongodb.bindip, and mongodb.port, that spe-
cifies the IP address and port on which the Mon-
goDB service should be listening.
• The ReplicableMongoDBComponent mixin
type defines the base type for components
that can be replicated. It defines the attribute
mongodb.replication.set.name that is used
to assign a component to a certain replication set.
MongoDB components belonging to the same
replication set are synchronized copies of each
other.
• The Router mixin type abstracts the notion of a
router in the MongoDB cluster. A router imple-
ments the component to which the user connects.
It forwards the requests of the user to the machi-
nes that actually hold the data.
• The ConfigServer mixin type abstracts the notion
of a config server of a MongoDB cluster. A config
server stores the metadata, including the state and
organization of the data. It is also responsible to
store authentication configuration information.
• The Shard mixin type abstracts the notion of a
shard in the MongoDB cluster. The shards are
used to store the actual data of the database. Each
shard holds a subset of the overall data.
CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science
106

Figure 10: Modeling a MongoDB Cluster with MoDMaCAO.
• The Cluster mixin type defines constraints for a
MongoDB cluster: A cluster must contain at least
one router (i.e., OneOrMoreRouters), at least one
shard (i.e., OneOrMoreShards), and at least one
config server (i.e., OneOrMoreConfigServer).
• The ConfigServerDependency mixin type
abstracts the execution dependency between
MongoDBComponents and a ConfigServer, to be
able to ensure that the ConfigServer is started,
before the other components get started.
A model for a MongoDB cluster with three
shards and no replication is depicted in Figure 10.
For the sake of brevity, we omit the depiction of
Attributes. The MongoDB-cluster cluster con-
sists of the components router, configserver, and
the three shards, shard1 to shard3. The router
and shard1 to shard3 have an execution dependency
to the configserver. The components are placed
on five different virtual machines, vm1 to vm5, using
PlacementLinks, which are connected to a network
using NetworkInterfaces.
5.1.2 LAMP
This second use case addresses LAMP, which is an
open source Web development platform that uses
Linux as the operating system, Apache as the Web
server, MySQL as the relational database manage-
ment system and PHP, Perl or Python as the object-
oriented scripting language.
The LAMP Web application can be modeled with
help of the following mixins:
• The LAMP mixin type abstracts the notion of
a LAMP application and depends on MoDMa-
CAO Application mixin. A LAMP application
is accessible via only one ApacheServer as en-
forced by the OnlyOneApacheServer constraint.
It is deployed using one or more Tomcat contai-
ner (i.e., OneOrMoreTomcats constraint). Mo-
reover, the persistent data of a LAMP applica-
tion are stored in only one MySQL database (i.e.,
OnlyOneMySQL constraint).
• The ApacheServer mixin type abstracts the
notion of a LAMP Web server. It inher-
its from the Component mixin of the MoD-
MaCAO modeling framework. It defines
OneOrMoreTomcatDependencies constraint en-
forcing that the ApacheServer instance cannot
run if it is not linked to at least one Tomcat in-
stance.
• The Tomcat mixin type abstracts the notion of
a LAMP application container. It inherits from
MoDMaCAO Component mixin. Each Tomcat
instance is executed if it is connected to only one
MySQL instance (i.e., OnlyOneMySQLDependency
constraint).
• The MySQL mixin type abstracts the notion of
a LAMP MySQL database and also inherits from
MoDMaCAO Component mixin.
• The TomcatDependency mixin type abstracts a
LAMP execution dependency by always con-
necting a Component instance to a Tomcat in-
stance (TargetMustBeTomcat).
• The MySQLDependency mixin type abstracts
a LAMP execution dependency by always con-
necting a Component instance to a MySQL instance
(TargetMustBeMySQL).
Model-driven Configuration Management of Cloud Applications with OCCI
107

5.1.3 Apache Cassandra
Apache Cassandra is an open-source distributed
NoSQL database management system. It is designed
to handle large amounts of data by offering support
for clusters across multiple datacenters. To achieve
scalability in Cassandra clusters, the architect adds
new nodes to an existing cluster without having to
disconnect it first. When a new node is added, the
cloud architect has to enter the new node name in
the seed component list and then the new node will
be part of the Cassandra database architecture, called
“ring”. Also, unlike other sharded systems like Mon-
goDB and other Master/Worker systems like Apache
Spark (cf. Section 5.1.4), a single point of failure does
not affect the whole cluster in Cassandra. Therefore,
it is capable of offering continuous availability. To do
so, it automatically distributes, replicates and main-
tains data across the nodes of a cluster. We detail in
the following each element of the Cassandra Model:
• The Cluster mixin type abstracts the notion of
a clustered Cassandra database. This mixin de-
pends on MoDMaCAO modeling framework by
inheriting from its Cluster mixin. It defi-
nes two constraints, i.e., OneOrMoreNodes and
OneOrMoreSeeds that enforce that a Cluster
contains at least one Node and one Seed, respecti-
vely.
• The Node mixin type abstracts the notion of a
Cassandra component. All nodes play an iden-
tical role, they communicate with each other via a
distributed, scalable protocol called “gossip”.
• The Seed mixin type inherits from the Node
mixin. The seed node maintains all the nodes list
in a cluster.
5.1.4 Apache Spark
Apache Spark is an open-source cluster computing
platform for big data processing. We define the fol-
lowing extension to be able to model Apache Spark
clusters:
• The ApacheSparkCluster mixin type abstracts
the notion of a Spark application that runs as in-
dependent sets of processes on a cluster. The
ApacheSparkCluster connects to several types
of ApacheSparkComponent instances, i.e., only
one master (OnlyOneMaster) and at least one
worker (OneOrMoreWorkers).
• The ApacheSparkComponent mixin type ab-
stracts the notion of a Spark component. Each
Spark component has apache.spark.port and
apache.spark.webui.port attributes represen-
ting the port to access the Spark console and
the Spark Web interface, respectively. An
ApacheSparkComponent instance may be either
a Master or a Worker.
• The Master mixin type abstracts the notion of a
managing component that has a pool of jobs and
assigns them to workers.
• The Worker mixin type represents any node
that can execute a job, i.e., run application
code in the cluster. Each worker has an
apache.spark.worker.cores attribute repre-
senting the number of cores in each worker. It
also has an apache.spark.worker.memory
attribute representing the worker memory in
gibibyte (GiB). A Worker instance depends on
on the execution of only one Master instance
(OnlyOneMasterDependency). We also define
WorkerCoresSmallerThanComputeCores and
WorkerMemorySmallerThanComputeMemory
constraints that enforce that the cores and the
memory of each worker are smaller than those of
its hosting virtual machine.
• The MasterDependency mixin type ab-
stracts a Spark execution dependency by
always connecting a Worker instance to a
Master instance (SourceMustBeWorker and
TargetMustBeMaster).
5.2 Implementations
In the following we briefly discuss the implementa-
tion for the configuration management tools Ansible,
Roboconf
10
and Cloud Automation
11
with help of the
MoDMaCAO implementation framework.
5.2.1 Ansible
We implemented an Ansible-specific plugin that im-
plements the ConfigurationManagementTool inter-
face. For each of the defined Mixins, an Ansible
role
12
is created that bundles the steps and files that
are necessary to install the corresponding software
component on a specific machine. For the prototypi-
cal implementation, we assume that these roles are al-
ready accessible from the OCCIware Runtime. When
executing the deploy action, this role is triggered by
our plugin. We further provide Ansible roles for the
undeploy, start, stop, and configure actions for
10
https://roboconf.net/
11
https://www.activeeon.com/cloud-automation/
12
https://docs.ansible.com/ansible/2.4/playbooks-
reuse roles.html
CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science
108

each Mixin. The Attributes defined by the Mixins
are getting passed to Ansible in form of Ansible va-
riables and are accessible in the configuration steps
defined in the Ansible roles.
5.2.2 Roboconf
Secondly, we implemented a Roboconf-specific
plugin (Pham et al., 2015), which is responsi-
ble of managing the application lifecycle via its
SoftwareInstanceManager concept. The latter ex-
tends the ConfigurationManagementTool interface
of MoDMaCAO implementation framework. The
SoftwareInstanceManager comprises three con-
nectors for managing the Application instances,
their Component instances and the ComponentLink
instances, respectively. A Roboconf method
deployAndStartAll(), which deploys an applica-
tion and directly starts its components, is executed by
only calling the deploy() method of MoDMaCAO.
The start() method of MoDMaCAO is implicit and
not implemented in Roboconf. A Mixin will start di-
rectly when it is deployed. The same behavior is ap-
plied to undeployAll() method of Roboconf which
will implicitly stop() the defined Mixin.
5.2.3 Cloud Automation
Finally, the third plugin integrated to our MoDMa-
CAO implementation framework is the Cloud Au-
tomation orchestrator. Cloud Automation is based
on workflows, which are series of automated actions
that the cloud developer triggers to occur based on
the Application or Component state. For example,
Cloud Automation organizes workflows for stopping
an application, as follows: stop all the application
components, undeploy them, and then stop the ap-
plication. These workflows are implemented thanks
to OCCI finite state machine.
5.3 Discussion
We enhanced the OCCI Application and
Component definition by adding three additional
lifecycle operations. Our case studies confirmed,
that these extensions are able to reflect the re-
quirements for the deployment of the selected
applications. Furthermore, by providing the notion
of a PlacementLink, we are able to establish a
connection between the OCCI Platform exten-
sion and the OCCI Infrastructure extension. The
PlacementLink is used in the implementations to
derive the IP-address of the hosting virtual machines
to be able to connect to them for the configura-
tion management. We separated the configuration
management tool-specific logic from the generic
provisioning order. In this way, only a minimal set
of tool-specific code needs to be provided for each
configuration management tool. By applying our
implementation framework successfully to three dif-
ferent configuration management tools, we were able
to show, that our approach is generic enough to cover
the requirements of different tools. Nevertheless,
we also discovered that there are some tool-specific
configuration needed that should also become part of
the modeling framework. For example, a SSH Key
and a username is required by Ansible to connect
to the virtual machines for the configuration mana-
gement. Such information could be either provided
by tool-specific Mixins that are added to the models
or by enhancing the OCCI Infrastructure extension
to be able to cover authentication information for
provided virtual machines. MoDMaCAO proved to
be powerful enough to model different distributed
cloud applications and we were also able to use its
implementation framework to successfully provide
plugins for different configuration management tools.
6 RELATED WORK
As already mentioned in Section 1 and as explained
in (Challita et al., 2017), there are three strategies
to address the heterogeneity between cloud offerings.
Since the first strategy, which is multi-cloud libraries,
is only focused on the infrastructure interoperability,
we detail in the following the state-of-the-art of the
two remaining strategies, especially the solutions that
tackle the management of applications.
MDE for the Cloud. Nowadays, model-based so-
lutions are becoming increasingly popular in cloud
computing. Some of them are commercial applica-
tion provisioning solutions enabling developers and
administrators to specify deployment artifacts and de-
pendencies. Notable examples include Ubuntu juju
13
that targets the modeling of applications and their hy-
brid deployment. In the same vein of this commercial
graphical interface, several research projects are pro-
viding domain-specific modeling languages and fra-
meworks that enable architects to describe and ma-
nage cloud platforms. Among these model-based
solutions, we identify OCCIware (Parpaillon et al.,
2015) (Zalila et al., 2017), which our work is an ex-
tension of. OCCIware has been successfully app-
lied for the management of resources from different
domains, including the management of Docker con-
13
http://juju.ubuntu.com/
Model-driven Configuration Management of Cloud Applications with OCCI
109

tainers (Paraiso et al., 2016), and the management of
mobile robots (Merle et al., 2017). COAPS (Sellami
et al., 2013) is a PaaS API for managing cloud ap-
plications. It extends the OCCI Core model, i.e., the
Resource and Link concepts, without extending the
OCCI Platform extension. Moreover, COAPS com-
plies to the previous, non-enhanced version of the
OCCI standard, hence it lacks of the resource state
management and the conformance verification provi-
ded by the OCCIware tool chain and MoDMaCAO.
SALOON (Quinton et al., 2016) is a model-driven
multi-cloud configurator. It uses feature models to re-
present infrastructure and platform variability, as well
as ontologies to describe the cloud applications requi-
rements. SALOON targets four PaaS providers and
the authors claim it can be extensible by adding now
provider models that conform to the metamodel they
define. However, this can be difficult and error-prone
since this framework is not based on a standard, nor
on some formal specification. TUNe (Chebaro et al.,
2009) is a management system that is based on the
Fractal component model for describing the software
encapsulation and on two UML profiles, one for the
deployment of legacy distributed applications and one
for their reconfiguration using state diagrams. TUNe
was applied for the administration of J2EE applicati-
ons. Like most of the available model-driven configu-
ration management approaches, TUNe allows chan-
ges only at design-time. This means that the deploy-
ment process may be repeated several times, which is
costly and time-consuming.
Regarding runtime support, a strong analogy
can be made between our approach and Deploy-
Ware (Flissi et al., 2008), while the former is applied
on cloud APIs and the latter on grid infrastructures.
In fact, DeployWare provides a modeling language to
deploy applications on Grid’5000
14
and a graphical
interface to manage them at runtime. CloudML (Ferry
et al., 2013) is a cloud modeling language that helps
to provision cloud infrastructure and platform resour-
ces by a semi-automatic matching between the defi-
ned application requirements and the cloud offerings.
CloudML is exploited both at design-time to describe
the application provisioning of cloud resources after
performing the necessary orchestration, and at run-
time to manage the deployed applications. Unlike our
work, CloudML is not based on standards and requi-
res the user to learn a new DSL.
Cloud Standards. Our work is also a standard-
based approach since it adopts the OCCI standard
metamodel. Besides OCCI, several cloud compu-
ting standards for managing cloud applications exist.
14
https://www.grid5000.fr/
The Organization for the Advancement of Structured
Information Standards (OASIS)’s Cloud Application
Management for Platforms (CAMP)
15
standard tar-
gets the deployment of cloud applications on top of
PaaS resources. The OASIS’s TOSCA standard de-
fines a language to describe and package cloud ap-
plication artifacts and deploy them on IaaS and PaaS
resources. The Eclipse Winery
16
project provides an
open source Eclipse-based graphical modeling tool
for TOSCA when the OpenTOSCA project provi-
des an open source container for deploying TOSCA-
based applications (Binz et al., 2013). Cloudify
17
is
an open source orchestration and management frame-
work for cloud applications lifecycle. It is also based
on TOSCA and provides a commercial Web Interface
that enables the developer to create deployments and
execute workflows.
In contrast to CAMP and TOSCA, OCCIware mo-
dels are executable inside a [e-mail] (Blair
et al., 2009) interpreter framework. In addition,
CAMP and TOSCA can use OCCI-based IaaS/PaaS
resources, so these standards are complementary.
This standards “marriage” will be a main pillar of our
future work, as discussed in Section 7.
7 CONCLUSION
We presented an approach for model-driven configu-
ration management of cloud applications at runtime
by using an enhanced version of OCCI. We used the
OCCIware tool chain to model the proposed enhance-
ments and used its capabilities to generate prototypi-
cal implementations for different configuration mana-
gement tools. Furthermore, we showed how the pro-
posed framework can be used to model, deploy and
manage four different distributed cloud applications.
As future work, we will investigate how the proposed
framework can be extended to support multiple confi-
guration management tools to be used side-by-side for
managing a single cloud application. We also want to
incorporate concepts that support the reuse of defined
Component mixins in other applications.
Our long-term goal is to extend the provided con-
cept and tooling with the support for additional cloud
standards, including TOSCA and CAMP. We already
defined and a preliminary mapping between TOSCA
and OCCI (Glaser et al., 2017). We will further refine
this mapping as a basis for providing an integrated so-
lution for model-driven cloud orchestration utilizing
both standards.
15
https://www.oasis-open.org/committees/camp/
16
https://www.eclipse.org/proposals/soa.winery/
17
http://cloudify.co/
CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science
110

ACKNOWLEDGEMENTS
We thank the Simulationswissenschaftliches Zentrum
Clausthal-G
¨
ottingen (SWZ), the French PIA OCCI-
ware project (www.occiware.org), and the Hauts-de-
France Regional Council for supporting this work.
AVAILABILITY
Readers can find the open source code base
of MoDMaCAO on https://github.com/occiware/
MoDMaCAO.
REFERENCES
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
International Conference on Service-Oriented Com-
puting, pages 692–695. Springer.
Blair, G., Bencomo, N., and France, R. B. (2009). Models@
run.time. Computer, 42(10).
Challita, S., Paraiso, F., and Merle, P. (2017). Towards
Formal-based Semantic Interoperability in Multi-
clouds: The fclouds Framework. In 10th IEEE Inter-
national Conference on Cloud Computing (CLOUD),
pages 710–713. IEEE.
Chebaro, O., Broto, L., Bahsoun, J.-P., and Hagimont, D.
(2009). Self-TUNe-ing of a J2EE Clustered Appli-
cation. In 6th IEEE Conference and Workshops on
Engineering of Autonomic and Autonomous Systems,
2009. EASe 2009, pages 23–31. IEEE.
Ferry, N., Rossini, A., Chauvel, F., Morin, B., and Solberg,
A. (2013). Towards Model Driven Provisioning, De-
ployment Monitoring, and Adaptation of Multi-Cloud
Systems. In 6th IEEE International Conference on
Cloud Computing (CLOUD), pages 887–894. IEEE.
Flissi, A., Dubus, J., Dolet, N., and Merle, P. (2008). De-
ploying on the Grid with DeployWare. In 8th IEEE
International Symposium on Cluster Computing and
the Grid (CCGrid), pages 177–184. IEEE.
Glaser, F., Erbel, J. M., and Grabowski, J. (2017). Mo-
del Driven Cloud Orchestration by Combining TO-
SCA and OCCI. In 7th International Conference on
Cloud Computing and Services Science (CLOSER),
pages 644–650. SciTePress.
Medhioub, H., Msekni, B., and Zeghlache, D. (2013).
OCNI – Open Cloud Networking Interface. In 22nd
International Conference on Computer Communicati-
ons and Networks (ICCCN), pages 1–8. IEEE.
Merle, P., Barais, O., Parpaillon, J., Plouzeau, N., and Tata,
S. (2015). A Precise Metamodel for Open Cloud
Computing Interface. In 8th IEEE International Con-
ference on Cloud Computing (CLOUD), pages 852–
859. IEEE.
Merle, P., Gourdin, C., and Mitton, N. (2017). Mobile
Cloud Robotics as a Service with OCCIware. In 2nd
IEEE International Congress on Internet of Things
(ICIOT), pages 50–57. IEEE.
Metsch, T., Edmonds, A., and Par
´
ak, B. (2016). Open Cloud
Computing Interface - Infrastructure. [Available on-
line: http://ogf.org/documents/GFD.224.pdf].
Metsch, T. and Mohamed, M. (2016). Open Cloud
Computing Interface - Platform. [Available online:
https://www.ogf.org/documents/GFD.227.pdf].
Nyr
´
en, R., Edmonds, A., Papaspyrou, A., Metsch,
T., and Par
´
ak, B. (2016). Open Cloud Com-
puting Interface - Core. [Available online:
http://ogf.org/documents/GFD.221.pdf].
Paraiso, F., Challita, S., Al-Dhuraibi, Y., and Merle, P.
(2016). Model-Driven Management of Docker Con-
tainers. In 9th IEEE International Conference on
Cloud Computing (CLOUD), pages 718–725. IEEE.
Parpaillon, J., Merle, P., Barais, O., Dutoo, M., and Paraiso,
F. (2015). OCCIware-A Formal and Tooled Frame-
work for Managing Everything as a Service. In Pro-
jects Showcase@ STAF’15, volume 1400, pages 18–
25.
Pham, L. M., Tchana, A., Donsez, D., De Palma, N., Zur-
czak, V., and Gibello, P.-Y. (2015). Roboconf: a Hy-
brid Cloud Orchestrator to Deploy Complex Applica-
tions. In 8th IEEE International Conference on Cloud
Computing (CLOUD), pages 365–372. IEEE.
Quinton, C., Romero, D., and Duchien, L. (2016). SA-
LOON: A Platform for Selecting and Configuring
Cloud Environments. Software: Practice and Expe-
rience, 46(1):55–78.
Sellami, M., Yangui, S., Mohamed, M., and Tata, S. (2013).
PaaS-independent Provisioning and management of
applications in the cloud. In 6th IEEE Internatio-
nal Conference on Cloud Computing (CLOUD), pages
693–700. IEEE.
Yangui, S. and Tata, S. (2013). CloudServ: PaaS resources
provisioning for service-based applications. In 27th
IEEE International Conference on Advanced Informa-
tion Networking and Applications (AINA), pages 522–
529. IEEE.
Yangui, S. and Tata, S. (2014). An OCCI Compliant Model
for PaaS Resources Description and Provisioning. The
Computer Journal, 59(3):308–324.
Zalila, F., Challita, S., and Merle, P. (2017). A Model-
Driven Tool Chain for OCCI. In 25th International
Conference on COOPERATIVE INFORMATION SY-
STEMS (CoopIS), pages 389–409. Springer, Cham.
Model-driven Configuration Management of Cloud Applications with OCCI
111