=Paper=
{{Paper
|id=Vol-1563/paper3
|storemode=property
|title=The Evolution of CloudML and its Applications
|pdfUrl=https://ceur-ws.org/Vol-1563/paper3.pdf
|volume=Vol-1563
|authors=Alexander Bergmayr,Alessandro Rossini,Nicolas Ferry,Geir Horn,Leire Orue-Echevarria,Arnor Solberg,Manuel Wimmer
|dblpUrl=https://dblp.org/rec/conf/models/BergmayrRFHOSW15
}}
==The Evolution of CloudML and its Applications==
https://ceur-ws.org/Vol-1563/paper3.pdf
The Evolution of CloudML and its Manifestations
Alexander Bergmayr1 , Alessandro Rossini2 , Nicolas Ferry2 , Geir Horn3 ,
Leire Orue-Echevarria4 , Arnor Solberg2 , and Manuel Wimmer1
1
TU Wien, Austria
{lastname}@big.tuwien.ac.at
2
SINTEF, Norway
{firstname.lastname}@sintef.no
3
University of Oslo, Norway
Geir.Horn@mn.uio.no
4
TECNALIA, ICT - European Software Institute Division, Spain
Leire.Orue-Echevarria@tecnalia.com
Abstract—Several modelling approaches including CloudML along with UML profiles [11]. The main rationale behind the
emerged to specify the deployment of cloud-based applications latter stems from the goal of the ARTIST project to support
and automate the provisioning of computational resources. migration of existing applications to the cloud, whereby UML
While CloudML was introduced in the REMICS project, its
development continued by ongoing projects, i.e., ARTIST, models are reverse-engineered and tailored to a selected cloud
MODAClouds, and PaaSage. As the evolution of CloudML environment. In contrast, the goal of the MODAClouds and
in the three projects aims for a different goal, a divergence PaaSage projects is to support self-adaptive multi-cloud ap-
between the current project-specific manifestations of CloudML plications, whereby the models are not necessarily reverse-
can be identified. Moreover, as the projects consider different engineered, but rather include dynamic variability to deal with
application scenarios, CloudML has been adapted to their
needs. In this paper, we distil these needs and investigate how multiple cloud environments and especially run-time changes
CloudML is currently manifested in the model-based ecosystems in these environments. As a result of the independent evolution
employed by the projects. We discuss the main challenges that of CloudML in different model-based ecosystems, syntactic as
need to be addressed to achieve a convergence of the current well as semantic divergences can be identified. At the same
CloudML manifestations. time, it seems nevertheless natural that the developed DSLs
Keywords: Cloud Computing, Model-Driven Engineering, share common modelling concepts as a result of their origin
UML, Domain-Specific Language, Cloud Modelling Language, even though all three projects, i.e., ARTIST, MODAClouds,
CloudML and PaaSage, provide model-based support for specific pur-
poses and different application scenarios.
I. Introduction In this paper, we give a brief overview of CloudML by
To address the complexity of specifying and executing discussing its core modelling concepts and the primary needs
cloud-based applications, several modelling approaches in- of the three projects to adapt it to their model-based eco-
cluding CloudML1 (Cloud Modelling Language) [1] have systems. To demonstrate these model-based ecosystems, we
recently been proposed [2], [3]. The REMICS project2 [4] introduce a representative application called SensApp [12] to
introduced CloudML [5] in 2012, with the main aim to which we refer throughout the remaining paper (cf. Section II).
automate the provisioning and deployment of cloud-based The project-specific ecosystems are investigated from the
applications. Several other projects, notably ARTIST3 [6], perspective of how CloudML has been manifested in them (cf.
MODAClouds4 [7], and PaaSage5 [8] are currently continuing Section III). The insights gained by this investigation enables
to develop cloud modelling approaches inspired by CloudML. us to discuss how the DSLs complement each other and even
Because the evolution of CloudML in these projects aim for a more important how their convergence may be achieved in the
different goal and the application scenarios considered by the long term (cf. Section IV). We conclude with an outlook on
projects differ, distinct cloud modelling concepts have been future work (cf. Section V).
introduced in the project-specific manifestations of CloudML.
While the MODAClouds and PaaSage project joined forces II. Modelling in cloud computing
for developing an external domain-specific language (DSL) [9] First, we briefly present the main concepts of CloudML
realised as a metamodel [1], [10], the ARTIST project de- and discuss the primary needs of the three projects to adapt
veloped an internal DSL [9] realised as a UML library it to their model-based ecosystems. Then, we introduce a
representative application in the context of cloud computing.
1 CloudML: http://cloudml.org
2 REMICS EU project: http://remics.eu
3 ARTIST EU project: http://www.artist-project.eu
A. CloudML in a nutshell
4 MODAClouds EU project: http://www.modaclouds.eu The provisioning and deployment of cloud-based applica-
5 PaaSage EU project: http://www.paasage.eu tions is typically carried out based on a deployment topology
capturing the deployable software artefacts, the middleware re-
quired to execute them, and the virtual machines providing the
computational resources of a cloud environment. To address
these requirements, CloudML is inspired by component-based data sensor
approaches to facilitate separation of concerns. A CloudML miner architect
end users registry
model assembles components exposing ports (or interfaces), database
and bindings between these ports. CloudML supports applic-
ation deployments to be specified in terms of cloud provider- sensors
independent models (CPIM), where the refinement into cloud
notification
provider-specific models (CPSM) is foreseen in a separate step. SensApp Admin
dispatcher
The main concepts of CloudML can be summarized as follows
(we refer the reader to [1] for details): Internet of Services Internet of Things
• Internal component: Represents a reusable type of ap-
Figure 1. The SensApp architecture [12]
plication component to be deployed onto an external
component.
• External component: Represents a reusable type of a the technical-related information is exploited in the refinement
virtual machine or platform service. of deployment models towards the selected cloud environment.
• Port: Represents a required or provided port to a feature
of a component. B. SensApp example
• Communication: Represents a communication binding SensApp7 is an open-source, service-oriented application for
between ports of two components, which implies a de- storing and exploiting large data sets collected from sensors
pendency between the components. and devices [12]. Using SensApp it is possible to register
• Hosting: Represents a binding between a component sensors, store their data, and notify clients when new data
deployed onto another one. are pushed.
• Cloud: Represents a collection of virtual machines offered SensApp consists of four main components (see Figure 1).
by a particular cloud provider. The Registry component stores metadata about the sensors.
Moreover, CloudML exploits the type-instance pattern [13] to The Database component stores raw data from the sensors
foster reuse of defined types, e.g., a virtual machine type with in a document-oriented datastore. The Notifier component
specific characteristics. Its abstract syntax is realized in terms sends notifications when relevant data are pushed. Finally, the
of a metamodel6 based on Ecore. Dispatcher component receives data from the sensors, stores
In the MODAClouds and PaaSage project, dedicated tool these data in the Database according to the metadata from
support has been developed to enact the provisioning and the Registry, and then triggers the notification mechanisms
deployment of multi-cloud applications and facilitate dynamic for the new data. SensApp Admin (see Figure 1) exploits
adaptations of provisioned resources at run-time, by leveraging the public REST API of SensApp to provide support for
upon the models@run-time approach [14]. For that reason, sensors management and data visualization using a graphical
CloudML has been adapted to the needs of reasoning, simu- user interface. In order to be deployed, SensApp requires an
lating, and validating adaptation actions before they are carried application container and a database, whilst SensApp Admin
out against components deployed onto a cloud environment. requires an application container.
As cloud environments are inherently elastic in the sense
that provisioned resources can be scaled on-demand, these de- III. Manifestations of CloudML
mands need to be specified for the artefacts of the deployment To give more insights into the evolution of CloudML in
topology usually in terms of scalability rules. Probably the the ARTIST, MODAClouds, and PaaSage projects, we briefly
simplest form of such a rule is to let the cloud environment summarize its manifestation in the model-based ecosystems
decide on provisioning new resources or releasing them. To employed by these projects.
specify more sophisticated custom rules for a target cloud
environment requires dedicated language support as proposed A. ARTIST ecosystem
by the PaaSage project. A major goal of the ARTIST project is to support the mi-
Finally, in the ARTIST project, the selection of the target gration of existing applications towards a cloud-based environ-
cloud environment in the context of a migration scenario ment with the goal to modernise them. This typically implies
has been addressed by introducing concepts that enable not adaptations to the application components. ARTIST advocates
only technical-related information to be captured (e.g., cloud modelling techniques to provide appropriate views that are
services and performance characteristics), but also business- aimed at increasing the engineer’s current understanding of
related ones (e.g., the costs of such services [15]). Particularly, the application components. Clearly, the selected modelling
language to represent such views in terms of models plays
6 CloudML metamodel: https://github.com/SINTEF-9012/cloudml/tree/
master/codecs/kmf/metamodel 7 SensApp: http://sensapp.org
an important role because the purpose of these views is to cloud node refers to the AWSM3Medium virtual machine type,
support engineers in analysing the application from which the DynamoDB service is employed for the required cloud
the models were produced. In the ARTIST project, UML is storage capabilities. Considering the defined stereotype cor-
favoured to reverse engineer models from software artefacts responding to the AWSM3Medium virtual machine type, it is
not only because it is a standardised modelling language annotated with stereotypes provided by meta-profiles devoted
but also it provides multiple modelling viewpoints to spot to pricing and performance information of cloud services. For
potential cloud-oriented opportunities for modernizing soft- instance, this information can be exploited in the process of
ware, platform, and infrastructure artefacts. Moreover, UML selecting the target cloud environment.
profiles facilitate models that capture environment-specific
information, which appears beneficial from a reverse engin-
eering perspective and a forward-engineering perspective [16]. SensApp Components
Considering the latter perspective, specifying cloud-oriented «component»
deployment models directly in UML requires extensions to Database
it, as UML’s standard deployment language does not provide «component» «component»
«use» Notification
modelling concepts specific to cloud environments. Registry
«use»
«use»
To address this need, in the ARTIST project, CloudML has
«component»
been realised as a UML internal DSL based on lightweight Dispatcher
extensions to the deployment viewpoint in terms of a library «manifestation» «manifestation»
and profiles. They are especially beneficial for migration «artifact»
SensApp «manifestation»
scenarios where reverse-engineered UML models are tailored fileName=sensapp.war
towards the environment of the selected cloud provider in
SensApp Deployment
a forward engineering step. To capture environment-specific
:SensApp
information, UML profiles dedicated to well-known cloud
«deploy»
environments, e.g., Amazon AWS8 , Google Cloud Platform9 ,
and Microsoft Azure10 , have been introduced. With the notion :WebContainer «deploy»
container=Jetty
of so called meta-profiles, cloud environment profiles can be «deploy»
refined with typically cross-cutting technical-related details, :CloudStorage
:CloudNode
such as the performance of a virtual machine, and business- dataStructure=
virtualization=Infrastructure DocumentOriented
related information [15], like the upfront and hourly costs of scaling=Auto consistency=eventual
a virtual machine. Exploiting UML profiles to externalize do-
main knowledge of cloud computing enables a clear separation Figure 2. Excerpt of the CPIM of the SensApp example.
between a CPIM and a CPSM, where UML profiles are applied
to a CPIM for the purpose of refining it towards a CPSM as
part of a forward engineering step. «profile»AWSCloudProfile
An excerpt of the CPIM of the SensApp example is depicted «generalPurpose,runningCosts»
«Stereotype»
in Figure 2. It shows SensApp’s main components, their AWSM3Medium
manifestation by a deployable artefact, and the deployment «GeneralPurpose»
memory=3.75
of the artifact in a cloud environment. Because CloudML virtualCores=1
applies the type-instance pattern, it is important to note that localDisk=4
«RunningCosts»
the deployment models depicted in Figure 2 and Figure 3 are value=0.70
specified at the instance level. The respective types are defined currency=USD
metric=Hour
by a model library realizing CloudML. Assigning types to
modelled instance specifications is natively supported by UML «apply»
AWS-based SensApp Deployment
via the classifier relationship. Also, UML supports component-
:SensApp
based modelling by default, which implies that the component
«deploy»
concept as defined by CloudML does not have to be recreated
:WebContainer
in UML. «deploy»
container=Jetty
Considering the deployment viewpoint, Figure 3 shows the «deploy»
result of the refinement from the CPIM towards a CPSM, «aWSM3Medium»
where the target ’platform’ is assumed to be Amazon AWS. :CloudNode «DynamoDB»
virtualization=Infrastructure :CloudStorage
For that reason, the UML profile dedicated to Amazon AWS dataStructure=
scaling=Auto
has been applied to the deployment model. While the modelled «AWSM3Medium» DocumentOriented
operatingSystem=Linux consistency=eventual
region=EU
8 Amazon AWS: http://aws.amazon.com
9 Google Cloud Platform: http://cloud.google.com
10 Microsoft Azure: http://azure.microsoft.com Figure 3. Excerpt of the CPSM of the SensApp example.
B. MODAClouds ecosystem CloudNodeInstance : SL
ML : ML
m1Provided
One of the objectives of the MODAClouds project is to mongoDB : JettySC :
deliver an advanced model-driven approach along with an in- s1 mongoDB
mongoDB
JettySC
sc
ml
tegrated software development environment to support engin- sl mongoDBRequired scRequired
eers in building and deploying multi-cloud applications (i.e., sensapp :
SensAppAdmin :
sensapp restRequired
applications that run across several clouds and exploit services JettySC : SensAppAdmin
AdminSensApp
JettySC
rest
at the infrastructure-, platform-, and software layer), together ml
sc scRequired
with related data [7]. This includes defining quality of service
constraints, monitoring mechanisms, prediction models, and
adaptive policies to provide quality assurance. To achieve
SensAppMinRam SensAppCPUUtilization SensAppUtilization
this objective, a large set of tool-supported domain-specific
languages collectively called MODACloudML has been de-
veloped. MODACloudML relies on the following three layers Figure 4. SensApp deployment model with QoS constraints.
of abstraction: (i) the cloud-enabled computation independent
model (CCIM) to describe an application and its data, (ii) the
CPIM to describe cloud concerns related to the application RAM (e.g., the virtual machine has to offer a minimum of 2GB
in a cloud-agnostic way, and (iii) the CPSM to describe the of RAM), the maximum CPU utilization (e.g., CPU utilization
cloud concerns needed to deploy and provision the application average should not exceed 90%), and the maximum average
on a specific cloud. Within MODACloudML, CloudML is response time (e.g., it should not exceed 5 seconds) required
exploited both at design-time to describe the deployment of to properly execute SensApp.
application components on cloud resources as well as the To facilitate integration and interaction with the other
provisioning of these resources at the CPIM and CPSM levels, MODAClouds design- and run-time components, deployment
and at run-time to manage the deployed applications. As models can also be transformed or specified using a JSON-
a result, CloudML model encompasses runtime information based textual syntax. Listing 1 presents the specification of
such as IP addresses, cloud resources ids and statuses. As the SL virtual machine type that is used to host SensApp. In
a part of MODACloudML, CloudML interacts with CCIM particular, the properties minCores, minRam, and minStorage
models describing the application to be deployed as well as represent the lower bounds of virtual compute cores, RAM,
models exploited for data migration and QoS optimisation and and storage, respectively, of the required virtual machine (e.g.,
performance analysis: minCores=1, minRam=2000). In this case, in order to validate
the QoS constraints, the minRam property is set to 2GB. The
• Data Model: describes the main data structures associated
same set of properties can be specified graphically using the
with the application to be. It can be expressed in terms of
MODAClouds IDE.
typical ER diagrams and enriched by a metamodel that
specifies functional and non-functional data properties. At Listing 1. Virtual machine type in CloudML (JSON syntax).
the CPIM level, this model refines the CCIM data model 1 "vms ": [{
to describe it in terms of logical models. At the CPSM 23 ""name eClass ": "net. cloudml .core:VM",
": "SL",
level, it describes the data model based on the specific 4 " minRam ": "2000" ,
5 " minCores ": "1" ,
data structures implemented by the cloud providers. 6 " minStorage ": "50" ,
• QoS Model: includes QoS properties (e.g., response time) 7 "os ": " ubuntu ",
at the application level as well as QoS properties of cloud 98 "" is64os ": true ,
securityGroup ": " sensapp ",
resources in both a provider-independent (CPIM level) 10 " sshKey ": " cloudml ",
" groupName ": " sensapp ",
and a provider-specific (CPSM level) way. It includes cost 11
12 " privateKey ": " cloudml .pem",
information, thus offering the possibility to estimate an 13 " providedExecutionPlatforms ": [{
14 " eClass ": "net. cloudml .core: ProvidedExecutionPlatform ",
upper-bound for application costs. 15 "name ": " m1Provided ",
• Monitoring rules: control the execution of specific soft- 16 "owner ": "vms[SL]",
}]
ware artefacts, including components and data assigned 17 18 }]
to specific resources. They are used to indicate to the
run-time platform the components to be monitored.
Figure 4 depicts a CloudML CPIM model for the de- C. PaaSage ecosystem
ployment and provisioning of the SensApp application to- In order to cover the necessary aspects of the modelling
gether with associated QoS constraints specified with the and execution of multi-cloud applications, PaaSage adopts
MODAClouds IDE (aka. Creator 4Clouds). In this deployment the Cloud Application Modelling and Execution Language
model, SensApp and the MongoDB are deployed on a single (CAMEL) [17]. CAMEL integrates and extends existing
virtual machine and the SensApp Admin on another one. The DSLs, namely CloudML, Saloon [18], and the Organisation
QoS constraints are associated to the virtual machine called part of CERIF [19]. In addition, CAMEL integrates new
CloudNodeInstance and specify the minimum amount of DSLs developed within the project, such as the Scalability
Rule Language (SRL) [20]. CAMEL enables engineers to 7 provided communication RESTProv {port: 8080}
required communication MongoDBReq { mandatory }
specify multiple aspects of multi-cloud applications, such 98 required host LL
as provisioning and deployment topology, provisioning and 10 configuration SensAppConfiguration {
download : "wget -P ..."
deployment requirements, service-level objectives, metrics, 11 12 install : "sudo bash ..."
scalability rules, providers, organisations, users, roles, secur- 13 }
}
ity controls, execution contexts, execution histories, etc. To 14 15 }
facilitate the integration across the components managing the 16 scalability model SensAppScalability {
life cycle of multi-cloud applications, PaaSage leverages upon 1817 scalability rule AvgExecutionTimeRule {
event: SensAppScalability . AvgExecutionTimeViolation
CAMEL models that are progressively refined throughout the 19 actions [ SensAppScalability . HorizontalScaleSensApp ]
20 }
modelling, deployment, and execution workflow phases: 21 horizontal scaling action HorizontalScaleSensApp {
• Modelling phase: Similar to MODAClouds, the envi- 22 type: SCALE OUT
vm: SensApp .LL
sioned PaaSage engineer designs a CPIM, which specifies 23 24 internal component : SensApp . SensApp
the deployment artifacts of a multi-cloud application 25 count: 1
}
along with its requirements and objectives in a cloud 26 27 non - functional event AvgExecutionTimeViolation {
provider-independent way. 28 metric condition : SensAppMetric . AvgExecutionTimeGT1000
29 violation
• Deployment phase: The Profiler component consumes the
30 }
CPIM, matches this model with the profile of cloud pro- 31 }
viders, and produces a constraint problem. The Reasoner 3332 metric model SensAppMetric {
metric condition AvgExecutionTimeGT5000 {
component solves the constraint problem (if possible) 34 context : SensAppMetric . AvgExecutionTimeGT5000
threshold : 5000.0
and produces a CPSM, which specifies the deployment 35 36 comparison operator : >
of a multi-cloud application along with its requirements 37 }
composite metric context AvgExecutionTimeGT5000 {
and objectives in a cloud provider-specific way. The 38 39 metric : SensAppMetric . AvgExecutionTime
Adapter component consumes the CPSM and produces 40 application : SensApp
window : SensAppMetric . WindowFiveMin
deployment plans, which specify platform-specific details 4142 schedule : SensAppMetric . ScheduleOneMin
of the deployment. 43 composing metric contexts [ SensAppMetric .
RawExecutionTimeContext ]
• Execution phase: The Executionware [25] consumes the
44 quantifier : ALL
deployment plans and enacts the deployment of the 45 }
composite metric AvgExecutionTime {
application components on suitable cloud infrastructures. 46 47 property : SensAppMetric . ExecutionTime
Finally, the Executionware records historical data about 48 unit: SensAppUnit . milliseconds
value type: SensAppType . AvgExecutionTimeRange
the application execution, which allows the Reasoner 49 50 metric formula AvgExecutionTimeFormula {
to look at the performance of previous CPSMs when 51 function arity: UNARY
52 MEAN ( SensAppMetric . RawExecutionTime )
producing a new one. 53 }
At the beginning of the PaaSage project, CAMEL consisted of 54 }
a family of loosely coupled DSLs, where the first member of 55 }
the family was CloudML. During the course of the project, this
family of loosely coupled DSLs was transformed into a single IV. Convergence of CloudML manifestations
DSL. To integrate concepts from multiple DSLs into CAMEL, We summarise main challenges that need to be addressed
we adopted the Eclipse Modelling Framework (EMF). The for a convergence of the existing CloudML manifestations.
current version of CAMEL is realized in terms of an Ecore-
based metamodel organised into packages that include cross A. External DSL vs. UML internal DSL
references as a result of the integration. As UML supports multiple viewpoints, CloudML and UML
Listing 2 shows a CAMEL CPIM whereby the deployment overlaps in several respects, particularly when the component
model can be regarded as a variant of a CloudML model viewpoint and deployment viewpoint is considered. To achieve
while the scalability and metric models are SRL models. The a convergence between the CloudML manifestations requires
scalability model refers to the virtual machine LL (line 24) consideration of UML concepts in addition to the concepts
in the deployment model as well as the composite metric introduced by CloudML itself and the project-specific mani-
context AvgExecutionTimeGT5000 (line 28) in the metric model. festations of it. For instance, components and ports are defined
This scalability model specifies that the virtual machine should by both CloudML and UML. At the same time, the differenti-
scale out every time the average execution time in the last five ation between internal and external components is specific to
minutes is greater than 5000 milliseconds. CloudML. This differentiation, i.e., the specification of cloud
services required for an application deployment, is supported
Listing 2. SensApp deployment, scalability, and metric models in CAMEL. via UML profiles by ARTIST’s model-based ecosystem.
1 deployment model SensAppDeployment {
2 vm LL {
3 requirement set LLReqSet B. Profiles for cloud environment-specific information
4 provided host LL
5 }
The specification of cloud-specific deployment models may
6 internal component SensApp { differ between the ecosystems of the projects. This is because
UML profiles introduce an additional typing dimension. These References
types need to be either introduced in terms of a properly [1] N. Ferry, H. Song, A. Rossini, F. Chauvel, and A. Solberg, “CloudMF:
structured type hierarchy in CloudML or translated into Applying MDE to Tame the Complexity of Managing Multi-Cloud
corresponding EMF profiles [21]. Because EMF profiles are Applications,” in UCC, 2014, pp. 269–277.
[2] A. Bergmayr, M. Wimmer, G. Kappel, and M. Grossniklaus, “Cloud
generally applicable to Ecore-based metamodels and so to Modeling Languages by Example,” in SOCA, 2014, pp. 137–146.
CloudML, generating EMF profiles from the UML profiles [3] R. F. Paige, J. Cabot, M. Brambilla, L. M. Rose, and J. H. Hill, Eds.,
developed in the ARTIST project appears beneficial. The typ- Workshop Proceedings of CloudMDE, vol. 1242, 2014.
[4] P. Mohagheghi, A. Berre, A. Henry, F. Barbier, and A. Sadovykh,
ing dimension supported by profiles can directly be exploited “REMICS- REuse and Migration of Legacy Applications to Interop-
for CloudML models developed in the MODAClouds and erable Cloud Services,” in Towards a Service-Based Internet, 2010, pp.
PaaSage project to explicitly represent a CPSM produced 195–196.
[5] E. Brandzæg, S. Mosser, and P. Mohagheghi, “Towards CloudML,
from a CPIM. Deployment models for multi-cloud applica- a Model-Based Approach to Provision Resources in the Clouds,” in
tions can be represented by applying multiple profiles that CloudMDE, 2012, pp. 18–27.
correspond to the selected cloud environments. Dynamically [6] A. Bergmayr, H. Bruneliere, J. L. Cánovas Izquierdo, J. Gorroñogoitia,
G. Kousiouris, D. Kyriazis, P. Langer, A. Menychtas, L. Orue-Echevarria
switching between deployment targets is enabled by (un-/re- Arrieta, C. Pezuela, and M. Wimmer, “Migrating Legacy Software to
)applying respective cloud environment profiles, which can the Cloud with ARTIST,” in CSMR, 2013, pp. 465–468.
be considered as an alternative approach to switch between [7] D. Ardagna, E. D. Nitto, P. Mohagheghi, S. Mosser, C. Ballagny,
F. D’Andria, G. Casale, P. Matthews, C.-S. Nechifor, D. Petcu, A. Ger-
ontological types that capture the respective environment- icke, and C. Sheridan, “MODAClouds: A Model-Driven Approach for
specific information. The latter approach is currently supported the Design and Execution of Applications on Multiple Clouds,” in MISE,
by the MODAClouds and PaaSage projects. 2012, pp. 50–56.
[8] K. Jeffery, G. Horn, and L. Schubert, “A Vision for Better Cloud
Applications,” in MultiCloud, 2013, pp. 7–12.
C. Possible semantic heterogeneities [9] M. Fowler, Domain-Specific Languages. Addison-Wesley Professional,
The operational semantics may differ between the ecosys- 2010.
[10] N. Ferry, A. Rossini, F. Chauvel, B. Morin, and A. Solberg, “Towards
tems of the projects: the first maps to TOSCA [22] in order model-driven provisioning, deployment, monitoring, and adaptation of
to exploit OpenTOSCA [23] for enacting the provisioning multi-cloud systems,” in CLOUD, 2013, pp. 887–894.
and deployment of cloud-based applications, the second is [11] A. Bergmayr, J. Troya, P. Neubauer, M. Wimmer, and G. Kappel,
“UML-based Cloud Application Modeling with Libraries, Profiles and
based on the Cloud Modelling Framework (CloudMF) [1] and Templates,” in CloudMDE, 2014, pp. 56–65.
its models@run-time engine, and the third is based on the [12] S. Mosser, F. Fleurey, B. Morin, F. Chauvel, A. Solberg, and I. Goutier,
model-based Upperware [24] and Executionware [25]. As a “SENSAPP as a Reference Platform to Support Cloud Experiments:
From the Internet of Things to the Internet of Services,” in SYNASC,
result, a comparison of deployment models together with the 2012, pp. 400–406.
provisioned cloud resources needs to be carried out before [13] C. Atkinson and T. Kühne, “Rearchitecting the UML infrastructure,”
a convergence of the different CloudML manifestations can TOMACS, vol. 12, no. 4, pp. 290–321, 2002.
[14] B. Morin, O. Barais, J.-M. Jézéquel, F. Fleurey, and A. Solberg,
properly be achieved. The comparison can be achieved using “Models@Run.time to Support Dynamic Adaptation,” IEEE Computer,
a by-example approach on the basis of SensApp. Based on vol. 42, no. 10, pp. 44–51, 2009.
the created deployment models, respective deployment plans [15] J. Cardoso, A. Barros, N. May, and U. Kylau, “Towards a Unified
Service Description Language for the Internet of Services: Requirements
need to be generated. Executing these deployment plans by the and First Developments,” in SCC, 2010, pp. 602–609.
employed provisioning engines enables to compare the cloud [16] A. Bergmayr, M. Grossniklaus, M. Wimmer, and G. Kappel, “JUMP -
resources provisioned on a common target cloud environment. From Java Annotations to UML Profiles,” in MODELS, 2014, pp. 552–
568.
[17] A. Rossini and the PaaSage consortium, “D2.1.3 – CAMEL Document-
V. Conclusion ation (Final version),” PaaSage project deliverable, October 2015.
As the evolution of CloudML resulted in divergent language [18] C. Quinton, D. Romero, and L. Duchien, “Cardinality-based feature
models with constraints: a pragmatic approach,” in SPLC, 2013, pp.
manifestations, their convergence appears desirable for the 162–166.
purpose of resolving existing heterogeneities and enabling [19] K. Jeffery, N. Houssos, B. Jörg, and A. Asserson, “Research Information
models to be exchanged between the model-based ecosystems Management: The CERIF Approach,” IJMSO, vol. 9, no. 1, pp. 5–14,
2014.
employed by the projects. We aim to define correspondences [20] K. Kritikos, J. Domaschka, and A. Rossini, “SRL: A Scalability Rule
between the various language concepts. This enables hetero- Language for Multi-Cloud Environments,” in CloudCom, 2014, pp. 1–9.
geneities to be resolved in a non-intrusive manner. Moreover, [21] P. Langer, K. Wieland, M. Wimmer, and J. Cabot, “EMF profiles: A
lightweight extension approach for EMF models,” JOT, vol. 11, no. 1,
we aim for model transformations that encode the corres- pp. 1–29, 2012.
pondences, thereby enabling models to be exchanged at least [22] T. Binz, U. Breitenbücher, O. Kopp, and F. Leymann, “TOSCA: Portable
partially. As a result, migration techniques of the ARTIST Automated Deployment and Management of Cloud Applications,” in
Advanced Web Services, 2014, pp. 527–549.
project may be applied by the MODAClouds and PaaSage [23] T. Binz, U. Breitenbücher, F. Haupt, O. Kopp, F. Leymann, A. Nowak,
model-based ecosystems to enable multi-cloud deployment and S. Wagner, “OpenTOSCA - A Runtime for TOSCA-Based Cloud
models to be specified based on reverse-engineered models of Applications,” in ICSOC, 2013, pp. 692–695.
[24] C. Perez and the PaaSage consortium, “D3.1.2 – Model Based Cloud
existing applications. At the same time, the ARTIST model- Platform Upperware,” PaaSage project deliverable, October 2015.
based ecosystem may benefit from the support of deploying [25] D. Baur, S. Wesner, and J. Domaschka, “Towards a Model-Based
applications to multiple cloud environments as provided by Execution-Ware for Deploying Multi-cloud Applications,” in Advances
in Service-Oriented and Cloud Computing, 2015, pp. 124–138.
the MODAClouds and PaaSage projects.