deliverable d5.3 (prototype) service composition with ... · • data, with a framework to...

Copyright REMICS Consortium 2010-2013

REuse and Migration of legacy applications to Interoperable Cloud Services REMICS

Small or Medium-scale Focused Research Project (STREP)

Project No. 257793

Deliverable D5.3 (Prototype)

Service composition with mediation services Work Package 5 Leading partner: SINTEF

Author(s): Brice MORIN (editor), Franck CHAUVEL

Dissemination level: Public

Delivery Date: 10-09-2013

Final Version: 1.0

Public

Copyright REMICS Consortium 2010-2013 / 13

Versioning and contribution history

Version Description Contributors

0.1 Initial draft (25 June 2013) SINTEF

0.2 Consolidated version (5 July 2013) SINTEF

0.3 Version of internal review (10 August 2013) SINTEF

0.4 Update version after first review (26 August 2013) Netfective, SINTEF

0.5 Update version after second review (04 Sept 2013) IICT-BAS, SINTEF

1.0 Final version after approval by technical manager (10 Sept 2013)

SOFT, SINTEF

Public


Executive Summary The deliverable D5.3 is defined in the DoW as a prototype, which extends D5.2. This document

therefore complements the software delivered by WP 5, and which has been released as a set of open-source projects on GitHub. D5.3 is a technical "getting started" document to guide users in using these tools, which provide advanced Model-based techniques to support the interoperability of cloud services, at three level:

• Data, with a framework to prototype and evaluate mediation algorithms

• Behaviour, with a domain-specific modelling language to express and generate mediators

• Deployment, with a domain-specific modelling language to enable the deployment of cloud services on multiple clouds

Note that deliverable D5.4 (report) gives more insight on REMICS work in the field of Model-Driven Interoperability, providing more details on the rationale behind these tools, their architectures, and offers some lessons learned on Model-Driven Interoperability based on these tools.

Public


Table of contents

EXECUTIVE SUMMARY ......................................................................................................................... 3

1 INTRODUCTION ................................................................................................................................... 5

2 FRAMEWORK FOR PROTOTYPING DATA MEDIATION .......................................................... 6 2.1 COMPILING THE MEDIATION FRAMEWORK ................................................................................... 7

2.2 RUNNING THE MEDIATION FRAMEWORK ...................................................................................... 8

3 BEHAVIOURAL SERVICE MEDIATION ......................................................................................... 9

4 MODEL-DRIVEN INTEROPERABILITY ACROSS MULTI CLOUDS ...................................... 11

5 CONCLUSION ...................................................................................................................................... 13

Public


1 Introduction This deliverable is a technical "getting started" document to guide users in using the tools

developed in WP5, which provide advanced Model-based techniques to support the interoperability of cloud services, at three level:

• Data, with a REST-based framework to prototype and evaluate mediation algorithms

• Behaviour, with a state machine-based domain-specific modelling language to express and generate mediators able to align the behaviour of different APIs

• Deployment, with a domain-specific modelling language to enable the deployment of cloud services on multiple clouds and enable the migrated service to operate on any cloud providers, thus avoiding the vendor lock-in.

As illustrated in Figure 1-1, maintenance and evolution is a continuous process, which is initiated after the migration steps (WP4), once the system has been recovered into UML models (WP3). When the legacy system has been migrated to a service-oriented architecture deployed over a cloud infrastructure, it is important to ensure that the system remains open and flexible enough in order to facilitate future evolutions and maintenance and minimize the risk of premature obsolescence. Maintaining the system mostly consists in replacing some services by another (semantically equivalent, but syntactically different) having better properties, such as lower cost, better reliability or better response time, possibly on a different cloud provider. This inevitably causes interoperability issues.

Figure 1-1 - Integration with the REMICS tool-suite

Public


2 Framework for Prototyping Data Mediation This section illustrates how to use the main features of the REMICS mediation framework. For testing purpose, a sample instance of the mediation framework is available in "the cloud", at the address http://54.247.114.191/net.modelbased.mediation.gui-0.0.1-SNAPSHOT/. More details on the architecture of the tool itself are provided in D5.4.

The first step is to properly configure the mediation portal. In the Settings tab, please make sure you are using the SINTEF-DEMO backend (see Figure 2-1 below), which contains some pre-existing models and mappings.

Figure 2-1 Configuring the settings of the mediation portal

