CC BY-NC-ND
0CrossMark
Available online at www.sciencedirect.com
ScienceDirect
Procedía Computer Science 68 (2015) 53 - 66
HOLACONF - Cloud Forward: From Distributed to Complete Computing,
Integration of DSLs and migration of models: a case study in the cloud computing domain
Nikolay Nikolova*, Alessandro Rossinia, Kyriakos Kritikosb
aSINTEF, Oslo, Norway bFORTH, Heraklion, Greece
Abstract
Domain-specific languages (DSLs) are high-level software languages representing concepts in a particular domain. In real-world scenarios, it is common to adopt multiple DSLs to solve different aspects of a specific problem. As any other software artefact, DSLs evolve independently in response to changing requirements, which leads to two challenges. First, the concepts from the DSLs have to be integrated into a single language. Second, models that conform to an old version of the language have to be migrated to conform to its current version. In this paper, we discuss how we tackled the challenge of integrating the DSLs that comprise the Cloud Application Modelling and Execution Language (CAMEL) by leveraging upon Eclipse Modeling Framework (EMF) and Object Constraint Language (OCL). Moreover, we propose a solution to the challenge of persisting and automatically migrating CAMEL models based on Connected Data Objects (CDO) and Edapt.
© 2015TheAuthors.Published by ElsevierB.V.This is an open access article under the CC BY-NC-ND license (http://creativecommons.Org/licenses/by-nc-nd/4.0/).
Peer-review under responsibility of Institute of Communication and Computer Systems.
Keywords: model-driven engineering; domain-specific language; metamodel migration; model co-evolution; cloud computing; CAMEL; EMF; OCL; CDO; Edapt
1. Introduction
Cloud computing provides a ubiquitous networked access to a shared and virtualised pool of computing capabilities that can be provisioned with minimal management effort1. Cloud-based applications are applications that are deployed on cloud infrastructures and delivered as services. The PaaSage project (see http://www.paasage.eu) aims to facilitate the modelling and execution of cloud-based applications by leveraging upon model-driven engineering (MDE) techniques and methods, and by exploiting multiple cloud infrastructures.
Models can be specified using general-purpose languages like the Unified Modeling Language (UML)2. However, to fully unfold the potential of MDE, models are frequently specified using domain-specific languages (DSLs), which are tailored to a specific domain of concern. In order to cover the necessary aspects of the modelling and execution of multi-cloud applications, PaaSage adopts the Cloud Application Modelling and Execution Language (CAMEL)3. CAMEL integrates and extends existing DSLs, namely Cloud Modelling Language (ClqudML)4,5,6,7, Saloon8,9, and
* Corresponding author. E-mail address: nikolay.nikolov@sintef.no
1877-0509 © 2015 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.Org/licenses/by-nc-nd/4.0/).
Peer-review under responsibility of Institute of Communication and Computer Systems. doi: 10.1016/j.procs.2015.09.223
the Organisation part of CERIF10. In addition, CAMEL integrates new DSLs developed within the project, such as the Scalability Rule Language (SRL)11,12. The cloud aspects covered by CAMEL include provisioning and deployment topologies and requirements, service-level objectives, metrics, scalability rules, providers, organisations, security controls and requirements, as well as execution contexts and histories.
Uncoupled and heterogeneous DSLs may not guarantee the consistency, correctness, integrity, and uniqueness of information specified to solve different aspects of a specific problem. This was also the case at the beginning of the PaaSage project, so we coupled and homogenised multiple DSLs by integrating them into the single language CAMEL. In this paper, we discuss how we tackled this challenge by leveraging upon Eclipse Modeling Framework (EMF) (see https://www.eclipse.org/modeling/emf/) and Object Constraint Language (OCL)13.
DSLs undergo constant evolution in order to better capture the concepts of a domain. Whereas established DSLs are not subject to frequent updates, this is not the case for newly developed DSLs. This is also the case in the PaaSage project, so we considered automating the migration of CAMEL models from an old version of the language to its current version. In this paper, we propose a solution to this challenge based on Connected Data Objects (CDO) (see https://www.eclipse.org/cdo/)and Edapt (see https://www.eclipse.org/edapt/).
The remainder of the paper is organised as follows: Section 2 introduces CAMEL and its role in the PaaSage workflow. Section 3 describes the main challenges faced during the development of CAMEL, while Sections 4 and 5 propose solutions for them. The related work is analysed in Section 6. Finally, Section 7 concludes the paper and provides future work directions.
2. PaaSage and CAMEL
In order to facilitate the integration across the components managing the life cycle of multi-cloud applications, PaaSage leverages upon CAMEL models cross-cutting the aforementioned aspects. These models are progressively refined throughout the modelling, deployment, and execution phases of the PaaSage workflow (see Figure 1).
Modelling Deployment Execution phase phase phase
Figure 1. CAMEL models in the PaaSage workflow
Modelling phase. The PaaSage users design a cloud-provider independent model (CPIM), which specifies the deployment of a multi-cloud application along with its requirements and objectives (e.g., on virtual hardware, location, and service level) in a cloud provider-independent way.
For instance, a PaaSage user could specify a CPIM of SensApp (see http://sensapp.org/), an open-source, service-oriented application for storing and exploiting large data sets collected from sensors and devices. Figure 2(a) shows the CPIM in graphical syntax. It consists of a SensApp servlet, which is hosted by a Tomcat servlet container, which in turn is hosted by a GNU/Linux virtual machine. Moreover, the SensApp servlet communicates with a MongoDB database, which is hosted by a GNU/Linux virtual machine in a data centre in Norway. Finally, the SensApp servlet must have a response time below 100 ms.
Deployment phase. The Profiler component consumes the CPIM, matches this model with the profile of cloud providers, and produces a constraint problem. The Reasoner component solves the constraint problem (if possible) and produces a cloud-provider specific model (CPSM), which specifies the deployment of a multi-cloud application along with its requirements and objectives in a cloud provider-specific way.
For instance, the Profiler could match the CPIM of SensApp with the profile of cloud providers, identify EVRY and Telenor as the only two cloud providers offering GNU/Linux virtual machines in data centres in Norway, and produce a corresponding constraint problem. Then, the Reasoner could rank EVRY as the best cloud provider to satisfy the requirements in the CPIM, and produce a corresponding CPSM. Figure 2(b) shows the CPSM in graphical syntax. It consists of two SensApp servlet instances, which are hosted by two Tomcat container instances, which in turn are hosted by two Ubuntu 14.04 virtual machine instances at Amazon EC2 in the EU. Moreover, the SensApp servlet instances communicate with a MongoDB database instance, which is hosted by a CentOS 7 virtual machine instance at EVRY in Norway.
The Adapter component consumes the CPSM and produces a deployment plan, which specifies platform-specific details of the deployment.
Execution phase. The Executionware consumes the deployment plan and enacts the deployment of the application components on suitable cloud infrastructures. It also records historical data about the application execution, which allows the Reasoner to continuously revise the solution to the constraint problem to better exploit the cloud infrastruc-
i— Types -|
MongoDB
sensAppl I sensApp2
tomcatl I tomcat2
ubuntul I ubuntu2
Amazon EC2
[location = EUl
[location = NO]
3. Challenge
Figure 2. Sample CAMEL models: (a) CPIM; (b) CPSM
The abstract syntax of a language describes the set of concepts, their attributes, and their relations, as well as the rules for combining these concepts to specify valid statements that conform to this abstract syntax. The concrete syntax of a language describes the textual or graphical notation that renders these concepts, attributes, and relations.
In MDE, the abstract syntax of a DSL is typically defined by its metamodel, which allows specifying valid models conforming to this metamodel2. Moreover, in MDE, the concrete syntax may vary depending on the domain, e.g., a DSL could provide a textual notation as well as a graphical notation along with the corresponding serialisation in XML Metadata Interchange (XMI)14.
At the beginning of the PaaSage project, CAMEL consisted of a family of uncoupled and heterogeneous DSLs, each having their own abstract and concrete syntaxes. Moreover, the models specified using these DSLs were persisted in a relational database, the so-called Metadata Database (MDDB)15.
This initial solution illustrates some of the challenges that are inherent to DSL integration and evolution. First, the elements in the metamodels of the DSLs needed to be matched to the elements in the schema of the MDDB using a custom mapping. Such a mapping needed to be bi-directional, since the data persisted in the MDDB had to be transformed back to the (abstract or concrete) syntax of the corresponding DSL. Second, the size of the schema became large as it needed to cover a considerable number of concepts from the DSLs - the last version had 70 tables and multiple referential integrity constraints. Third, the custom queries for reading and writing data also became complex. Finally, although they were designed to cover most aspects of a multi-cloud deployment16, both the DSLs and the MDDB needed to evolve to cope with the changing requirements in the domain. This evolution affected the metamodels of the DSLs, the schema of the MDDB, the data persisted in the MDDB, and the back-end code managing this data. Therefore, we quickly realised that we needed a better solution than the time-consuming and error-prone custom mapping approach, and opted for an integration approach, whereby the family of uncoupled and heterogeneous DSLs was transformed into a single language.
The integration approach had to overcome certain language-specific issues. First, concepts from the DSLs were defined at different levels of detail and granularity, depending to the specific use within the domain. Second, similar or equivalent concepts were duplicated and defined with heterogeneous syntaxes and semantics. Therefore, the integration solution had to couple and homogenise the DSLs to ensure that the concepts in the resulting language were defined at the same level of granularity and that no concepts (along with properties and references) were duplicated.
4. DSL Integration
In order to integrate the multiple DSLs into CAMEL, we adopted EMF and OCL. In this section, we outline these technologies and describe how they fit the requirements of the PaaSage platform.
4.1. Eclipse Modeling Framework
EMF is a modelling framework that facilitates defining DSLs. EMF provides the Ecore metamodel, which is the core metamodel of EMF and allows specifying Ecore models. The CAMEL metamodel is an Ecore model that conforms to the Ecore metamodel (see Figure 3). The Ecore metamodel, in turn, is an Ecore model that conforms to itself {i.e., it is reflexive).
conforms to
metamodel of
Ecore Metamodel
conforms to
metamodel of
Ecore Model
rnnfnrrrr; tn
CAMEL Model
Figure 3. The Ecore-based modelling stack in PaaSage
EMF allows generating Java class hierarchy representations of the metamodels based on those definitions. The Java representations provide a set of APIs that enables the programmatic manipulation of models. In addition, EMF provides code generation facilities that can be used to automatically generate a tree-based editor, as well as frameworks such as Graphical Modeling Framework (GMF) (see https://www.eclipse.org/modeling/gmp/) or Graphical Editing Framework (GEF) (see https: //www. eclipse. org/gef/) to manually create a custom graphical editor.
EMF enables checking of cardinality constraints on properties, creating classification trees, automatically generating code, and validating the produced models according to their metamodels. However, it lacks the expressiveness required for capturing (part of) the semantics of the domain, and hence cannot guarantee the consistency, correctness, and integrity of information in CAMEL models at both design-time and run-time. For instance, consider service level objectives (SLOs). SLOs consist of conditions over service level metrics while SLOs assessments consist of evaluating these conditions over the corresponding service level metric instances. In CAMEL, metrics and their instances are specified in metric models, SLOs are specified in requirements models, and SLO assessments are specified in execution models. Therefore, the cross-references across these models have to be checked for consistency, correctness,
In order to validate CAMEL models, we annotated the CAMEL metamodel with OCL constraints. OCL is a declarative language for specifying expressions such as constraints and queries on Meta-Object Facility (MOF)17 models and metamodels. OCL is also an integral part of the Queries/Views/Transformations (QVT)18 specification, where it is adopted in the context of model transformation. The Eclipse Model Development Tools (MDT) (see http: //www. eclipse. org/modeling/mdt/) project includes the Eclipse OCL (see http: //wiki. eclipse. org/OCL) component, which is a tool-supported implementation of the OCL declarative language, compatible with EMF. The OCL constraints are attached to the elements of the CAMEL metamodel and evaluated on the instances of these elements. By navigating the cross-references across models, these OCL constraints guarantee the consistency, cor-
In order to persist and automatically migrate CAMEL models, we adopted Connected Data Objects (CDO) and Edapt. In this section, we first outline these technologies and describe how they fit the requirements of the PaaSage platform. Then, we analyse how these technologies have been extended in order to fulfil the goals of automating the
CDO is semi-automated persistence framework that works natively with Ecore models and their instances. It can be used as a model repository where clients persist and distribute their models. CDO abstracts away the specific underlying database and allows DSL developers and users to focus on the modelling process. Additionally, the framework automatically takes care of the bi-directional mapping of models to (relational) data. Additionally, it provides features that satisfy the design-time and run-time requirements of the PaaSage platform, such as:
• Transaction: CDO supports transactional manipulations of the models persisted in the repository. This ensures that the models persisted in the repository are valid at any time, so that the components of the PaaSage workflow
• Validation: CDO supports automatic checking of the conformance between the models persisted in the repository and their metamodel. This also ensures that the models persisted in the repository are valid at any time.
• Versioning: CDO supports optimistic versioning19, where each client of the repository has a local (or working) copy of a model. These local copies are modified independently and in parallel and, as needed, local modifications can be committed to the repository. Non-overlapping changes are automatically merged. Otherwise, they are rejected, and the model is put in a conflict state that requires manual intervention.
• Automatic Notification: CDO automatically notifies clients about changes in the state of the models persisted in the repository. This allows PaaSage components to monitor certain models or parts of the models and respond
• Auditing: CDO automatically records the history of revisions of each model since its creation, thus allowing to
• Role-based Security: CDO provides role-based access control to the models persisted in the repository, thus supporting the controlled access to (parts of) models by different components and actors in the PaaSage workflow.
5.2. Edapt
As mentioned, models that conform to an old version of CAMEL have to be migrated to conform to its current version. This functionality is provided by Edapt, which is an EMF framework to migrate instances of an Ecore model after changing its respective metamodel. In Edapt, metamodel evolution is recorded as a history of changes, which encompasses the operations that have been performed in the metamodel (e.g., add, delete, rename, etc.). These operations can be basic operations that can be performed on single elements of the metamodels, as well as composite operations stored in a library accessible within the Ecore model editor. Then, model migration is based on this history of changes and is performed automatically.
Edapt is suited to deal with pure Ecore models and, at the time of writing of this paper, is not integrated to work with CDO repositories. Such an integration implies solving a large number of technical challenges. In the following, we describe some of these challenges and propose a solution that addresses them.
5.3. Extensions to CDO and Edapt
The extensions to CDO and Edapt consist of three main components: the DSL Integration and Evolution Manager, the Migration Node, and the Historical Repository Node. Figure 4 shows the architecture of the proposed solution.
Administrative Client v_;
Figure 4. Architecture of the proposed solution
The DSL Integration and Evolution Manager exposes a set of APIs designed to serve different needs of different clients. In particular, we consider three types of clients: DSL Development Environments, Model Processing Applications and Administrative Clients. DSL Development Environments use the APIs for storing and retrieving metamodels along with their history of changes. Model Processing Applications use the APIs for storing and retrieving models possibly conforming to different metamodel releases. Finally, Administrative Clients use the APIs to control the life cycles of the underlying repositories and perform migrations of models and metamodels. The Historical Repository Node is a customised CDO repository capable of storing models conforming to different releases of the same metamodel. The Migration Node is used to migrate stored model data based on an extension of Edapt that works with CDO repositories.
5.4. DSL Integration and Evolution Manager
As mentioned, the DSL Integration and Evolution Manager is the component that orchestrates the execution of storing and migrating model data. Figure 5 shows a detailed view of the DSL Integration and Evolution Manager.
The DSL Integration and Evolution Manager controls the Migration Node and Historical Repository Node. We designed the component with distributed DSL development in mind, so that its functionality is exposed through the use of web services.
DSL Integration and Evolution Manager
Administrative APIs
Metamodel development APIs
I . I DSL Evolution and I I Nodes Manager
Model consumption APIs
Migration Node
Historical Repository Node
Figure 5. DSL Integration and Evolution Manager
Each of the web services has a distinct set of APIs associated with the different tasks that need to be performed by the component. Access to these services is controlled, so that only the clients with appropriate credentials can use them.
The Administrative APIs expose functionalities associated with the administration of nodes. Through these APIs, clients can initiate migrations, backup and purge repositories, or gain low-level access to the underlying repositories. Furthermore, clients can also receive notifications of life cycle events in the repository. We envision these APIs to be available to system administrators only.
The Metamodel Development APIs expose functionality associated with metamodel and release management. Through these APIs, clients can store and retrieve metamodels (not models) to and from the Migration Node and Historical Repository Node. Moreover, clients can register new releases of the metamodels along with any associated custom metamodel and model migration definitions in Java. Finally, through a set of event-based APIs, clients can also receive notifications about changes to the state of metamodels, which enables collaborative and integrated DSL development. We envision these APIs to be incorporated and used within the DSL Development Environment of the EMF editor, so that the metamodelling is further streamlined.
The Model Consumption APIs expose functionality associated with model management. Through these APIs, clients can store and retrieve models to and from the Migration Node and Historical Repository Node. Note that the models could possibly conform to different releases of the same metamodel. The release could be the latest (using the Migration Node), a pre-specified one, or the release to which the model conformed (using the Historical repository node) when last stored.
The DSL Evolution Nodes Manager is the control component that manages the historical repository and migration nodes. It also exposes appropriate functionality to the web services front ends.
5.5. Migration Node
The Migration Node contains the business logic associated with performing migrations of models. Figure 6 shows its sub-components.
The CDO Migrator sub-component takes advantage of the Edapt run-time libraries, which realise the basic migration operations that can be performed on a model according to the corresponding history of changes of its metamodel. CDO supports a failure tolerant mode of operation, whereas instead of having one single repository, CDO can be configured to work in a cluster with a master repository. We use two repositories: the CDO Primary Repository and the CDO Auxiliary Repository. The former contains the models that conform to the current metamodel release. The latter is
I . I Edapt I I Runtime
I . I CDO
| | Migrator
Figure 6. Migration Node
used during the metamodel migration process to store the new models that conform to the target metamodel release. After the migration has ended, we purge the CDO Primary Repository and switch the roles of the two repositories. In order to expose low-level functions of CDO, these repositories are surrounded by a wrapper that enables access and modification of the CDO concept-table mappings and APIs for clearing the contents of the underlying stores.
As discussed in Section 5.2, Edapt is not integrated with CDO repositories yet. For the specific purposes of migration in that context, we developed a proprietary algorithm. It is inspired by the step-wise manual relational dataware co-evolution approach discussed in Section 6. We divide our algorithm in three phases: preparation, migration, and repository switch phase. In the following, we detail the implementation of the migration algorithm.
1. Preparation phase: During this phase, we make sure that the CDO Migrator has at its disposal all the needed information about the migration. The input of the CDO Migrator is a set of URIs that identify the location of the models that need to be migrated, the history of changes of the metamodel, as well as source and target releases. Each resource contains a number of objects, which instantiate the various concepts from the different packages of the CAMEL model. We permit the specification of references that cross resource (model) boundaries in order to minimise redundancy of information in the repository.
1.1 Validation of releases: During this step, we perform checks to ensure that the source and target releases are valid. If the target release has not been set, we imply the latest release.
1.2 Gathering of related resources (models): In order to ensure the success of the migration, we need to employ certain heuristics. This is because the input set of URIs of resources to be migrated might be missing the URIs that reference or are referenced by the ones listed in the input set. An example of a situation that might occur is depicted in Figure 7.
Let us suppose that we have to migrate Resource 3. The resource contains a reference from Object 6 to Object 7. Since both objects reside in the same resource, the migration can be successfully completed without any loss of data. However, this is not the case if we have to migrate Resource 1 instead. If we simply migrate only the selected resource, we would, first of all, lose information about the references in the contained objects (Object 1 has a reference to Object 4). Later, when copying Resource 2, we would also lose information about the already migrated Resource 1 (Object 4 has a reference to Object 2). Such inconsistencies are undesirable, so we take steps to avoid them. The references that can cause this type of situation are referred to as noncontainment proxy references. Note that we do not consider containment proxy references simply because, by default, CDO moves all objects referenced by such constructs to the resource that has the containment. We apply this heuristic under the assumption that the client to the migrator is not (and should not be) always necessarily aware of all of the references from and to the model it has to migrate. This holds especially well
Resource (Model) 1 ( Object 1 )- Resource (Model) 2 _____________ / \ 1 / \ Object 4 ) ! \ J \ / / --------- / ---- Resource (Model) 3 ; f Object 6 J
f ( Object 2 V ( Object 3 J X_____y | f Object 5 J ! [ | ( Object 7 J i
Figure 7. Referencing example
in the case of PaaSage, as the CAMEL metamodel consists of a collection of packages with cross-references between them, where each package originates from standalone DSLs such as CloudML, etc. In order to cope with the aforementioned issues, we perform a preliminary gathering of related resource references by traversing the entire object graph of the resources selected for migration. All non-referenced resources encountered are thus appended to the list of input resources to be migrated. The newly found resources' object graphs are also traversed, until we are left with no such referenced resources.
1.3 Creating target repository URIs: Using the URIs of the source resources along with information provided by the CDO wrapper of the CDO Auxiliary Repository, we create a set of target URIs that point to newly created resources in this repository. Their paths are formed by obtaining the resource paths of the source resources and simply copying them. After this step, we are ready to start the migration to the CDO Auxiliary Repository.
2. Migration phase: During this phase, we perform the actual migration from the source to the target release.
2.1 Migration of input resources: During this step, we migrate resources that contain proxy references from or to objects contained in each selected resource, along with the selected resources themselves. Here, we use the Edapt run-time APIs. This involves deserialising CDO resources (representing models) and packages (representing metamodels) and serialising them into according internal Edapt representations. After that, the Edapt migrator takes over and implements the necessary migrations based on the history and input source and target releases. Any custom migrations are assumed to be available in the environment of the migration.
2.2 Copying remaining resources: After having successfully completed the migration of the resources, we can copy the remaining ones to the auxiliary repository. Since we expect to have a large number of remaining resources, we copy them one by one, taking care to check and add proxy-referenced resources to the list of resources to copy. These checks are done in the same manner as in the preparation phase.
3. Repository switch phase: after the migration has been completed, all of the models of the source repository have been copied to the CDO Auxiliary Repository and conform to the desired metamodel release. Therefore, the information in the CDO Primary Repository is now stale. In order to enable work with the most current information, we now purge the CDO Primary Repository and switch the roles between the two. This concludes the migration algorithm.
It is worth mentioning that successful migration is ensured by model validation checks. These checks include checking for conformance to the metamodel, including any OCL constraints attached to the metamodel. They are performed after the serialisation to the Edapt internal metamodel/model formats (by the Edapt framework) and at each transaction commit (by the CDO run-time) during the migration phase.
5.6. Historical Repository Node
The Historical Repository Node provides functionality to store models based on different releases of the same metamodel. It is inspired by the ideas on object-oriented versioning dataware metamodel/model co-evolution discussed in Section 6. Figure 8 shows its sub-components.
Historical Repository Node
I - I CDO Mapping I I Customizer
Figure 8. Historical Repository Node
In essence, our historical repository implementation uses a customisation over the proprietary CDO concept-table mappings in order to ensure that the different releases of the metamodels are mapped to tables differently. In order to ensure this in 100% of the cases, we use the namespace URIs and namespace prefixes defined in the metamodels. URIs and prefixes are associated with each of the packages contained in a metamodel. We operate under the assumption that they are unique even across different releases of the same metamodel. This assumption holds, as Edapt requires for users to define a different namespace URI at each release in order for it to internally differentiate between the different ones. The resulting table names consists of the namespace prefix concatenated with the path defining the namespace URI, where all special symbols (e.g., /, ., etc.) that are not supported as valid database table name characters are replaced by an underline (_). The annotation task is done by the CDO Mapping Customiser component and the results are persisted in a CDO History Repository.
It has to be noted that with this component, we do not support forward or backward migrations - this is simply a customisation of the CDO basic concept-table mapping that allows co-existence of models conforming to different releases of the same metamodel. This makes it possible for components that have not been updated to work with the current metamodel release, to continue storing and retrieving models.
6. Related Work
Coupled evolution of DSLs varies according to the technical space. In this section, we take a comprehensive look at the existing approaches for coupled evolution within the dataware, grammarware, XML-ware, and modelware technical spaces.
6.1. Dataware Approaches
In the dataware technical space, approaches differ in accordance with the type of persistence schema underlying the database. We will look at the main approaches of co-evolution of schemas and data tuples, applied for relational and object-oriented databases.
In relational dataware, there are generally two groups of migration specification approaches: manual and operator-based. In manual migration specification approaches, the user of the database management system constructs the migration by implementing a stepwise procedure. Such approaches are applied and documented in20'21'22. The process initiates with the creation of the target schema definition. The old data are then copied to the target mapped schemas, whereby, using database triggers, it is ensured that the data are synchronised. When the migration is verified for validity and completeness, the source schema is purged and the new transactions can be executed. In operator-based
approaches, schema evolution and data migration is done through use of pre-defined operator definitions23'24. The coupled operators, referred to in this class of approaches, contain all necessary information for performing the entire process at once. In23 the provided operators are formally proven to be semantics-preserving.
In object-oriented dataware, schemas and data are described using the object-oriented formalisms: definitions of attributes, inheritance, and inter-class associations. These concepts are then projected into an object-oriented database. Although object-oriented dataware is not used as much as relational dataware, in literature there is a large number of different approaches to migration of data.
Similar to relational dataware, in object-oriented dataware there is a class of operator-based migration approaches. Again, the migration steps are defined using a set of pre-defined operators that encapsulate both class hierarchy and concrete objects' modifications. In25 authors propose a fixed set of operators designed for the ORION database management system. The migration of object data is done within the same database and after all coupled operations are performed, data are restored to a consistent state.
Difference-based approaches in object-oriented dataware rely on detecting differences across the different schema versions. Such approaches are applied in26,27. In26 authors present a similar tool to Edapt that records changes to schemas and then uses the recorded information to form a migration of both schema and objects in the database. In27 authors propose an approach to detecting the differences between the different schema versions using a three-stage comparison algorithm. The approach works well when the schemas implement strong naming conventions or retain structural integrity across evolution steps.
Versioning approaches postulate the co-existence (within the same database) of different versions of either individual classes (28'29) or the entire object-oriented database schema (30'31). In28 authors divide the object-oriented database into class sets where only versions of the particular classes are kept and accessed through a common interface. In29 the migrations are defined by each user and work in both forward and backward direction. Thus, migrations of a particular class and its objects can be done on-line from any version to any other. In30 the authors propose an extension of the model proposed in25 for the ORION database management system. By including necessary invariants and operators, the authors are able to perform entire schema migrations. Finally, in31 the authors propose an approach in which the schema version mappings are specified manually. The approach covers more use cases than the one proposed by30, which is based on a limited number of pre-defined operators, but involves manual intervention. It allows for complex operations to be performed such as automatic updates of references to dependent attributes across model versions upon migration.
With view-based approaches, the data are not physically transformed. Instead, the target class hierarchy and object graphs are formed through view definitions over the source schemas. The view definitions are described using a view definition language in a declarative way. Such a language is COOL32, which has been designed for the COCOON object model. The approach in EVER (Evolutionary ER diagrams)33 builds upon the existing graphical notation of entity-relationship diagrams. With EVER, the version mappings are created manually by defining each of the version schemas. These definitions are then used to perform the transitions across versions. This approach also supports adding new attributes to previous versions of classes within the defined schemas.
6.2. Grammarware Approaches
The primary artefacts in the grammarware technical space are grammars. Grammars define the syntax of a language (DSL or a programming language) by describing the rules to define a valid sentence or program within it. History matching approaches take advantage of a recorded history over a grammar. An example of this class of approaches is implemented in the TransformGen framework34. The history is recorded over the process of changing the grammar definition. On the grammar level, the evolution is done by modifying the structure of the grammar definition. The needed changes at the sentence or program level are derived based on the history definition, whereas, whenever the matching cannot be done automatically, user-defined migrations are used.
Operator-based evolution approaches, similarly to relational and object-oriented dataware, are also useful within the grammarware technical space. Such an approach has been applied in the Lever framework35. Evolution is specified based on a set of predefined operations that are applied to both the syntax definition and the corresponding sentences or programs. As it has been designed for programming languages, Lever can also be used to migrate their compilers.
In XML-ware, DSLs are defined using schemas (XML Schema or DTD), which describe the format of valid XML documents conforming to them. The technical space is characterised by a wide cross-platform support of programmatic serialisation/deserialisation of model elements. With manual approaches for evolving schemas in XML-ware, users are required to manually specify the evolution of the schema and associated documents. In36, the authors propose an extension of XML Schema through which the migration declarations can be defined. The changes to both schemas and documents are derived from those definitions and then applied to the actual artefacts.
Operator-based approaches are also used in the XML-ware technical space. Such approaches have been proposed in the X-Evolution37 and XEM38 tools. Both frameworks rely on a predefined set of primitive change definition operators that can be used to perform migrations. The X-Evolution tool additionally allows for custom migrations to be specified by users, in cases when migration cannot be automatically covered by the default implementations.
In modelware, DSLs are defined using metamodels, which describe the format of valid models conforming to them. There exist several object-oriented meta-languages that are used to define the DSLs in this technical space, including Ecore, MOF, and MetaGME. Manual approaches in the modelware technical space share the same principle as in the other technical spaces we discussed previously. The migrations are specified in a particular transformation language and then used to perform the actual evolution on the DSL metamodels and models. An example of such an approach is given by39. Based on automatically-identified differences between source and target metamodel versions, users are required to describe the model migration behaviour, which is then used for model migration. Another approach in this context is presented in40 with the Flock migration language. The approach has been developed for migration of Ecore metamodels and models, and relies on a similar algorithm to the one applied in39. The difference is that the migration of models is done iteratively, with user input for model elements that have different specification in the
Metamodel difference-based approaches use automatic difference detection between metamodel versions. Those differences are then used to derive a migration plan, which is either generated, or based on user input. Such approaches have been proposed in41,42'43 for Ecore-based metamodels. The approach in41 only provides support for detection of simple changes that break compatibility across metamodels but that can be resolved and are not dependent on other changes. Examples of such are renaming, deletion, addition, moving, and association changes. In42, the authors provide support for more complex changes by also considering interdependent metamodel changes. Finally, in43, the authors define the Atlas Matching Language (AML), through which users can define pattern-matching algorithms to be used in the process of change detection. The migration is then automatically generated for the underlying models.
Operator-based approaches in modelware have been developed both for MOF44 and Ecore45. In44 authors define a set of operators that are then used to perform transformations of metamodels and models by using QVT relations. In45, the authors describe COPE: a tool-supported approach for the specification of metamodel and model evolution. The approach was initially based on Groovy scripts, but has been since ported to work with Java in Edapt.
The solution described in this paper incorporates the advantages of several of the discussed approaches. First and foremost, it can be attributed to the group of operator-based approaches since it relies heavily on the operations provided by the Edapt framework. Furthermore, it operates in a similar way to manual relational dataware approaches, whereby the data model (schema) is migrated in a step-wise manner. First, by creating the target schema; then, by performing the migration from the source data to the target schema; and finally, by disposing of the source data that are not needed for the operation of the system. This way, if a migration is to fail, it would not affect the data integrity and the system would be able to continue operating. Finally, in a similar manner to the object-oriented ver-sioning approaches, with the Historical Repository Node, the described solution allows to keep model data for individual
In this paper, we presented a case study in the cloud computing domain of integration of DSLs and migration of models based on the use of an appropriate mixture of technology, along with adaptations and extensions to existing approaches. In particular, we discussed how we tackled the challenge of integrating the DSLs that comprise CAMEL by leveraging upon EMF and OCL. Moreover, we proposed a solution to the challenge of persisting and automatically
Our solution provides several advantages by combining and incorporating features and patterns from existing approaches, frameworks, and tools. First, the solution design does not imply significant effort to integrate within a given platform. This is due to the loose coupling between the system and the different types of clients, achieved through the programmatic APIs, and the pluggable database back-end supported by CDO. Furthermore, the process of recording changes to DSL metamodels is made completely transparent to the user, thanks to the Edapt integration with EMF. Migration steps are pre-defined and available out-of-the-box. Edapt supports operation implementations for all basic operations that can be executed in the modelling interface of EMF, and additionally provides a rich library of over 60+ composite ones. Finally, the solution guarantees a consistent state of the system through the appropriate use of transactions, data redundancy, fail over, and validation through mechanisms provided by EMF, OCL, and CDO.
In terms of limitations, first of all, the abstract syntaxes of languages need to be expressed as metamodels and specified in EMF. The approach is also not entirely automatic, as any custom migration steps, which are not supported by the Edapt operations library, need to be manually specified by the user and attached to the corresponding step in
In the future, we intend to conduct a empirical study on the differences between the automated and manual migration of CAMEL models from and old to the current version of CAMEL. The goal is to collect quantitative and qualitative measurements on the two alternatives, which will allow us to verify if there is any statistically significant
Acknowledgements. The research leading to these results has received funding from the European Commission's Seventh Framework Programme (FP7/2007-2013) under grant agreement number 317715 (PaaSage).
1. Mell, P., Grance, T.. The NIST Definition of Cloud Computing. Special Publication 800-145; National Institute of Standards and Technology;
2. Object Management Group, . Unified Modeling Language Specification; 2011. http: //www. omg. org/spec/UML/2.4.1/.
3. Rossini, A., the PaaSage consortium,. D2.1.3 - CAMEL Documentation (Final version). PaaSage project deliverable; 2015.
4. Ferry, N., Song, H., Rossini, A., Chauvel, F., Solberg, A.. CloudMF: Applying MDE to Tame the Complexity of Managing Multi-Cloud Applications. In: Bilof, R., editor. UCC 2014: 7th IEEE/ACM International Conference on Utility and Cloud Computing. IEEE Computer
5. Ferry, N., Chauvel, F., Rossini, A., Morin, B., Solberg, A.. Managing multi-cloud systems with CloudMF. In: Solberg, A., Babar, M.A., Dumas, M., Cuesta, C.E., editors. NordiCloud 2013: 2nd Nordic Symposium on Cloud Computing and Internet Technologies. ACM. ISBN
6. Ferry, N., Rossini, A., Chauvel, F., Morin, B., Solberg, A.. Towards model-driven provisioning, deployment, monitoring, and adaptation of multi-cloud systems. In: O'Conner, L., editor. CLOUD 2013: 6th IEEE International Conference on Cloud Computing. IEEE Computer
7. Rossini, A., de Lara, J., Guerra, E., Nikolov, N.. A Comparison of Two-Level and Multi-level Modelling for Cloud-Based Applications. In: Taentzer, G., Bordeleau, F., editors. ECMFA 2015: 11th European Conference on Modelling Foundations and Applications', vol. 9153 of Lecture Notes in Computer Science. Springer. ISBN 978-3-319-21150-3; 2015, p. 18-32. doi:10.1007/978-3-319-21151-0_2.
8. Quinton, C., Romero, D., Duchien, L.. Cardinality-based feature models with constraints: a pragmatic approach. In: Kishi, T., Jarzabek, S., Gnesi, S„ editors. SPLC 2013: 17th International Software Product Line Conference. ACM. ISBN 978-1-4503-1968-3; 2013, p. 162-166.
9. Quinton, C., Haderer, N., Rouvoy, R., Duchien, L.. Towards multi-cloud configurations using feature models and ontologies. In: MultiCloud 2013: International Workshop on Multi-cloud Applications and Federated Clouds. ACM. ISBN 978-1-4503-2050-4; 2013, p.
10. Jeffery, K., Houssos, N., Jorg, B., Asserson, A.. Research information management: the CERIF approach. IJMSO 2014;9(1):5—14.
11. Kritikos, K., Domaschka, J., Rossini, A.. SRL: A Scalability Rule Language for Multi-Cloud Environments. In: Guerrero, J.E., editor. CloudCom 2014: 6th IEEE International Conference on Cloud Computing Technology and Science. IEEE Computer Society. ISBN 978-1-
12. Domaschka, J., Kritikos, K., Rossini, A.. Towards a Generic Language for Scalability Rules. In: Ortiz, G., Tran, C., editors. Advances in Service-Oriented and Cloud Computing - Workshops ofESOCC 2014; vol. 508 of Communications in Computer and Information Science. Springer. ISBN 978-3-319-14885-4; 2015, p. 206-220. doi:10.1007/978-3-319-14886-1_19.
13. Object Management Group,. Object Constraint Language Specification; 2014. http: //www. omg. org/spec/OCL/2.4/.
14. Object Management Group,. XML Metadata Interchange Specification; 2014. http: //www. omg. org/spec/XMI/2.4.2/.
15. Kritikos, K., Korozi, M., Kryza, B., Kirkham, T., Leonidis, A., Magoutis, K., et al. D4.1.1 - Prototype Metadata Database and Social Network. PaaSage project deliverable; 2014.
16. Papaioannou, A., Magoutis, K.. An Architecture for Evaluating Distributed Application Deployments in Multi-Clouds. In: CloudCom 2013: 5th IEEE International Conference on Cloud Computing Technology and Science. 2013, doi: 10.1109/CloudCom. 2013.79.
17. Object Management Group,. Meta-Object Facility Specification-, 2014. http: //www. omg. org/spec/MOF/2.4.2/.
18. Object Management Group,. Query/View/Transformation Specification; 2011. http: //www. omg. org/spec/QVT/1.1/.
19. Rossini, A., Rutle, A., Lamo, Y., Wolter, U.. A formalisation of the copy-modify-merge approach to version control in MDE. Journal of Logic and Algebraic Programming 2010;79(7):636-658. doi:10.1016/j . j lap. 2009.10.003.
20. Sockut, G.H., Iyer, B.R.. Online reorganization of databases. ACM Computing Surveys (CSUR) 2009;41(3):14. doi:10.1145/1541880. 1541881.
21. L0land, J., Hvasshovd, S.O.. Online, non-blocking relational schema changes. In: Advances in Database Technology-EDBT2006. Springer; 2006, p. 405-422. doi:10.1007/11827252_10.
22. Ronström, M.. On-line schema update for a telecom database. In: ICDE. 2000, p. 329-338. doi: 10.1109/ICDE. 2000.839432.
23. Shneiderman, B., Thomas, G.. An architecture for automatic relational database sytem conversion. ACM Transactions on Database Systems (TODS) 1982;7(2):235-257. doi: 10.1145/319702.319724.
24. Curino, C.A., Moon, H.J., Zaniolo, C.. Graceful database schema evolution: the prism workbench. Proceedings of the VLDB Endowment 2008;l(l):761-772. doi:10.14778/1453856.1453939.
25. Banerjee, J., Kim, W., Kim, HJ., Korth, H.F.. Semantics and implementation of schema evolution in object-oriented databases', vol. 16. ACM; 1987. doi: 10.1145/38713.38748.
26. Lerner, B.S., Habermann, A.N.. Beyond schema evolution to database reorganization. In: ACM SIGPLANNotices; vol. 25. ACM; 1990, p. 67-76. doi: 10.1145/97945.97956.
27. Lerner, B.S.. A model for compound type changes encountered in schema evolution. ACM Transactions on Database Systems (TODS) 2000; 25(1):83-127. doi:10.1145/352958.352983.
28. Skarra, A.H., Zdonik, S.B.. The management of changing types in an object-oriented database. In: ACM SIGPLANNotices; vol. 21. ACM; 1986, p. 483-495. doi: 10.1145/28697.28747.
29. Monk, S., Sommerville, I.. Schema evolution in oodbs using class versioning. ACM SIGMOD Record 1993;22(3): 16-22. doi: 10.1145/ 163090.163094.
30. Kim, W., Chou, H.T.. Versions of schema for object-oriented databases. In: VLDB; vol. 88. 1988, p. 148-159. URL: http://www. vldb. org/conf/1988/P148.PDF.
31. Clamen, S.M.. Schema evolution and integration. In: Distributed and Parallel Database Object Management. Springer; 1994, p. 101-126. doi: 10.1007/BF01263340.
32. Tresch, M., Scholl, M.H.. Schema transformation without database reorganization. ACM SIGMOD Record 1993;22(l):21-27. doi:10. 1145/156883.156886.
33. Liu, C.T., Chrysanthis, P.K., Chang, S.K.. Database schema evolution through the specification and maintenance of changes on entities and relationships. In: Entity-Relationship Approach—ER'94 Business Modelling and Re-Engineering. Springer; 1994, p. 132-151. doi:10. 1007/3-540-58786-1_77.
34. Garlan, D., Krueger, C.W., Lerner, B.S.. Transformgen: automating the maintenance of structure-oriented environments. ACM Transactions on Programming Languages and Systems (TOPLAS) 1994;16(3):727-774. doi:10.1145/177492.177697.
35. Pizka, M., Jürgens, E., et al. Tool-supported multi-level language evolution. In: Software and Services Variability Management Workshop; vol. 3. 2007, p. 48-67. URL: http://www4.in.tum.de/publ/papers/2007_pizka_juergens_svm.pdf.
36. Tan, M., Goh, A.. Keeping pace with evolving xml-based specifications. In: Current Trends in Database Technology-EDBT2004 Workshops. Springer; 2005, p. 280-288. doi: 10.1007/978-3-540-30192-9.27.
37. Guerrini, G., Mesiti, M., Sorrenti, M.A.. Xml schema evolution: Incremental validation and efficient document adaptation. In: Database andXMLTechnologies. Springer; 2007, p. 92-106. doi:10.1007/978-3-540-75288-2_8.
38. Su, H., Kramer, D., Chen, L., Claypool, K., Rundensteiner, E.A.. Xem: Managing the evolution of xml documents. In: Research Issues in Data Engineering, 2001. Proceedings. Eleventh International Workshop on. IEEE; 2001, p. 103-110. doi:10.1109/RIDE. 2001.916497.
39. Sprinkle, J.M.. Metamodel driven model migration. Ph.D. thesis; Citeseer; 2003.
40. Rose, L.M., Kolovos, D.S., Paige, R.E, Polack, F. A.. Model migration with epsilon flock. In \ Theory and Practice of Model Transformations. Springer; 2010, p. 184-198. doi:10.1007/978-3-642-13688-7_13.
41. Gruschko, B., Kolovos, D., Paige, R.. Towards synchronizing models with evolving metamodels. In: International Workshop on Model-Driven Software Evolution. 2007,.
42. Cicchetti, A.,DiRuscio, D.,Eramo, R., Pierantonio, A.. Automating co-evolution in model-driven engineering. In: Enterprise Distributed Object Computing Conference, 2008. EDOC'08. 12th International IEEE. IEEE; 2008, p. 222-231. doi: 10.1109/ED0C. 2008.44.
43. Garces, K, Jouault, F., Cointe, P., Bezivin, J.. Managing model adaptation by precise detection of metamodel changes. In: Model Driven Architecture-Foundations and Applications. Springer; 2009, p. 34-49. doi:10.1007/978-3-642-02674-4_4.
44. Wachsmuth, G.. Metamodel adaptation and model co-adaptation. In: ECOOP 2007-0bject-0riented Programming. Springer; 2007, p. 600-624. doi: 10.1007/978-3-540-73589-2_28.
45. Herrmannsdoerfer, M., Benz, S., Juergens, E.. Cope-automating coupled evolution of metamodels and models. In: ECOOP 2009-0bject-OrientedProgramming. Springer; 2009, p. 52-76. doi: 10.1007/978-3-642-03013-0_4.