Then it is possible to use the mediation portal with pre-loaded models and mappings, including models coming from the DOME use case. Figure 2-2 below illustrates the result of the mapping of the DOME schema with the Open Travel Alliance (OTA) schema, based on a default mapping algorithm.

Public


Figure 2-2 Visualisation of a specific mapping

Other features can be accessed via the other tabs, for example a tool to graphically compare the results of different mediation algorithms.

The data mediation portal is available as a set of open-source projects on GitHub1, under the L-GPL licence. It represents as a whole about 130 kLoC of JavaScript (front-end) and Scala (back-end), developed as part of REMICS, in collaboration with ENVISION and EMPOWER projects. These projects are all Maven projects supported by a continuous integration and tests process by Jenkins2.

It is also possible to run the mediation portal locally, by following the instruction given in the two sub-sections below.

2.1 Compiling the mediation framework To compile the mediation framework, you need two third-party software pieces: a Git client to access the source code repository and Maven to automate the build process.

1. You first need to retrieve the source code from the Git repository. The command below will connect to the git repository, retrieve all needed content, and place it in a folder entitled "mediation-portal".

$ git clone https://github.com/SINTEF-9012/mediation-portal.git

2. Moving to the mediation portal, you must go to the "net.modelbased.mediation" directory and call Maven to build and deploy all the mediation modules.

$ cd mediation-portal/net.modelbased.mediation

$ mvn clean install

1 https://github.com/SINTEF-9012/mediation-portal 2 http://build.thingml.org/job/Build%20Mediation%20Portal/

https://github.com/SINTEF-9012/mediation-portal

http://build.thingml.org/job/Build%20Mediation%20Portal/

Public


2.2 Running the mediation framework The mediation portal has two main dependencies towards third-party software:

• It requires MongoDB to be installed on the target system.

• It requires a servlet container, compliant with the Servlet 3.0 standard such as Jetty.

MongoDB is a scalable "no-SQL" database developed in C++, with native support for JSON format. It is used as the storage layer for models, mappings, and comparisons, and it is therefore a mandatory component. MongoDB can be retrieved and installed from http://mongodb.org. Please refer to the MongoDB documentation3 for the detailed installation procedure.

Jetty4 is a lightweight HTTP server and servlet container, which we advocate to run the mediation framework. Please refer to the Jetty documentation for a detailed installation procedure.

Once you installed Jetty, you just need to retrieve the mediation portal module WAR file, located in the "net.modelbased.mediation.portal" sub-directory and drop it into the "webapp" directory of your Jetty installation. Similarly, the GUI can be installed by dropping in this webapp directory the WAR file contained into "net.modelbased.mediation.gui" sub-directory. Restarting the jetty server will activate both the GUI and the back-end.

$ cp mediation-portal/net.modelbased.mediation.portal/target/net.modelbased.mediation.portal-0.0.1-SNAPSHOT.war jetty/webapps

$ cp mediation-portal/net.modelbased.mediation.gui/target/net.modelbased.mediation.gui -0.0.1-SNAPSHOT.war jetty/webapps

$ service jetty restart

3 Available at http://www.mongodb.org/display/DOCS/Home 4 Available at http://jetty.codehaus.org/jetty/

Public


3 Behavioural Service Mediation The Domain-Specific Language (DSL) for expressing behavioural mediation only requires Java to be installed. The editor is available both as a Java standalone version and as a set of plugins for Eclipse 3.8 and 4.2.

A lightweight version of this toolset is available as a Java Web Start package5. All you need is to have Java installed on you computer.

The editor is also available as an Eclipse plugin. The latest version of the ThingML plugins are available from and update site located at:

http://dist.thingml.org/update

To install, you will have toadd the update site to a fresh installation of Eclipse. The ThingML plugins require the EMF and EMFText plugins to be installed. The EMF plugins should be automatically resolved and installed by the Eclipse installer but you might have to add the EMFText update site for the EMFText dependencies to be installed. It is located at:

http://www.emftext.org/update

The ThingML plugins are built and tested for Eclipse 3.8 and 4.2 (Juno).

The Eclipse editor illustrated below in Figure 3-1 provides all the classical features present in most IDE, code completion, syntax highlighting, navigation into the code/model, an outline, etc. The language basically offers components and state machines to implement mediators that are able to synchronize messages between two, or more other components or services.

Figure 3-1 Behavioral mediation DSL in Eclipse

5 http://dist.thingml.org/LaunchThingMLEditor.jnlp

http://dist.thingml.org/update

http://www.emftext.org/update

http://dist.thingml.org/LaunchThingMLEditor.jnlp

Public


The language also comes with a first class action language, so that designers can model the behaviour of services at a detailed level, with no need for them to hide uncompiled Java code (or code expressed in another language) inside their model, which thus remains 100 % independent of any specific platform. Still, in order to easily integrate with code-level artefact, which is typically where interoperability should finally be addressed in practice, the DSL provides support to wrap existing code into model elements, which can then be seen a standard model elements. This feature is typically used to wrap the API or the services to be mediated.

The DSL for service mediation at the behavioural level is implemented on top of the ThingML language. More precisely, compilers targeting the Java Virtual Machine have been implemented by REMICS, as Java (and other JVM-based languages) is the defacto standard languages used in the Cloud, and used in the REMICS case studies. In particular, this DSL now compiles to the REMICS WP6 models@runtime engine based on a model to text transformation. REMICS also has implemented facilities to simulate mediators using graphical interfaces.

The different compilers are available from the standalone editor, as illustrated in Figure 3-2 below.

Figure 3-2 Compilation of a mediator to the WP6 models@runtime engine

The compilers developed by REMICS generate a project that can then be compiled and executed with Maven. Extract (non-business sensitive) of the DOME have been made available public and are available on GitHub, together with instructions6.

6 https://github.com/SINTEF-9012/mediation-portal/tree/master/samples/behavior

https://github.com/SINTEF-9012/mediation-portal/tree/master/samples/behavior

Public


4 Model-Driven Interoperability across Multi Clouds The CloudML tool supports (i) the specification of the deployment and provisioning of cloud-based systems with a domain-specific modelling language (DSML) and (ii) an engine for enacting the provisioning, deployment and adaptation of these systems on different cloud providers. CloudML is used for the initial deployment of the migrated application to the Cloud, and could also be used for the runtime management of the application, including the deployment of mediators in order to interoperate with third-party services. CloudML abstracts cloud provider-specific details and facilitates the interoperability of services deployed on different providers e.g., Amazon and Flexiant.

The model-driven approach adopted in CloudML allows developers to model the provisioning and deployment of the system at various levels of abstractions. The two proposed levels are: (i) the Cloud Provider-Independent Model (CPIM) to the topology together with requirements and constraints related to the provisioning and deployment of an application in a cloud agnostic way, and (ii) the Cloud Provider-Specific Model (CPSM) to describe the cloud concerns needed to enact the provisioning and deployment of the application on a specific cloud. This two-level approach is agnostic to any development paradigm and technology, meaning that the developers can design and implement the applications based on their preferred paradigms and technologies.

Figure 4-1 below illustrates the CPSM of the DOME case study, instantiated from a CPIM model (the types located on the left hand side of the figure). This system is going to be deployed on three virtual machines.

Figure 4-1 CloudML graphical editor

CloudML models can be serialized in different formats (JSON, XMI, etc.). These serialized forms

are the input to the deployment and adaptation engine, as illustrated in Figure 4-2 below.

Public


Figure 4-2 CloudML architecture

The deployment engine is then responsible for the provisioning and deployment of the cloud-

based system based on the in-memory model (models@runtime). It is also responsible for enriching the CPIM with provider specific data (e.g., type of virtual machine provisioned, name of the image loaded) and runtime data (e.g., public address, domain name). Currently, this engine is built on top of the jclouds7 library, which supports more than 20 providers.

CloudML is available as an open-source project available on GitHub8 initiated in REMICS as a WP4-WP5 collaboration, and developed in collaboration with other projects such as MODAClouds and PaaSage. It is written in JVM based languages with Maven as a build tool. The current implementation represents around 5 000 lines of Java code and 1 000 lines of Scala code. Figure 4-2 presents the main architectural elements of CloudML. More details on CloudML can be found in D4.4.

7 http://jclouds.incubator.apache.org/ 8 https://github.com/SINTEF-9012/cloudml

http://jclouds.incubator.apache.org/

https://github.com/SINTEF-9012/cloudml

Public


5 Conclusion This deliverable D5.3 complements the software delivered by WP 5, and which as been released

as a set of open-source projects on GitHub. This document only gave a rapid "getting started" guide to start using the tools. More fundamental details are available in the deliverable D5.4 (report), and more extensive documentation on how to use these tools are available on the respective websites of the tools and on their GitHub repositories.

deliverable d5.3 (prototype) service composition with ... · • data, with a framework to...

Documents