Hans Christian Andersen

Bruno Defude

Je Remercie Aussi

Daniela Grigori

Olivier Perrin

Mohamed Sellami

Sami Yangui

Mohamed Mohamed

Samir Tata

Paas

Samir Moalla

Scalable

" La reconnaissance est la

Keywords: Application à base de service -Approvisionnement de ressource Cloud -Cloud Computing, Micro-conteneur de services -Modélisation de ressource Cloud Cloud Computing -Cloud resource modeling -Cloud resource provisioning -Service-based application -Service micro-container ix, evolution

les membres du jury. Un très grand merci à

Context

Cloud Computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of congurable computing resources (e.g. networks, servers, storage resources, applications, services, etc.). These resources should be swiftly provisioned and released with minimal management eort and service providers interactions [START_REF] Mell | The NIST Denition of Cloud Computing[END_REF].

In this work, we are interested in service-based applications provisioning in Cloud environments. These applications are built according Service Oriented Architecture (SOA) which is a software architecture and applications design principle that starts with an interface denition and builds the entire application topology as a topology of interfaces, interface implementations and interface calls [START_REF] Hirsch | Introduction to Service-Oriented Architectures[END_REF].

Service-based applications consist in assembling a set of elementary services using appropriate service composition specications such as Service Component Architecture (SCA) [START_REF] Beisieg | SCA-Service Component Architecture[END_REF], Business Process Model and Notation (BPMN) [START_REF]Business Process Model and Notation (BPMN)[END_REF] or Web Services Business Process Execution Language (BPEL) [START_REF]OASIS Web Services Business Process Execution Language (WSBPEL)[END_REF]. Service-based applications are built from components and services that maybe heterogeneous in the sense that they (1) are not all implemented using the same programming languages (e.g. C++, Java, etc.), (2) do not support all the same communication protocols (e.g. RMI, SOAP/HTTP, etc.) and/or (3) do not run on the same hosting frameworks (e.g. POJO VM, .NET framework, etc.).

Provisioning a service-based application in the Cloud consists of: (1) allocation of adequate resources to host and execute the application and (2) upload of the application artifacts (e.g. binary code) on the allocated resources. This provisioning requires then the delivery of appropriate frameworks and specic runtimes supporting the heterogeneities presented above. However, existing Cloud platforms are limited to reasons such as the huge variety of manipulated resources and applications and the absence of universal standards for both applications and Cloud resources. For example, to deploy a Java Web application in Cloud Foundry, the developer have only to provide the application byte code. The allocation of the hosting tomcat server is performed implicitly by the PaaS based on the application type. While, deploying the same application in Jelastic requires: (1) the creation (manually) of the hosting environment containing a tomcat instance by the developer, (2) the upload of the application and (3) the linking of the application to the created environment for the concrete deployment.

Thesis research issues and motivations

On one side, SOA developers manipulate various and heterogeneous application components which: (1) do not use necessarily the same programming languages, (2) do not support all the same communication protocols and/or (3) do not run on the same hosting frameworks. On the other side, taxonomy of Cloud Computing shows that all the existing systems are limited to specic hosting environments, programming frameworks and runtimes. Each Cloud system provides a nite and limited set of hosting and execution resources (e.g. execution engines, message routers, etc.) and services (e.g. storage services, logging services, etc.). For example, deploying BPEL processes (respectively SCA-based applications) in the Cloud requires provisioning, among others, specic execution engines such as Apache ODE (respectively Apache Tuscany). These limitations impose constraints and makes the use of those systems dicult, since SOA developers need to use the related programming languages and execution frameworks before using the Cloud [START_REF] Bhaskar Rimal | A Taxonomy and Survey of Cloud Computing Systems[END_REF]. Capabilities of Cloud platforms are limited in terms of hosting and execution resources and cannot meet all the time the high heterogeneity of application components.

Some of the existing solutions (e.g. Cloud4SOA, mOSAIC, etc.) propose to provide dedicated frameworks for SOA applications, or to allow developers to install and congure themselves required execution frameworks when deploying the application components (e.g. [START_REF]Deploying Application Server in Cloud Foundry Using the Standalone Framework[END_REF] for Cloud Foundry PaaS), these solutions delegate installation and conguration tasks to developers which complicates signicantly the deployment, constitutes a step backward and is inconsistent with the Cloud business model. Other solutions (e.g. Cloud Foundry, WSO2 Stratos, etc.) compensate this adhesion to specic programming languages, communication protocols and/or hosting frameworks by continuous development of extensions requested by end users (for proprietary solutions) or proposed by developers (for open-source solutions). Nevertheless, this extension task is quite complex and expensive. It is a development task rather than an integration facility that consists of adding new components without hard coding.

In addition to these constraints, we noticed another type of restrictions when deploying service-based applications in the Cloud. Such applications are often distributed, so it is not uncommon to deploy their components separately on multiple Cloud platforms for example. However, application required resources are provisioned by Cloud platforms in a specic way. Each Cloud system has proprietary description models to describe, manage and provision applications and their hosting resources. This is also reected in the heterogeneity of the user APIs implementing these description models (e.g. proprietary operations, specic provisioning scenarios, etc.).

These limitations are forcing developers to adapt their applications and provisioning procedure when they provision them into several Cloud platforms and/or when they move from a Cloud platform to another. These limitations cause application portability issues which impedes operating such applications in Cloud context. Cloud applications portability is a concept that refers to the ability to move applications between Cloud vendors with a minimum level of integration issues. Cloud applications portability enables the re-use of application components across Cloud platforms and services [START_REF] Walraven | Comparing PaaS oerings in light of SaaS development[END_REF]. Application portability limitations lead to restriction problems, compatibility drawbacks and vendor lock-in that make operating service-based applications dicult in the Cloud due to the dierences on used resources description models and user APIs.

To address these issues, we dene, in this thesis, a novel approach to provision service-based applications in Cloud environments. To do this, we propose to design and implement appropriate mechanisms to support the high heterogeneity of the applications components and generic operations independent from the target Cloud environment for applications deployment.

Thesis objectives and principles

In this thesis, we aim at dening an approach to provision automatically service-based applications in Cloud environments. This approach aims at addressing highlighted SOA applications heterogeneity limitations and portability issues in the Cloud. Our approach covers applications described according SOA, and particularly business processes modeled through BPEL or BPMN processes and applications whose services compositions can be modeled as directed graphs such as SCA-based applications.

Our approach consists in dening and implementing new provisioning mechanisms that are exible enough to support the deployment of high heterogeneous service-based application components. These mechanisms must also allow application portability to enable automatic and unied provisioning and management procedures whatever is the target Cloud without any modications and/or adaptations on the Cloud environment side.

To support application components heterogeneity, we propose to slice the applications into a set of elementary and autonomous services before allocating a dedicated and appropriate environment for each one of the obtained services. Applications slicing in elementary services seeks to facilitate deployment task and heterogeneity constraints satisfaction when instantiating hosting Cloud environments. Indeed, it is dicult to meet Cloud provided resources with such varied application components hence our idea of slicing. After that, if the provisioning of required Cloud resources for hosting and execution of these services is not supported by the target Cloud environment, we propose to perform dedicated service containers wherein we package sliced services and required execution resources.

To enhance Cloud portability, we dene a unied application and resources description model and a generic API implementing this model. Based on our introduced model and its correspondent API, we are able to describe, provision and manage applications and allocated resources on the same way whatever is the target Cloud infrastructure or platform.

Finally, it should be noted that based on these principles, the execution of the deployed service-based applications are assimilated to services choreographies instead of the initial services orchestrations which is more appropriated for decentralized environments such as the Cloud.

Thesis Contributions

In order to achieve our stated objectives, we dene a novel approach that we called SPD to perform the provisioning procedure. The SPD approach requires no modication and/or adaptation on Cloud provider side and enable applications portability thanks to the generic resources description model that we dene for both application and Cloud resources.

The SPD approach consists of three steps:

1. Slicing the application into a set of elementary services, 2. Packaging the resulted services into service micro-containers, 3. Deploying the micro-containers in a target Cloud environment.

If the application to deploy is mono-block (e.g. Java Web application), we perform directly the third step of the approach. Else, if the application has several components, we perform the rst step of the approach to slice it before. Note that the second step is performed only when the target Cloud platform do not support provisioning required Cloud resources for hosting and execution of sliced services. The three SPD approach steps are detailed in the following.

Step 1: Slice the service-based application

The slicing step is based on the application deployables and descriptor. Application deployables are all necessary artifacts (e.g. ZIP le, EAR le, conguration scripts, etc.) needed to run the application while the application descriptor, often an XMLbased document, is a sort of contract describing how to invoke the application and giving details regarding its several components, bindings and interactions between them. The principle of this step is to cut and divide the service-based application into an equivalent set of autonomous and operational elementary services while ensuring the preservation of their initial business semantics. The execution of these resulting services ensures the same functionality of the initial application. 1.4.2 Step 2: Package the services to deploy

In this step, we package each one of the obtained services from the slicing step in a particular type of service container. Only one service and necessary resources to implement its binding types such as communication protocols and its required facilities such as migration, elasticity or monitoring are packaged in a dedicated container that we called service micro-container. The micro-containers are generated from the packaging framework based on the provided service.

Step 3: Deploy the packaged services

Once the services are packaged in micro-containers, we can deploy them in a target Cloud environment. Depending on the choice of the developer, the micro-containers can be deployed on Cloud infrastructure (IaaS) or Cloud platform (PaaS). For an IaaS deployment, service micro-containers are placed on virtual machines as standalone applications. For a PaaS deployment, we dened a PaaS-independent platform and application resources description model based on the Open Cloud Computing Interface (OCCI) to enable applications portability. We also performed a REST API called COAPS implementing this model and enabling unied and automatic provisioning through generic operations.

Thesis outline

This thesis includes 7 chapters:

In Chapter 2, we introduce a set of denitions and basic concepts before presenting the work related to our thesis. We study results of dierent collaborative research projects (e.g. Cloud4SOA, mOSAIC, etc.), tentatives of standardization (e.g.

TOSCA, CAMP, etc.) and existing solutions for service-based applications description and provisioning in the Cloud. This analysis allows us to highlight the existing limitations and justify the need of novel appropriate mechanisms for service-based applications provisioning in the Cloud.

Chapters 3, 4 and 5 are the core of our thesis, which elaborate our dened SPD approach to provision service-based applications in Cloud environments. Each one of these Chapters details a step of our SPD approach. Concrete illustrative examples are provided at the end of each Chapter.

In Chapter 3, we present our performed work to achieve the rst step of the SPD approach. In this Chapter, we dene and comment a set of formal algorithms that slices service-based applications based on their type (i.e. business processes or applications based on service compositions). The dened slicing algorithms allow the preservation of the applications business semantics.

In Chapter 4, we present the architecture of the packaging framework and its execution process to package sliced services in appropriate service micro-containers.

Extended variants of packaging framework supporting the packaging of non-functional properties such as migration or monitoring in the micro-containers are also described.

In Chapter 5, we present our proposed applications and platform resources description model. We also describe the COAPS API specications which implements this model. Our dened model allows applications and/or services deployment through seamless interactions with dierent and heterogeneous PaaS and address applications portabiliy issues.

In Chapter 6, we present implementations details and used technologies to realize each step of the SPD approach. We discuss also the experimentations results that we have conducted to evaluate our service micro-container performances against classical service containers in Cloud environments. This Chapter is organized as follows: We introduce a set of denitions and basic concepts related to our work in Section 2.1. Then, we present the criteria that we have selected to evaluate related works in Section 2.2. After that, we discuss results of collaborative research projects and existing approaches for applications provisioning in the Cloud in Section 2.3. Finally, we study and compare existing approaches for Cloud resources description in Section 2.4.

Background

In this Section, we introduce denitions and basic concepts related to our work.

Cloud Computing

The American National Institute of Standards and Technology (NIST) dened Cloud Computing as a new emerging model for enabling ubiquitous, convenient, on-demand network access to shared pool of congurable computing resources (e.g. networks, servers, storage resources, applications, services, etc.). These resources should be swiftly provisioned and released with minimal management eort [START_REF] Mell | The NIST Denition of Cloud Computing[END_REF].

Based on [START_REF] Foster | Cloud Computing and Grid Computing 360-Degree Compared[END_REF], Cloud Computing is dened as a specialized distributed computing paradigm. It diers from traditional ones on the fact that it (1) is massively scalable, (2) can be encapsulated as an abstract entity that delivers dierent levels of services to customers outside the Cloud, (3) is driven by economies of scale, (4) can be dynamically congured (via virtualization or other approaches) and ( 5) can be delivered on demand. The associated delivery models to Cloud Computing are: Infrastructure as-a-Service (IaaS), Platform as-a-Service (PaaS) and Software as-a-Service (SaaS).

IaaS provides services that furnish to the consumer processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. At IaaS level, the consumer does not manage or control the underlying Cloud infrastructure but has control over operating systems, storage, and deployed applications [START_REF] Mell | The NIST Denition of Cloud Computing[END_REF]. Examples of IaaS are Amazon AWS 1 , Rackspace Open Cloud 2 , Google Compute Engine 3 , etc.

PaaS provides services that furnish to the consumer appropriate resources to deploy in the Cloud infrastructure consumer-created or acquired applications implemented using programming languages, libraries, services and tools supported by the provider [START_REF] Mell | The NIST Denition of Cloud Computing[END_REF]. PaaS consists of a re-usable framework, which provides one or more application platform components as a service. Examples of PaaS are Cloud Foundry Listing 2.1: The online shop process descriptor.

Related work evaluation criteria

To address the SOA support issues mentioned in Section 1.2, Cloud platforms should provide appropriate mechanisms to support SOA application components heterogeneity. In addition to that, to enable automatic provisioning of these applications and enhance their portability in such context, we need to use a generic and common application and Cloud resources description model. Such generic model unies the application provisioning and management steps and enhance applications portability since it will be described and provisioned, as well as its resources, in the same way whatever is the target Cloud platform.

In the following, we enumerate and discuss results of related works which are interested in addressing these issues. To evaluate these works, we rely on the following criteria:

• SOA support: Appropriate provisioned Cloud resources to support applications described according to SOA hosting and execution,

• Applications portability: Provided solutions to minimize modications and adaptations of applications from a Cloud platform to another,

• Standardized resources description model: The proposal or not of common and unied resources description model,

• Standardized user API: The proposal or not of generic user API operations implementing the resources description model.

Approaches for applications provisioning in the Cloud

In the following, we present and discuss results of related research projects. For each one of these projects, we describe its contributions and performed solutions. Cloudlets. A Cloudlet represents an abstraction of application functionnality and is subject to be elastic and monitored by the Sotware Platform. The Semantic Engine is the sub-system supporting the user in selecting APIs components and functionalities needed to build the Cloudlet, and resources to be allocated from the Cloud providers.

The API operations are generic. This ensures a degree of abstraction of Software Platform Support when describing the application and its resources.

The Software Platform Support manages the hosting environment of the application to deploy based on deployment and application descriptors. The Software Platform Support identies the application components and the needed Cloud resources when parsing the application descriptor. Provided resources do not support appropriate frameworks and engines for applications described according to SOA execution.

However, the Software Platform Support is open source and could be extended by the community to support SOA in the near future.

The Infrastructure Support provides concrete Cloud resources and services to be provisioned. • Repository layer : provides records as RDF triples related to developer's proles and supported PaaS providers' capabilities.

The provisioning process is performed through a harmonized API that exposes generic application management operations. A specic adapters ensure the mapping between the harmonized API and the proprietary PaaS oering APIs. This architecture consists of 3 layers:

• Federation layer which implements a broker-based solution to manage and negotiate contracts with the providers based on Service Level Agreements (SLA) documents. This layer exposes a REST API to manage applications, data, users and providers,

• Provider layer which manages applications and services provisioning and execution according to the provided SLA (e.g. ConPaaS [START_REF] Pierre | ConPaaS: A Platform for Hosting Elastic Cloud Applications[END_REF]).

• Resource layer which aggregates resource characteristics and capabilities.

The Contrail project does not support deployment of applications described according to SOA. The applications deployment mechanism is based on the Open Virtualization Format (OVF). OVF is an open standard for packaging and distributing software to be deployed and run in virtual machines. This facilitates the import/export applications from one provider to another. However, this requires that the target provider supports OVF processing. The federation API exposes aggregated management operations common to providers. They enable managing applications and resources in the same way when even if there are delivered by dierent providers.

Other research projects

The Cloud-TM project 18 proposes a middleware platform which exposes a set of APIs and abstractions for the development, provisioning and administration of large scale applications across a dynamic set of distributed nodes allocated from IaaS Cloud providers [START_REF] Romano | Cloud-TM: Harnessing the Cloud with Distributed Transactional Memories[END_REF].

4CaaSt 19 proposes a solution ensuring the development, description and deployment of applications [START_REF] García-Gómez | Challenges for the comprehensive management of Cloud Services in a PaaS framework[END_REF]. The three processes are seperated. The user can develop and describe the application through 4CaaSt before delegating the hosting environment selection and the deployment to the platform. Application archives need to be adapted after the selection of the hosting platform.

The RESERVOIR 20 project provides an infrastructure that allows reliable services provisioning. Connected Cloud providers to RESERVOIR address end-users' requirements leasing computational resources from IaaS providers which interoperate with each other creating a seamlessly pool of resources and address interoperability issues based on an OCCI infrastructure implementation [START_REF] Rochwerger | The Reservoir model and architecture for open federated cloud computing[END_REF]. For example, for business processes, the authors in [START_REF] Anstett | Towards BPEL in the Cloud: Exploiting Dierent Delivery Models for the Execution of Business Processes[END_REF] draw up an inventory of the dierent delivery models available to execute a BPEL process at IaaS, PaaS and SaaS layers. The conclusion made by the authors stipulates that there is still several lacunas to support BPEL processes provisioning in the Cloud especially in terms of communication processing between the dierent activities of the process.

In [START_REF] Fan | Investigating the Feasibility of Making Contexts Explicit in Designing Cloud Workow[END_REF], the authors propose a context-oriented methodology supporting Cloud workows design. This approach interacts strongly with the user to allow him to make contexts explicit in designing Cloud workow models. The users could then customize information, formalize their design strategies, and possibly interact with the system in a collaborative pattern in order to perform Cloud workows operating.

Moreover, some works have proposed to transform and slice business processes to equivalent sub-processes in order to be able to deploy them (or a part of them) in the Cloud [START_REF] Anstett | Towards BPEL in the Cloud: Exploiting Dierent Delivery Models for the Execution of Business Processes[END_REF] [38] [START_REF] Wagner | Towards choreographybased process distribution in the cloud[END_REF].

Other approaches consists in dening algorithms to place and execute workows over allocated Cloud resources optimally [40] [41]. These approaches consider the data dependencies between workow steps and the utilization of resources at runtime to place the process components over these resources. Placement and resources allocation decisions are based on predened heuristics. Provided implementations are based on the ActiveBPEL engine for processes executing and Amazon's Elastic Compute Cloud for required resources allocation.

In addition to that, it should be noted that several PaaS providers begin to integrate features to design, deploy and execute business processes in the Cloud. For example, Amazon Web Service proposes the Amazon Simple Workow Service (Amazon SWF) which assists developers to coordinate the various processing steps in the process to deploy and allow them to manage distributed execution state [START_REF]Amazon Simple Workow Service[END_REF]. Salesforce introduced a tool called Visual Process Manager to support business process management on Salesforce platform [START_REF]Approvals and workow[END_REF]. WSO2, an Apache ODE-based process engine, provides a variant of its business process server as-a-Service [START_REF]WSO2 Business Process Server[END_REF].

Regarding applications based on services compositions, some works have focused on dening new PaaS prototypes dedicated to support such applications and provision their needed hosting frameworks. For example, in [START_REF] Paraiso | A Federated Multi-cloud PaaS Infrastructure[END_REF], a PaaS prototype relies on a congurable kernel which is inspired from FRASCATI 21 , an open source implementation of SCA specications, to support SCA runtime. There are also additional works based on FRASCATI and supports reconguration of SCA applications from the domain of Software Product Line (SPL) design provided by the developer [45] [46]. Furthermore, FRASCATI was integrated as standalone framework over several existing PaaS providers to support execution over these PaaS (e.g. FRASCATI in Google App Engine 22 , FRASCATI in Heroku 23 , etc.)

In [START_REF] Ruz | Flexible SOA Lifecycle on the Cloud Using SCA[END_REF], the authors introduced an approach to deploy SCA applications in Cloud environments. In this approach, the initial application provided by the developer is an SOA application described through a BPMN diagram. This latter is transformed to a basic equivalent SCA view using Mangrove core tool. After that, the developer has the ability to rene the application architecture (e.g. introducing additional components, dening external dependencies, etc.) and augment then the application components with virtual node (VN) names. VN concept is an abstraction for the deployment of distributed applications used by GCM/ProActive wich represents an implementation of the Grid Component Model (GCM) [START_REF] Baude | GCM: a grid extension to Fractal for autonomous distributed components[END_REF]. The VN abstraction is used to refer to the location where the GCM components will be deployed without actually specifying physical nodes, and delaying this association to the moment when the actual resources are available. From this augmented description, an equivalent GCM architecture description language descriptor is generated. This descriptor contains the GCM components, their bindings and the VNs where they will be deployed, thus oering a vision obtained directly from the architectural design, and at the same time closer to infrastructure concerns [START_REF] Ruz | Flexible SOA Lifecycle on the Cloud Using SCA[END_REF].

In addition to that, the Apache Foundation tried to develop a Cloud-aware version of Apache Tuscany to be able to be hosted and provisioned eciently by a PaaS provider [START_REF] Resende | Developing Composite Applications for the Cloud with Apache Tuscany[END_REF]. They also start a new project called Apache Nuvem which aims to dene a novel API for Cloud application services, to support SOA applications (SCAbased applications included) deployment across the most popular Cloud providers [START_REF]The Apache Nuvem incubator[END_REF].

Approaches for Cloud resources description

In the following, we discuss existing related work regarding platform and application resources description models. For deployment, TOSCA application elements are encapsulated in a predened archive format called Cloud Service ARchive (CSAR). CSAR is composed at least of two directories. The rst directory is the TOSCA meta le (.meta) which describes metadata of all other les in the CSAR. The second one is the denition directory which contains typically sources and denitions related to the application (.tosca). The use of CSAR meet with applications described according to SOA specications but the Service Template notion hampers the application portability. Indeed, this requires a set of modication and adaptation in the PaaS side. Each Cloud platform would map the specied Service Topology to its available concrete infrastructure in order to support concrete instances of the application and adapt the management plans accordingly. In addition to that, most of existing PaaS do not support currently CSAR deployment even if there is some platform prototypes supporting TOSCA specications (e.g. ServIce Oering and Provisioning Platform -SIOPP 24 [START_REF] Cardoso | Cloud Computing Automation: Integrating USDL and TOSCA[END_REF], OpenTOSCA [START_REF] Binz | OpenTOSCA A Runtime for TOSCA -based Cloud Applications[END_REF]). Figure 2.12: Typical PaaS architecture [7].

Cloud Application Management for Platforms (CAMP) is a specication and REST API standardized by OASIS [7]. CAMP provides basis for developing multicloud management tools as well as a REST-based approach to application management across public and private Cloud computing platforms. Provided management operations involve application description, packaging and deployment.

Before dening application operations management and PaaS API specications, CAMP performed a census for existing PaaS resources. This is useful besause these are the resources that will ensure and execute the operations exposed by CAMP API on the provider side. through the self service API operations by the application developers. The details of identied platform components are as follows:

• Runtime containers to provide runtime environment and execution frameworks to applications,

• Firewalls to secure applications invoking,

• Load Balancers and Message Queues to manage applications instances and received requests,

• Web Servers to host and execute Web applications,

• Databases to manage data persistence,

• Log aggregators for applications logging. OCCI is a set of specications that denes a meta-model for abstract Cloud resources and a RESTful protocol for their management. It oers a exible API with a strong focus on interoperability while still oering a high degree of extensibility.

To enhance modularity and extensibility, OCCI is released as a suite of complimentary documents such as:

1. OCCI core that denes a meta-model for Cloud resources description and management [START_REF] Nyren | Open Cloud Computing Interface -Core[END_REF],

2. OCCI rendering specications that contains multiple documents describing rendering of the OCCI core model [START_REF] Metsch | Open Cloud Computing Interface -RESTful HTTP Rendering[END_REF],

3. OCCI extensions which are instantiations of the OCCI core meta-model to model particular Cloud resources (e.g. infrastructure resources [START_REF] Metsch | Open Cloud Computing Interface -Infrastructure[END_REF]). The OCCI core model is suitable to be extended and serve many other resource description models such as infrastructure resources. The HTTP Rendering document denes how to serialize and interact with these types using RESTful communication. working mixin for TCP/IP capabilities). In addition to that, the extension provides a set of attributes to well describe the dened types and a set of operations to manage

Related academic work

In the literature, we found several works that tried to dene generic operations for Cloud provider resources management. These works attempt to benet from identied similarities between Cloud platform representations. In [START_REF] Loutas | Towards a Reference Architecture for Semantically Interoperable Clouds[END_REF], the authors discuss the need for a generic API that enables Cloud users to specify their requirements among provider oers. Their investigations shows that most of these APIs use similar concepts with similar properties and actions but with dierent names and structures.

The authors consider that the interoperability and portability problems arise due to dierent modeling and notation of the same features across dierent Cloud providers.

To handle this issue, the author considers semantic technologies as a solution for interoperability and portability in the Cloud.

In [START_REF] Satzger | Winds of Change: From Vendor Lock-In to the Meta Cloud[END_REF], the authors propose to use existing approaches to describe applications and their deployment procedure in the Cloud. They use resource templates (as for TOSCA and CloudFormation) representing recongurable entities that can be reused for different applications. Automated deployment of the resources associated to templates description, can be possible using deployment recipes (using DevOps technologies like Chef 25 or Puppet 26 )

In [4], the authors suggest that a common API should involve a set of core functionalities that will meet the basic needs of any Cloud Platform and will unify all dierent APIs (an API for all APIs). Accordingly, a common API is proposed with a common semantics for the needed PaaS resources and actions. This API communicates with PaaS providers via adapters, and any new provider has to adapt his oering following the same semantics (i.e. using the same models and structures or providing an adapter to transform its own representation to the common one). To deploy an application, developers should provide an application prole that describes the requirements of the application. A management module builds an application deployment descriptor according to the selected PaaS, and then, initiates the application deployment via a standard API (i.e. Cloud4SOA [START_REF] Francesco | Cloud4SOA: Multi-cloud Application Management Across PaaS Oerings[END_REF]) that uses the dedicated adapter for the selected PaaS oer. TOSCA and CAMP are promizing tentatives of standardization, but their introduced specic application archives format (i.e. PDP for CAMP, CSAR for TOSCA) penalizes the application portability. Indeed, to support these formats, we need to use specic implementations (e.g. OpenTOSCA) or perform changes on the Cloud platform side (e.g. CloudBees to support CAMP specications).

Synthesis

To allow portability between end users and existing Cloud platforms, we need to design a description model which would help to make abstraction of any provisioning system, of any Cloud service and/or resource. Such a model would enable a detailed description of complex workloads in order to provision them in an automated fashion on heterogeneous providers. To achieve this goal, we believe that we IaaS layer and has contribute to cooperate and federate data centers and infrastructure resources [START_REF] Celesti | How to Enhance Cloud Architectures to Enable Cross-Federation[END_REF] [32] [START_REF] Buyya | InterCloud: Utilityoriented Federation of Cloud Computing Environments for Scaling of Application Services[END_REF]. Furthermore, the resources introduced by OCCI extension should support applications described according to SOA hosting and execution.

Conclusion

In this Chapter, we highlighted Cloud platform limitations and drawbacks related to service-based applications provisioning. We presented a set of related collaborative research projects that attempt to address these issues. We also detailed a set of standardization tentatives of application and platform resources description that aims to unify provisioning and management operations. In the last Section of the Chapter, we draw a synthesis and we discuss results of cited works.

Introduction

Our dened SPD approach to provision a service-based application in Cloud environments consists of 3 steps: (1) Slicing the service-based application into a set of elementary and autonomous services, (2) Packaging these services in micro-containers and (3) Deploying the micro-containers in the target Cloud environment [START_REF] Yangui | The SPD approach to deploy service-based applications in the cloud[END_REF]. In this Chapter, we present and details the rst step of this SPD approach.

Since service-based applications have often highly heterogeneous components (See Section 1.1), it is dicult to satisfy its requirements by provisioning one allocated hosting environment based on existing Cloud environment capacities. Because of this, we propose to slice the applications into a set of elementary and autonomous services before allocating a dedicated and appropriate environment for each one of the obtained 33 services. Moreover, the slicing facilitates the deployment of the applications and allows us to susbstitue the initial application components orchestrations by services choreographies when executing the application.

For service-based applications, it is not possible to determine in advance the execution branch that it will follow at runtime. Indeed, branch execution choices depend on several unpredictable parameters criteria (e.g. variable and parameter values, human interactions in the middle of the process, handlers processing, etc.). All these aspects should then be taken into consideration in the slicing step. Furthermore, since these applications are various in terms of execution specications (e.g. services choreography for some, services orchestration for others, etc.) and correspondent descriptors does not use the same description languages (e.g. Service Component Description Language (SCDL), etc.), we perform appropriate slicing algorithms. Broadly speaking, this step aims at slicing applications described according to SOA based on formal representation of their services compositions. We handles in this step slicing of:

• Applications modeled as business processes,

• Applications modeled as compositions of service components.

To perform slicing, we chose to formally represent the service-based applications, and then process the slicing. This allows us to keep an eye on sliced services interaction and orchestration with other services and then facilitate the verication procedure of the semantics preservation. Specically, for applications modeled as business processes, we covers all specications that can be modelized on Petri nets such as BPEL or BPMN processes. For applications modeled as compositions of services, we cover all specications whose services compositions can be modelized as graph-based composition (directed graph) such SCA-based applications. This Chapter is organized as follows: We present our dened algorithms to slice business processes in Section 3.2. We present our dened algorithm to slice applications modeled as compositions of service components in Section 3.3. Proof of preservation of processes semantic and illustrative examples are provided for both cases.

Slicing of business processes

For business processes slicing, we opted for the use of Petri nets to formally describe the processes and then, proceed to the slicing step directly on the correspondent Petri net graphs. The use of Petri net representation as an intermediate step allows us to preserve semantics of sliced processes.

Preliminaries on Petri nets and WF-nets are rstly introduced in Section 3.2.1.

The slicing algorithms are presented in Section 3.2.2. Addressed algorithms enable business processes decomposition into a set of dependent WF-nets through an intermediate Petri net representation. A function to determine the dependencies between the obtained WF-nets is carried. Based on the results of this function and applying the theorem we have dened, we retrieve the same execution of the initial business process. The proof of the dened theorem is given in Section 3.2.3. The algorithms that we have dened are not costly when operating the business processes as they are executed only once before deploying the processes. To illustrate our ndings, we provide an example of a BPEL process slicing in Section 3.2.4.

Preliminaries: Petri nets, WF-nets

In this following, we present some preliminary notions on Petri nets. • P is a nite set of places (cercles) and T a nite set of transitions (squares) with (P ∪ T ) = ∅ and P ∩ T = ∅,

• A ow relation F ⊆ (P × T ) ∪ (T × P ),
• W : F → N + is a mapping that assigns a positive weight to any arc. The incidence matrix C associated with the net is dened as follows : ∀(p, t) ∈ P × T : C(p, t) = W (t, p) -W (p, t). A marking of a Petri net N is a function m : P → N. The initial marking of N is denoted by m 0 . The pair N, m 0 is called a Petri net system. A transition t is said to be enabled by a marking m (denoted by m t -→ ) i ∀p ∈

m in N is denoted by R(N, m). A run of marked petri net N, m 0 is a path π = m 0 t 1 -→ m 1 . . . tn -→ m n . S.
The set of markings reachable from a marking m in N is denoted by R(N, m). The set of markings reachable from a marking m, by ring transitions of a subset T only is denoted by Sat(m, T ). By extension, given a set of markings S and a set of transitions T , Sat(S, T ) = m∈S Sat(m, T ) . For a marking m, m → denotes that m is a dead marking, i.e., Enable({m}) = ∅.

Two Petri nets

N 1 = P 1 , T 1 , F 1 , W 1 and N 2 = P 2 , T 2 , F 2 , W
∪ P 2 , T = T 1 ∪ T 2 , F = F 1 ∪ F 2 and W : F 1 ∪ F 2 → N + is the mapping assigning the weight W i (f ) to any arc in F i , for i ∈ {1, 2}.
The decomposition of a given Petri net into two (ore more) subnets corresponds to the dual operation. Again, the two main decomposition approaches are based on the splitting of a Petri net into two (ore more) subnets that share a subset of places or/and a subset of transitions. The sharing of transitions represent a synchronisation (rendez-vous) between two components while the sharing of places (buers) represent an asynchronous communication between components.

WF-nets

We use a particular Petri net for modeling the control-ow dimension of a service-based processes. This is a variant of Work-Flow nets (WF-nets) that have been introduced

in [ • for any node x ∈ P ∪ T , for any source place i ∈ I and for any sink place o ∈ O, there exists a path from i to o which passes through x.

It should be noted that the sole dierence between the WF-nets introduced in [START_REF] Van Der Aalst | The Application of Petri nets to Workow Management[END_REF] and the above denition is the fact that, we allow a WF-net to have several source places and/or several sink places. This has no eect on the semantics of the obtained model but is more convenient for our decomposition approach. As a special kind of Petri nets, WF-nets have the same semantics described above. Its behavior can then be represented by its reachability graph. As far as the behavior of a workow is concerned, the corresponding WF-net is associated to an initial marking where only the source places are marked with a single token. Besides, a nal marking of WF-net is every place, that is reachable from a such initial marking, where each sink place is marked and none of the other places is.

Slicing of a Petri net corresponding to a business process

The decomposition of a WF-net corresponding to a business process is based on an onthe-y traversal of the whole Petri net, considered as a graph, and takes into account the following considerations:

1. each sub-net is a WF-net (according to Denition 3.).

the decision to cut a current subnet and start the construction of a new one is

based on the structure of the Petri net and on the nature of the business process activities (respectively):

• when the current node (place) has several output transitions i.e., it is a choice between two (or more) services/activities, (e.g. this may corresponds to an IF...Else structure in a BPEL process, to an OR operator in a BPMN process),

• when the current node (place) has several input transitions i.e. it is a conjonction of several exclusive services,

• when the current node (transition) has several output places i.e., it is the launch of two (or more) parallel services/activities, (e.g. this may corresponds to a Flow structure in a BPEL process, to the execution of a component in a BPMN process),

• when the current node (transition) has several input places i.e., it is a synchronization of several concurrent services,

• when the current node (transition) is the waiting point for the reception of some asynchronous message (e.g. this may corresponds to the Receive activity in BPEL, to the execution of a component implementing receiving messages/parameters in a BPMN process),

• when the current node (transition) is the synchronization point from some synchronous message, (e.g. this may corresponds to the end of the Flow structure in BPEL, to the end of execution of a component in a BPMN process),

3. given the resulting set of subnets, a dependency function, computed on-the-y, allows to deduce the order of the execution of the services corresponding to these subnets. Thus, the combination of the set of subnets with such a function determines the semantics of the whole net.

4. it is possible to compose back the obtained subnets, by merging shared places, to obtain the original whole WF-net. This allows to preserve the original behaviour (semantics) of the Petri net and hence the corresponding business process.

Given a process model, which has been translated to WF-net, we use Algorithm 1

to slice the WF-net into several WF-subnets. The inputs of the algorithm are a current node (curN ode), which can be either a place or a transition, a current subnet (curServ), to be decomposed, and the whole WF-net (W ). The rst call to Algorithm 1 is performed using the following input: the source place of the whole WF-net and a current WF-subnet which is empty. Algorithm 1 is recursive and uses the following functions: N ewService() creates a new subnet and initializes its set of places, transitions and edges with the given parameters. 2. S ∨ S means that either S or S is executed (exclusive or), 3. S || S means that the execution of S and the execution of S are concurrent (parallel).

We also save the subnets generated by each node (curN ode) in BuiltSlice(), so that the generation is done once for each encountered node (place or transition) using the boolean function Alreadytreated().

The slicing algorithm is composed of three main phases: First, starting from the current node, the current subnet service (curServ) is incremented (by adding places and transitions) as long as we are following a linear (sequential) branch of the Petri net i.e. each encountered node has a single input, a single output, and is neither a receive transition nor a synchronous invoke activity (lines 3 -6). When the rst phase terminates, i.e. the current node has more than one input/output node. First, if it is a place then it is the output place of the current subnet (lines 7 -9). Then, if this node has been already treated (lines 10 -15), i.e. a decomposition is starting from this node or a predecessor node has already been performed, then, the set of built subnets must be executed before the current one, and are added as resulting from the decomposition of the initial node (initN ode). Finally, two cases are considered depending on whether the current node is a place (lines 18 -36) or a transition (lines 37 -68). Notice that, in the second case, we do not distinguish whether the current transition is a "normal" one or a receive/synchronous invoke transition.

Given the set of WF-subnets constructed by our algorithm and the computed dependencies between these subnets, one can orchestrate the execution of the whole process by executing these sub-processes separately. The main novelty in our approach is that such scheduling is not centralized. It is distributed on the dierent subnets in such a way that the currently executed sub-process is able to compute (using the dependency function) the set of sub-processes that must be enabled after it nishes its execution. Algorithm 2 accomplishes such a task. It has as inputs the current subnet to be executed, a set of subnets SN , and a dependency function Dep. Thus, an execution of the whole WF-net can be obtained by a call to Algorithm 2 with an empty subnet, the set of subnets and the dependency function issued from Algorithm 1.

In this algorithm, Choice denotes any maximal subset of subnets, denoted by Ch, Algorithm 2 starts by waiting while the precondition of the current subnet is not satised (lines 1 -3), i.e. the source places are not all marked. Then, the current subnet can be executed (leading to a sequence of ring sequence of transitions) (line 4) before determining the set of subnets to be enabled at the next step Init (line 5). Init contains any subnet sn i such that there is no other subnet s j (j = i) such that Dep(sn j , sn i ) =→. If Init contains more than one element, it can be written as Let sn c be some chosen element of Ch (e.g., satisfying a given condition) Execute -subnet(sn i , SN, Dep) 18: end for the following: Init = ch 1 ∪ . . . ch k ∪ P ar where ch i , for i = 1 . . . k are maximal sets containing exclusive subnets, P ar contains concurrent (parallel) subnets (note that, in the rst call, P ar is necessarily empty), and ch i ∩ ch j = ∅ and chß ∩ P ar = ∅, for any i = j. Lines 6 -15 allow to keep in Init the subset P ar and one representative of each subset ch i and to update the set of subnets SN and the dependency function Dep. Once we have in Init the set of the subnets to be concurrently enabled at the next step, each one will be enabled and receives the updated set of subnets and the dependency function (lines 16 -18). Enabling a subnet is putting a token in the source place which coincides with the sink place of the current subnet. Thus, if the next subnet represents a synchronization between several subnets, it must wait until all these subnets nish their execution i.e., each source place is marked (the precondition becomes then satised).

To conclude, Algorithm 2 is associated to each subnet resulting from the decomposition of the whole WF-net and allows each subnet, executed separately, to autonomously launch the subnets to be executed in the next step. The rst call is performed with an empty subnet unless the rst enabled subnet is determined, a priori, by executing lines 5 -15 in which case the rst call can be performed by the subnet resulting from this execution.

Proof of preservation of semantics

Theorem 1 provides the execution chain to follow for obtained subnets to retrieve the business functionality of the initial business process.

Theorem 1. Let SN and Dep be respectively the set of subnets and the dependency function resulting from the application of Algorithm1 on a WF-net N . Let σ be a sequence of transitions. σ is a ring sequence of N (i.e. σ ∈ L(N )) i σ corresponds to an execution of Algorithm 2 with an empty subnet.

Proof.

• ⇒

Let σ be a run of SN and let us demonstrate, by induction on the length of σ (|σ|), that σ can be generated by Algorithm 2. |σ| = 1. Assume σ = t and let i the source place of SN . Then, t ∈ i • and m 0 (i) > P re(t, i) (where m 0 is the initial marking). Thus, the precondition of t is satised and the run of some of the subnets containing i (line 4) will allow to re the transition t. Note that it is possible that i belongs to several subnets when, in SN , |i • | > 1.

Assume that any run of SN , of length n ∈ N, can be generated by Algorithm 2.

Let σ = t 1 ...t n+1 be a run of SN . Then, the sequence t 1 ...t n can be generated by Algorithm 2. We distinguish the two following cases:

1. t n and t n+1 belong to the same subnet sn i . In this case, the run of sn i , by the instruction at line 4 allows to re t n+1 directtly after the ring of t n . 2. t n and t n+1 belong to two dierent subnet sn i and sn j respectively. In this case, only one of the following conditions holds:

(a) Dep(sn i , sn j ) =→ (b) Dep(sn j , sn i ) =→ (c) Dep(sn i , sn j ) = ||
Indeed, the value of Dep(sn i , sn j ) can not be ∨ otherwise t n+1 would not be friable, within SN , after the ring of t n .

* The two rst cases being symmetrical, assume that Dep(sn i , sn j ) =→ = σ k (where σ m is the sux of σ starting at the transition t m and σ m ksn k denotes the projection of this run on the transitions of sn k ). Indeed if this does not hold, then t n+1 would not be enabled within SN . Thus, the precondition of sn j becomes satised (line 1) as soon as t n is red and t n+1 is red by the run of sn j (line 4). * Assume now that Dep(sn i , sn j ) = ||. Then, sn i and sn j can be launched in parallel by the loop instruction at line 16. One can then choose an interleaving allowing to re t n+1 directly after t n .

• ⇐

Let σ = t 1 ...t n be a sequence of transitions (execution) generated by Algorithm 2 and let us assume that σ is not a ring sequence of SN . Note rst that t 1 is reable at the initial marking of SN , otherwise the precondition (line 1) would not be satised and t 1 would not start any sequence generated by Algorithm 1. Thus, if σ is not a ring sequence of SN , then there exists 2 ≤ i ≤ n such that t 1 ...t i-1 is a run of SN and t i is not reable by the marking reached by this run.

We distinguish the two following cases:

1. t i-1 and t i belong both to a subnet sn i . In this case, t i is not enabled by SN is not possible since instruction 4 launch the subnet sn i which has the control on all its transitions i.e. the ring of t i depends only on the ring of t i-1 .

2. t i-1 and t i belong to sn k and sn l (k = l) respectively. t i is not friable means that there exists a place p i ∈ • t i whose marking, after the ring of t i-1 , is strictly less than P re(t i , p i ). This is not possible because the fact that t i is generated by the algorithm (line 4) means that the precondition of the subnet sn l is satised i.e., all the input places of t i have been suciently marked by the execution of the loop at line 16.

Example: Slicing of the Online shop process

For this example, we recall the online shop BPEL process introduced in Section 2.1.3.

To perform the BPEL to Petri net transformation, we use the BPEL2PN 1 tool.

BPEL2PN tool is a Java-based compiler that transforms a process specied in BPEL into a Petri net according to the Petri net semantics [START_REF] Hinz | Transforming BPEL to Petri Nets[END_REF]. The output format of BPEL2PN is a Petri net in the data format of the Petri net based model checker LoLA [START_REF] Schmidt | LoLA: A Low Level Analyser[END_REF] [66].

LoLA also oers the opportunity to write out the net into the standard interchange format for Petri nets, the Petri Net Markup Language (PNML) [START_REF] Billington | The Petri Net Markup Language: Concepts, Technology, and Tools[END_REF]. Thus, since other modeling languages, which are more frequently used in practice, map to Petri nets (for BPEL, see e.g. [START_REF] Lohmann | Comparing and evaluating Petri net semantics for BPEL[END_REF], for BPMN, see e.g. [START_REF] Remco | Semantics and Analysis of Business Process Models in BPMN[END_REF]), our approach is relevant for 1 http://www2.informatik.hu-berlin.de/top/bpel2pn/index.html

Slicing of applications based on services compositions

To slice applications based on services compositions, we opted for the use of directed graph to formally respresent the application components before performing the slicing. The use of a graph-based composition enables us to focus on all application components interactions and dependencies between them when processing the slicing.

Preliminaries on graphs and directed graphs are introduced in Section 3.3.1. The nodes of directed graphs represent the applications services (e.g. the application components in the case of an SCA-based application), the edges represent compositions between these services (e.g. component bindings in the case of an SCA application) sn 1 sn 2 sn 3 sn 4 sn 5 sn 6 sn 7 sn 8 sn 9 sn 10 sn 11 sn 1

- → → → → → → → → → → sn 2 - - ∨ ∨ → ∨ ∨ ∨ ∨ ∨ → sn 3 - - - → ∨ → → → → → → sn 4 - - - - ∨ → → → → → → sn 5 - - - - - ∨ ∨ ∨ ∨ ∨ → sn 6 - - - - - - || → || → → sn 7 - - - - - - - || → → → sn 8 - - - - - - - - || → → sn 9 - - - - - - - - - → → sn 10 - - - - - - - - - - → Table

Preliminaries: graphs, directed graphs

In the following, we introduce both graph and directed graph notions.

Denition 4. (Graphs & directed graphs) A graph G = V, E comprises a set V = {1, ..., n} of n nodes, and a set E of directed edges where (i, j) ∈ E is an edge from node i to node j. We further associate with each edge (i, j) a number δ ij that expresses the relative hierarchy of the nodes. Usually, δ ij = 1 for a directed edge i → j, meaning that i precedes j by one unit.

Slicing of a directed graph corresponding to an application based on services compositions

Given an application based on services compositions which have been translated to a directed graph, we address Algorithm 3 to slice it into several aggregated services. The input of the algorithm is the directed graph G characterized by set of nodes (V ) and edges (E). The algorithm provides as result a serviceList structure. Each element of serviceList describes an application component and all its sub-elements (e.g. service, references, binding, properties, etc.). This algorithm is executed only once to slice an application before its deployment.

Algorithm 3 Slicing and aggregation of an application based on services compositions.

Require:

G = V, E Ensure: serviceList 1: serviceList = ∅ 2: n= sizeOf (V ) 3: k=1 4: while (k <> n) do 5: serviceList(k) ← V k 6:
AggregateService(serviceList(k))

7:

for all t ∈ E do 8:

if (δ kt ) then 9:

GenerateClientInterf ace(V k , V t ) AggregateService(serviceList(k)) process service corresponding to V k code generation and its validity regarding standard service specications. The service code is copied from the component source code. In the case of an SCA-based application, the SCA annotations in the components source code are parsed and transformed to a regular code. For example, a @Property annotation, which provides the name of a given property of a component, is transformed in the service code to a simple or a complex types. A @Reference annotation, which allows a given SCA component implementation to call another component, is transformed to a local call and the @Remotable annotations are transformed to remote calls.

After service aggregation, the algorithm checks if the selected graph node have outgoing edges (line 7) to other nodes (i.e. (δ kt ) =1, ∀t ∈ E). This indicates if the service corresponding to this node has interactions with other services of the application. For all these services, a call to GenerateClientInterf ace is made (lines 8 -10).

GenerateClientInterf ace(V k , V t ) adds a client code to the service code corresponding to V k to allow it to invoke service corresponding to V t . This remote call is carried through conguration of generic clients. The needed properties (i.e. name of the target service, name of the operation to invoke, input parameters number and types, etc.) to set up the clients are determined from the application descriptor (e.g. the .composite le in the case of an SCA-based application).

Introduction

In this Chapter, we detail the second step of the SPD approach. The rst step of our dened approach involved slicing of a service-based application into a set of elementary and autonomous services (See Chapter3). This step aims at packaging the obtained services in micro-containers before deploying them in a target Cloud environment.

The packaging step consists in generating an appropriate micro-container around one service with the minimal modules implementing its required resources (e.g. specic communication bindings). This step is performed when the target Cloud environment do not support provisioning required Cloud resources for hosting and execution of sliced services. The choice of the micro-containers was motivated by (1) the possibility to provision dynamically services' required resources independently of the target Cloud capacities and (2) its higher performances against classical service containers (e.g. Apache Axis) demonstrated in Section 6.3.

Service micro-containers provide the minimal functionalities to manage hosted service life cycle according to the denition introduced in [START_REF] Bernhard | Web services container[END_REF]. These basic functionalities ensure the minimal main process of our micro-containers (e.g. services hosting, interaction with clients, etc.). For example, we failed to incorporate a safety module for managing access since it is a prototype and a service balancer module as we are assuming a single service per container. However, the design of the micro-containers was made so that these modules can be added as extensions or add-ons if necessary.

For example, we add extensions to support services non-functional properties (e.g. migration) if they are requested by the developer. These extensions can be integrated to the generated micro-containers to provide specic features at a very ne degree of granularity (i.e. service level). For example, when adding migration facilities to a given micro-container, we can migrate its service from a hosting machine to another. This prevents us to migrate the entire machine with all its other running services.

We thought of designing a system composed of two main parts:

1. The service micro-container, 2. The generic packaging platform that build the micro-container and package the service to host in it. This Chapter is organized as follows: We present our performed packaging framework and comment the packaging process of a given service in a micro-container in Section 4.2. Then, we detail the architecture of the generated micro-containers in

Service packaging framework

Since we consider several types of services (languages, bindings, etc.), we are able to dynamically generate the correspondent micro-container from the packaging framework for each service to be deployed [START_REF] Yangui | Scalable Service Containers[END_REF] [59] [START_REF] Yangui | CloudServ: PaaS Resources Provisioning for Service-Based Applications[END_REF]. An overview of the main components of the packaging framework and architecture of generated micro-containers are detailed in Figure 4.1.

To package a service and build its appropriate micro-container, one must mainly provide for the deployment framework two elements:

1. The service to package with all its components (code, resources, etc.), 2. A deployment descriptor that species the container options.

The Processor module analyzes the service code, parses its associated descriptor to determine the service binding types and instantiates an appropriate Communication

• • •

The packaging framework provides also a generic client to invoke packaged service in the generated micro-container. The client setup is based on the service bindings type and information described in its contract. For example, for a Java Web service the contract is a WSDL document and needed information to setup the client are described in operation, input, output and service elements.

Service micro-containers process client requests according to the following scenario:

Adding migration facilities to service micro-containers

We extended our micro-containers allowing them to be mobile and give them the ability to migrate, with its service inside, from one host to another once deployed in a Cloud environment [START_REF] Omezzine | Mobile Service Micro-containers for Cloud Environments[END_REF]. To handle this, we used two dierent approaches:

• JADE-based technology integration in the packaging framework,

• Extension of the packaging framework by adding a generic migration module.

JADE-based migration uses an existent mobile multi-agent platform called Java

Agent DEvelopment Framework1 to handle service migration. We have integrated this platform to our service packaging process. The choice of JADE was motivated by the analysis presented in [START_REF] Gupta | A Survey on Comparative Study of Mobile Agent Platforms[END_REF]. In this survey, the authors dress a comparison between existent mobile agent platforms and show that JADE is the most appealing. JADE is FIPA-compliant so it allows interoperability between agents and provides many graphical tools for development and debugging.

The second approach followed consists in extending the packaging framework by adding a generic migration package which component's can be instantiated and parameterized during the packaging phase. Both approaches are detailed respectively in Section 4.4.1 and Section 4.4.2.

JADE-based migration technology integration

The idea we adopted was to encapsulate a micro-container in a mobile agent as detailed in

Adding elasticity facilities to service micro-containers

In order to add elasticity facilities to micro-containers, we extended the packaging framework with adding new generic modules implementing elasticity mechanisms. The added modules are schematized in Figure 4.5.

We have not made changes in the micro-container itself. However, we have include generation of two additional components in the packaging process to implement and process the target elasticity mechanisms. On one hand, we designed a controller container to monitor a designated set of services packaged in micro-containers. The controller is instantiated from the Generic controller component which implements a process controller according to a given formal model [START_REF] Amziani | Time-Based Evaluation of Service-Based Business Process Elasticity in the Cloud[END_REF]. On the other hand, we designed a set of front-end routers (i.e. one per generated service micro-container).

A router is instantiated from the Generic Router component and is assimilated to a micro-container proxy. The invocation of a service packaged in a micro-container must henceforth be processed via the dedicated router. Indeed, the router is responsible of load balancing between all of micro-container instances and ensures then abstraction of all service copies at duplication/consolidation time. The architecture of the routers are strongly inspired from micro-containers architecture to optimize changes on the packaging framework. The routers does not contain services but still contains their contracts in order to facilitate prospective service invocations. The service copies management is insured thanks to a routage table.

Introduction

In this Chapter, we detail the third step of our dened SPD approach. This step is the last one of the approach and covers the deployment in a target Cloud after slicing a service-based application into several elementary services (See Chapter 3) and packaging them in appropriate micro-containers (See Chapter 4) [START_REF] Yangui | The SPD approach to deploy service-based applications in the cloud[END_REF].

According to [START_REF]Service-oriented Computing Track[END_REF], there are four types of service deployment solutions i.e. manual, script-based, language-based and model-based deployment. Since we consider our service micro-containers as standalone and autonomous applications, we opted for the manual deployment.

59

There are two ways to deploy micro-containers: The rst one consists in deploying them as standalone applications in a Cloud infrastructure (IaaS), while the second one consists in deploying them in a Cloud platform (PaaS). Challenges and requirements are dierent for an IaaS or a PaaS deployment.

Deploying service micro-containers in IaaS consists in uploading and running the micro-containers in virtual machines (VMs) instantiated from an infrastructure manager such as OpenNebula 1 or OpenStack 2 . Meanwhile, the micro-containers can also be deployed in existing Cloud platforms as standalone applications (e.g. See [START_REF]Running Standalone Web Applications on Cloud Foundry[END_REF] for deployment in Cloud Foundry, See [START_REF]Process Types and the Procle[END_REF] for deployment in Heroku). This deployment is based on the Cloud platform description models and is performed through their user APIs. It should be noted that for an IaaS deployment, unlike for a PaaS deployment, the developer have to install and congure all prospective resources needed by the application apart service micro-containers (e.g. installation of a database, conguration of the container binding with the database, etc.). Such manipulations add complexity to the deployment task and it is contradictory to Cloud operating principles. Indeed, according to the denition of the Cloud Computing paradigm [START_REF] Mell | The NIST Denition of Cloud Computing[END_REF] and its correspondent economic model [START_REF] Marston | Cloud computing The business perspective[END_REF] [19], installation and conguration tasks related to the deployment should be insured and delegated to the Cloud environment.

Based on this, we can say that a deployment in a PaaS is more appropriate for our use case. So, as part of our work, we dened a generic description model for applica-

Model for PaaS resources description and provisioning

We dened an OCCI-based model for the description of the platform and application resources independently from the targeted PaaS [START_REF] Yangui | An OCCI Compliant Model for PaaS Resources Description and Provisioning[END_REF]. Our proposed model extends the OCCI core model and is composed of two main parts:

1. An OCCI platform extension which describes all PaaS resources that can be provisioned by a PaaS to set up an appropriate environment,

2. An OCCI application extension which describes the application resources to deploy in this environment.

These two extensions dene and classify PaaS resources through generic OCCI types that we have dened. Each one of these types is characterized by a set of attributes and actions to handle and manage it according to the OCCI standard. By doing so, provisioning and management processes of these resources can be aggregated which brings us to handle them on the same way through our dened properties and actions independently of the hosting PaaS. Our two dened extensions are detailed in the rest of the Section. Router entities are use-ful where for example deployed applications on Cloud platforms are multi-tenant and/or service-based and requires then several (may be heterogeneous) containers to be hosted.

Platform resources description model

Table 5.4 describes the attributes that we have dened to describe the Router type through its Kind instance (Router scheme). The actions applicable to a Router instance and the diagram schematizing the evolution of the state value in relation with the execution of these actions are schematized in Figure 5.4. Each action is identied by a Category instance using a /router/action# categorization scheme.

The DatabaseLink link type

To connect these dened platform resources, we modeled a set of platform link entities.

These entities are extended from the OCCI core model Link base type. For example, to link a Container resource to a Database resource, we dene the DatabaseLink type. This link enables a Database instance to be attached to a Container instance for applications interacting with a database system management for example (See As examples of DatabaseLink, we can cite:

• .NET/Connector: which connects a .NET container to a MySQL instance,

• Mongo+Hadoop Connector: which connects a Hadoop server to a MongoDB instance.

A DatabaseLink instance can be set up between two or several Container and Database instances through the Bind action (see Table 5.5).

Table 5.5: Actions applicable to DatabaseLink instances.

Action Attributes Description

Bind source, target bind a Container instance source to a target Database instance.

The ContainerLink link type

We dened the ContainerLink type to enable connecting one or several homogeneous Container resources between them. By homogeneous, we mean same type container instances (see Figure 5.6.). For example, a multi-tenant J2EE application deployed onto two or more Apache Tomcat instances.

Examples of dened platform mixins

In addition to these dened platform resources and links, we can dene platform Mixin if needed. Mixins are dened in order to support specic features and operations oered by some PaaS and cannot be described by the main platform resources that we have dened. We consider for example the service micro-container that can be modeled as platform resource mixin. Indeed, in order to support the particular service microcontainer capabilities (e.g. migration [START_REF] Omezzine | Mobile Service Micro-containers for Cloud Environments[END_REF], monitoring [START_REF] Mohamed | How to provide monitoring facilities to services when they are deployed in the cloud ?[END_REF], etc.), a correspondent mixin, which is a specialization of the Container resource type, is dened. [START_REF]Enterprise Service Bus Documentation[END_REF]. To support these specic features, a WSO2 ESB router mixin was dened.

The correspondent state diagram and relative action are dened in Figure 5.9.

Existing PaaS propose, apart platform resources, a set of technical functionalities and features (e.g. authentication, logging, metering, messaging, etc.) and even paid applications and services through marketplaces (e.g. Heroku add-ons [START_REF]Heroku PaaS Add-ons[END_REF], Cloud

Foundry marketplace [START_REF]Cloud Foundry Marketplace[END_REF], etc.). These functionalities and services are also considered as platform resources. They are supported by our extension and can be modeled as mixins.

Application resources description model

In addition to the platform resource extension, we dene an additionnal OCCI-based application extension. The purpose of this model is to describe an application (i.e. • Environment which represents a set of settings needed to host and run an Application (e.g. runtime, framework, message queue, etc.),

• Application which is the software or program that can be deployed on top of a PaaS (WAR le, Ruby program, etc.).

• Deployable which represents the Application deployables (e.g. sources archives, etc.),

• EnvironmentLink which connects an Application to an Environment. The Environment resource type

The Environment resource models a set of congurations and settings of the platform resources (e.g. Container resources, Database resources, DatabaseLink resources, etc.) and needed to host and run applications on PaaS. Environment resource includes, among others, the needed runtime (e.g. java 7, java 6, ruby, etc.), the needed frameworks/containers (e.g. spring, tomcat, ruby, etc.) and optionally needed provider services (e.g. monitoring, messaging, etc.). The OCCI attributes dened for an Environment resource through its Kind resource instance are listed in Table 5.8. We dened also an action exposed by all Environment type instances in order to update an already existing environment (See Table 5.9). To deploy an Application, the end-user species a set of properties (e.g. application name, application description, etc.). Moreover, if the target PaaS supports the management of multiple instances (e.g. Cloud Foundry), the user can specify the desired number of active instances to ensure application scalability and availability (See Table 5.10).

Once deployed, the Application can be invoked and executed through its public URL provided by the target PaaS. To manage the dierent Application instances, we dened a set of actions (See Table 5.11). These actions allow to start (respectively stop) an already deployed application in a hosting Environment and then to update its state value to available (respectively unavailable ). The update action allow reload an application after setting and/or Deployables changes. The Deployable resource type

The Deployable type models the Application source archives. By deployables, we mean all necessary artifacts (e.g. ZIP le, EAR le, etc.), conguration les (e.g. Chef script, etc) and/or deployment descriptors (e.g. XML le, DAT le, etc.) needed to carry out the application deployment (see Table 5.12).

The end-user can upgrade Deployable instances to apply new source updates for example through the update action (see Table 5.13). The EnvironmentLink link type

COAPS API specications

In

COAPS generic interfaces overview

The COAPS generic interfaces are classied into two resource management packages:

1. The Environment management package which provides COAPS generic operations to create and manage Environment resources, 2. The Application management package which provides generic COAPS operations to create and manage Application resources.

A resource-based representation of the proposed environment management operations is provided in Figure 5.12. Each box represents an Environment resource (or sub-resource), the title text (e.g. /environment, /environment/envId, etc.) represents the resource identier and the body text lists the oered operations by this resource (e.g. FindEnvironments, CreateEnvironment, etc.) and its associated REST methods (e.g. GET, POST, etc.).

Figure 5.12: The COAPS API environment management operations.

In COAPS specications, we consider the basic operations for an application's environment creation and management. The environment management resource oers the following operations:

• Create Environment : creates a new environment using the paas_environment element of the manifest. The operation returns, among others, an environment ID.

• Update Environment : updates an existing environment. An environment ID must be provided and the updates must be specied in a new manifest.

• Destroy/Describe Environment : destroys/describes an environment given its ID.

• Find Environments : lists all available environments.

• Get Deployed Applications : lists all deployed applications in an environment given its ID.

• Get information : lists the runtimes, frameworks and services supported by the targeted PaaS.

As for the environment management resource, we consider the basic operations for an application provisioning and management. Our application resource management package is represented in Figure 5.13.

Figure 5.13: The COAPS API application management operations.

The application resource management package oers the following operations:

• Create Application : creates a new application using the application description in the manifest. The operation returns, among others, an application ID.

• Deploy Application : deploys an application identied by its ID on an existing environment identied by its environment ID.

• Start/Stop/Restart/Un-deploy/Destroy Application : starts/stops/restarts/un-deploys/destroys a deployed application given its ID.

• Update Application : updates an existing application. The application ID must be provided and the updates have to be specied in a new manifest.

• Describe Application : returns an application description given its ID.

• Find Applications : lists the available applications.

• Destroy Applications : destroys all existing applications. More details about current available COAPS implementations are provided in Section 6.2.3.2.

Deployment of service-based applications using COAPS

Generally, service-based applications deployment through COAPS API is performed according to the scenario steps detailed in Figure 5.17.

Figure 5.17: Provisioning applications scenario steps through COAPS API.

These steps represents generic operations of COAPS detailed in Section 5.3.1.

Thanks to COAPS, to provision an application in a PaaS, we follow the same provisioning scenario, the same API operations and the same resources descriptors whatever is the target Cloud platform.

Examples of service-based applications deployment

As illustrative examples, we propose to deploy the shop process and ComputePrice micro-containers obtained after slicing the applications and packaging their services.

The deployment is performed in both IaaS and PaaS.

For an IaaS deployment, we used the Network and Cloud Federation (NCF) experimental platform deployed at Télécom SudParis. We used OpenNebula IaaS manager to instantiate hosting VMs. For a PaaS deployment, we used Cloud Foundry PaaS.

In the following, we describe the work that we have done to deploy and execute shop process and ComputePrice application service micro-containers.

Deployment of shop process

All needed services to deploy the shop process are packaged in micro-containers. There is no more additional modules (e.g. remote Web services, external partner links) service1

To provision the tomcat server and the database instance, we create a novel appropriate environment called JavaWeb_Env (See Listing 5.3). Then, we created a novel application associated to the DetermineTaxRate Web service and we deploy it JavaWeb_Env environment (See Listing 5.4).

Listing 5.4: The Application resource manifest.

1 <?xml v e r s i o n=" 1.0 " e n c o d i n g=" UTF8 " ?> 2 <paas_application name=" DetermineTaxRate " environment=" JavaWeb_Env "> 3 <description>DetermineTaxRate WS . </description> 4 <paas_application_version name=" version1 .0 " label=" 1.0 " url=" DetermineTaxRate . cfapps . io "> 5 <paas_application_deployable name=" DetermineTaxRate . WAR " description =" WAR_file " content_type=" artifact " l o c a t i o n=" /home/yangui/WS " /> 6 <paas_application_version_instance name=" Instance1 " initial_state="1 " default_instance=" true " /> 7 </paas_application_version> 8 </paas_application> OpenShift), we use exactly the same manifests and the same operations.

Conclusion

In this Chapter, we presented and detailed the third step of the SPD approach i.e. In the last Section of the Chapter, we illustrated our ndings by showing the deployment procedures for the shop process and ComputePrice applications in both NCF infrastructure and Cloud Foundry PaaS.

In the next Chapter, we detail and discuss the implementation details of each one of the SPD approach steps.

Chapter 6

Implementation & Experiments

Introduction

In this chapter, we present the implementations we have done to realize the SPD approach, and the experiments we have made to evaluate the eectiveness of our developed tools. Our goal is to prove that our approach is feasible and eective in real uses cases. To that end, we have implemented each step of our dened SPD approach.

To implement the rst step of the SPD approach i.e. slicing a service-based application in a set of elementary services, we developed tools implementing our algorithms introduced in Chapter 3. The developed tools support slicing and aggregating BPELbased processes and SCA-based applications.

To implement the second step of the SPD approach i.e. packaging sliced services in appropriate micro-containers, we implement the packaging framework that allows the service micro-containers building from the framework generic modules (See Chapter 4).

To implement the third step of the SPD approach i.e. deploying the microcontainers in a target Cloud environment, we develop a REST API implementing our proposed applications and PaaS resources description model (See Chapter 5).

Our performed API is a PaaS-independent solution which enables provisioning and managing services and applications in existing Cloud platforms through appropriate implementation of its generic operations.

This Chapter is organized as follows: we describe development details and used technologies to implement each step of the SPD approach in Section 6.2. Then, we present the experimentations that we have performed to (1) highlight classical service container limitations in Cloud environments and (2) evaluate our service microcontainer performances versus classical service containers in Section 6.3. Finally, we present a realistic use case resuming our ndings in Section 6.4.

Implementation

The implementation details of our developed tools are detailed in the following Section.

For each step of the SPD approach, we developed tools that implements algorithms and architectures that we have introduced. Applications slicing and services aggregation tools are detailed in Section 6.2.1. The packaging framework implementation is detailed in Section 6.2.2. COAPS API implementation is detailed in Section 6.2.3.

Application slicers and services aggregation tools

We develop service-based application slicers and services aggregators implementing our algorithms introduced in Chapter 3. Our tools support BPEL-based processes and SCA-based applications processing. For BPEL-based processes, we develop the BPEL2Java tool that slices a given BPEL according to Algorithm 1 before generating and aggregating the java code of each obtained subnet. For SCA-based applications, we develop the SCA2Java tool that slices a given SCA application according to Algorithm 3 before aggregating the java code of obtained services.

BPEL2Java tool

For BPEL-based processes slicing, we follow the following methodology:

1. Generate a Petri net graph from the BPEL to deploy, 2. Slice the Petri net into a set of dependent WF-nets, 3. Sort the subnets to obtain the whole execution chain equivalent to the initial BPEL, sychronous remote call, an Assign activity to a Java assignment instruction and so on). Table 6.1 details a non-exhaustive list of transformation rules that we have dened.

To support the Invoke activity, we add to services code a parameterized generic client stemming from a generic soap client code 1 . The parameters provided to each client are based on information on the .bpel process descriptor and its prospective related .wsdl partner link descriptors. Furthermore, the structured BPEL activities (e.g. IF, Else, While, Switch, Case, etc.) are still the same in Java. The java source code generation is performed by the use of the Codemodel 2 tool. Codemodel is a Java library providing a way to generate Java programs using appropriate packages.

It should be noted that some information are likely to be lost when we generate the Petri net from the .bpel descriptor. Indeed, the choice of execution branch is a nondeterministic choice in a Petri net. Thus, structured BPEL activities (e.g. IF, While, etc.) can not be represented using a Petri net. To nd this kind of information, we annotate the Petri Net elements with these tests and/or conditions. SCA annotation Equivalent Java instruction(s) @Property Java type @Reference local java call @Remotable remote java call

SCA2java tool

We developed a tool called SCA2java implementing Algorithm 3 [START_REF] Yangui | PaaS-Independent Approach to Provision Appropriate Cloud Resources for SCA-based Applications Deployment[END_REF]. The tool sources are available at [START_REF]The SPD approach to deploy service-based applications[END_REF]. These sources are composed of 22 packages, 79 classes and 27339 instructions. The execution of SCA2java is schematized in Figure 6.1.

The tool parses the .composite of a given SCA-based application descriptor using Eclipse modeling framework (EMF 3 ) and initializes the serviceList structure. Each element of serviceList is loaded by an application component and its sub-elements (e.g. service, reference, properties, binding, etc.). After that, for each element of serviceList, we create a correspondent java service. Each generated service represents an implementation of one of the SCA-based application components. These services are composed of two classes: an interface class and an implementation class of this interface. The source code of these services is copied from the initial SCA project. Some aggregation tasks are also performed in the services source code to ensure their validity and compliance with java service specications. Among the major changes that we operate, we can cite the transformations of the SCA annotations to a standard java code. Table 6.2 details a non-exhaustive list of transformation rules from SCA annotations to standard java code that we have dened.

The remote java calls instead of @Remotable annotation are performed by injecting the code of parameterized generic soap client 4 . The client properties (i.e. name of the target service, name of the method to invoke, input parameters number and types) are determined from the .composite SCA-application descriptor and prospective .wsdl remote services descriptors.

Packaging framework tool

We implemented the packaging framework using java according to the system architecture introduced in Section 4.2. The generic framework modules are implemented progressively as java packages and are integrated then in the packaging process when they are linked to the processing module. By doing so, we guarantee that these modules are plugables. In fact, adding new communication protocols or programming 4 https://github.com/impactcentre/iif-generic-soap-client languages support consists in adding the correspondent components in the packaging framework generic packages.

Before starting the packaging process, the developer can specify some settings (e.g. location of the generated micro-container, name of the generated micro-container, listening port value, etc.) through a .properties le representing the deployment descriptor of the micro-container. In addition to that, the packaging framework provides the possibility to package in micro-containers services with specic requirements (e.g. specic librairies, conguration les, etc.). To perform this, the processing module adapts the service invocation package using the JavaAssist 5 tool. autonomous and standalone applications packaged as running Java ARchives (JAR le) thanks to One-Jar tool 6 . The information about the main class to execute in the micro-container are provided in the JAR manifest according to java standard specications. Micro-containers JAR les can be run over a classical standard Java Virtual Machine (JVM).

Once running, a micro-container is listening and waiting for hosting service execution requests through the designated port in the deployment descriptor. The packaged service into a running micro-container can be then invoked through our generic client.

To that end, we setup the client before invocation by updating its .properties le with the appropriate parameters (i.e. micro-containers location, micro-container listening port, operation name to invoke and parameters.).

We also implemented variants of the packaging framework to support migration facilities according to the architectures presented in Section 4.4. The rst variant allows building mobile micro-containers using JADE-based migration. To perform this variant, we integrated the JADE-based framework 7 to our packaging process in order to generate mobile micro-containers (See Figure 4.2). This intermediary step allows integrating additional migration technical modules to micro-containers (e.g. context management module). We have also implemented an administrator agent container to deploy with the mobile containers. This latter is responsible of sending the migration requests to the micro-containers.

The second variant of the packaging framework with migration facilities consists on adding a migration facilities package implementing generic migration modules (See Section 4.4.2). The generic migration modules allow adding a migration component in the micro-containers that interact with a receiver container to perform migration (See Figure 4.3).

COAPS API

COAPS API is an OCCI-compliant solution implementing the platform and application resources description and provisioning model that we have dened [START_REF] Sellami | PaaS-Independent Provisioning and Management of Applications in the Cloud[END_REF] open-source Cloud platform, the EASI-CLOUDS platform (see Figure 6.4), that can be instantiated to set up an application type-specic cloud (e.g. e-learning, HPC-ondemand, storage marketplace) for a private, public, or hybrid usage, and implementing a given level of security, privacy and QoS [START_REF]Easi-Clouds project description[END_REF]. An EASI-CLOUDS platform must also provide the required facilities for intra-cloud cooperation and federation.

In this project, one of our objectives is to provide the required facilities promoting EASI-CLOUDS platforms federation. COAPS is used in this context to enable application provisioning/management (i) between EASI-CLOUDS platforms of a same federation and also (ii) with other existing commercial PaaS (see Figure 6.4).

Examples of existing COAPS implementations

Currently, we provide a Cloud Foundry and OpenShift implementations (respectively called CF-PaaS API and OS-PaaS API) [START_REF] Sellami | PaaS-Independent Provisioning and Management of Applications in the Cloud[END_REF]. These implementations are developed in Java and provided as RESTful Web applications (i.e. WAR). We also developed a generic Web client for application provisioning and management in PaaS with an implementation of our API (See Figure 6.5). All these implementations demonstrate the easy way of developing a new COAPS implementation through the proxy system that we have dened, even by a tierce party, with only the sources and documentation that we provide.

Experimentations

In this Section, we present and comment the experiments that we have conducted.

Service containers limitations in Cloud environments

Generally speaking, to deploy an application on a service container, one must mainly provide two elements:

• The application with all its components (e.g. compiled classes, resources, etc.),

• A deployment descriptor that species the container options to run the application.

There are several types of service containers. For example, for the J2EE technology there are: Web containers for servlets and JSP, EJB containers for EJBs, and client containers for applications on standalone terminals using J2EE components.

In line with the denition given in [START_REF] Bernhard | Web services container[END_REF], we can dene a Web container as an application that implements the communication contract between dierent application components obeying to a distributed architecture. This contract species a runtime As part of our work, we decided to conduct a set of experimentation scenarios involving classical service containers in realistic Cloud context. To that end, we considered Apache Axis 2 12 which is one of the most adopted service containers in the industry world. Therefore, Apache Axis 2 can handle a big number of services at the same time and response to client's queries in an acceptable time. These experimentations allowed us to highlight its lacunas for deployment and management of a huge number of Web services in Cloud environments [START_REF] Yangui | Scalable Service Containers[END_REF] [59]. At each iteration of the experiments, we deployed a number of services set in advance and then we took the measures using a java client. On the one hand, based on the curve shown in Figure 6.6, we note that the response time of an Axis 2 client request is too large from 600 deployed services. We also noted a total crash of Axis 2 from 630 deployed services. On the other hand, based on the curve shown in Figure 6.7, we noticed an important increase of the host machine memory consumption especially for high numbers of services. These two aspects of Axis 2 behavior are characteristics of several classical Web containers we studied and represent the two major defects which prevent these containers to scale and thus makes it unsuitable for Cloud context.

Based on these ascertainments and after studying dierent architectures of service containers (e.g. See [START_REF] Perera | Axis2, Middleware for Next Generation Web Services[END_REF] for Apache Axis 2 container, See [START_REF] Langlet | Apache Tomcat 6 Guide d'administration du serveur Java EE sous Win-dows et Linux[END_REF] for Apache Tomcat container, See [START_REF] Dhesiaseelan | Web Services Container Reference Architecture (WSCRA)[END_REF] for Web Services Container Reference Architecture), we realized that they aren't able to scale among many physical machines. Any of those containers Figure 6.7: Apache Axis 2 server memory consumption evolution.

can be deployed physically just on one machine, so the Cloud using such containers will reach its limits when this host machine uses its entire resources even if the other machines are charge free. Based on this, we can say that the Cloud's limit is the same limit of the host machine in which we deployed the service container. This machine presents then a bottleneck in every Cloud using such containers for service-based applications.

This motivated our decision to design and implement the service micro-containers.

We think that if each service is deployed separately, the Cloud can really contain as much deployed services as it is allowed by the available physical resources of the Cloud.

Each service can be deployed in a micro-container anywhere in the Cloud with the minimal use of its resources. We can deploy as many micro-containers as it is possible on any machine, if this machine reaches its limit we can deploy on a second one then on a third and so on. With this idea we are sure that we use the minimal resources to encourage the pay as-you-go model of Cloud Computing [START_REF] Robert | The Case for Cloud Computing[END_REF] and we can enforce the elasticity of Cloud because we just use the resources needed.

Service micro-containers experimentations

To perform these experiments, we chose to evaluate the performance of our microcontainers opposite to Apache Axis 2. As far as we know, Axis 2 is one of the most used and ecient classical services containers. These experiments aimed to validate the good behaviour of our micro-containers for a huge number of deployed services in a Cloud context and to demonstrate its superior performances and scalability comparing to classical service containers such as Axis 2.

Firstly, we developed a test collection generator to obtain thousands of generated Web services code archives and their WSDL les. The functionality which implements these Web services is the same: calculation of an arithmetic operation of two integers.

At each iteration of the experiments, we deployed a number of services set in advance, we invoke one of these services randomly selected using a classic java client and then we took the measures.

We have considered a couple of criteria that we think essential to evaluate the two service containers performance:

• Response time: Time taken by a service container between request reception instant and response sending instant,

• Memory consumption: Memory size necessary to load and process deployed services in the container after receiving a request.

The experiments was conducted in the Network and Cloud Federation (NCF)

experimental platform deployed at Télécom SudParis. When we conducted these experiments, the NCF platform has: 380 Intel Xeon Nehalem Cores, 1.17 TB RAM and 100 TB as shared storage. We have used OpenNebula 13 resources manager to create our experimental VMs using various personalized templates. Characteristics of the templates we used for experimentations are detailed in Table 6.3. To perform these tests, we dened several scenarios with dierent alternatives.

These scenarios reect the objectives that we want to highlight in our experiments.

The details of these experiments are as follows: Obtained results of each one of these scenarios are detailed in the rest of this Section.

Axis 2 Versus Micro-container with various VMs

In the rst series of tests, we deployed just one service on Axis 2 and on the microcontainer. After that, we deployed these containers on dierent virtual machines created by various templates listed in Table 6.3 and then we took measurements.

The purpose of this experiment is to see the impact of the VM template choice on performance of the two containers. Figure 6.8 shows the dierent stored values for Axis 2 and MC for one service response time deployed in these VMs while Figure 6.9

shows the evolution of their memory resources consumption. During these experiments, we had to make a choice between:

• Alternative 1: Test by comparing Axis 2 performance versus a single instance of the micro-container performance,

• Alternative 2: Test by comparing total CPU time between all instances of deployed micro-containers running in parallel versus Axis 2.

Finally, we opted for the rst alternative plan because we chose to compare performance of the two service containers with the same test collection of deployed services. Based on the curves schematized in Figure 6.10, we note that Axis 2 response time increases proportionally to the number of deployed services. Concretely, a major part of this time evolution lies on the time needed for Axis 2 to update hosted services indexation mechanisms, manage execution contexts and load the requested service.

Processing service request, service execution and response building process times are roughly steady. For our micro-container, the response time is approximately the same for all the experiences. This can be explained by the fact that each instance of the micro-container is independent from the others, and hosts only one service (no service context management then). Hence, we can deploy as many micro-containers as it is possible regarding the available resources in the virtual machine without aecting the response time. In this testing environment, Axis 2 crashed when 630 services are deployed because there is no more memory resources on the hosting virtual machine for deploying and processing more services. Actually, Axis 2 overowed into the virtual machine due to its excessive memory resources consumption. However, our micro-container reached more than 2000 deployed services using our dened approach without any performance degradation. These interpretations are also veried by the memory consumption measures presented in Figure 6.11.

Axis 2 Versus Micro-container with less CPU VMs (T5 template)

In this experimentation scenario, we repeated the same tests with changing only the template used to intantiate the hosting VMs. We used T5 template in order to increase the memory capacity of the hosts (1Gb of memory instead of 512 Mb) and low CPU power. The purpose of this operation is to avoid Axis 2 crash observed in the previous experiment by providing more memory in the hosting VMs. Figure 6.12 shows the dierent stored values for response time experiments while Figure 6.13 shows memory resources consumption evolution for the two containers. We notice that the memory usage is linear and increases according to the evolution of the number of deployed services in the two containers. Obtained curves show the savings of the micro-container against Axis 2 in memory usage. This is due to the large number of programs and operating les generated by the Axis 2 core to index and manage hosted services (e.g. archives, index, temporary les, context les, etc.). Axis 2 has exceeded its limit observed in the latest experience due to the lack of memory, but it still crashing when we increase the number of deployed services (1230 deployed services for this test). This crash is due to an overow of the hosting VM CPU. On the other side, for the same VMs, we deployed more than 2000 services on micro-containers with steady response times. All this inspired us to repeat these tests with overpowering templates. The detail of these tests is detailed in the next subsection.

Axis 2 Versus Micro-container with powerful VM (Tp template)

In this experimentation scenario, we create powerful VMs instantiated using Tp template in order to eliminate all physical limit aspects which penalized Axis 2 during last scenarios. Figure 6.14 schematizes the obtained response time curve, while Figure 6.15 schematizes the obtained memory consumption curve. In this experiments, we note that Axis 2 reaches and exceeds the limits observed in previous scenarios. However, it crashes for 3860 deployed services while CPU and memory resources are still available in the hosting VM. In fact, this crash is caused by the design of Axis 2 itself, which begins to fail from a given number of services even if the host still have resources. This is an intrinsic limitation related to the architecture of Axis 2, which is certainly ecient and adequate for an industrial use but still unreliable for such environments. This is true for all classical service containers (e.g.

Apache Tomcat, Metro, GlassFish, etc.).

In the same testing environment, we was able to deploy more than 4000 services in micro-containers with steady response time and memory consumption values. Indeed, when using micro-containers, the limit number of deployed services is the physical limit of the VM while Axis 2 crashes when it reaches its logic limit of supported hosting services.

Based on these curves, we observed that just before the Axis 2 crash, response times increase abruptly. In fact, for a huge number of services, Axis 2 has to manage much indexes and service contexts which led it to consume more resources and degrades its performance. The idea that we had was to determine the optimal range number of services that Axis 2 can host and then confront the two containers performance in this range. This can easily be determined by a simple calculation of the memory space ratio used for a number of deployed services in Axis 2 based on the values of the curve in Figure 6.15 (i.e. between 800 and 1000 services for these experiments). Recorded micro-container performance values for this range are better than the Axis 2 values.

Axis 2 Versus Micro-container with mutiple VMs usage (T6 template)

In this experimentation scenario, we use multiple Axis 2 instances deployed on multiple VMs. We deploy services respectively on Axis 2 and MC until the saturation of the hosting VM. Then, we instantiate a second with a second Axis 2 instance, and we resume deployment until the saturation of the second host and so on. This scenario simulates horizontal scalability in a Cloud provider. For these tests, we used T6 VM template to reach quickly the VMs limits. When multiple VMs are used, the memory consumption values represent the sum of all memory spaces used in all allocated VMs.

The curves related to these experiments are shown in Figure 6.16 and Figure 6.17.

Using Axis 2, we used 4 VMs to host 1200 services while we used only 1 VM when using micro-containers. For the same number of used VMs (i.e. 4 VMs) we have successfully deployed more than 5000 services using micro-containers, while we could deployed only 1200 services using Axis 2. Based on this, we can say that not only that micro-container performance are superior to Axis 2 performance but also that using micro-container on Cloud providers costs less than using classical service containers.

Mobile service micro-container experimentations

We also conduct a set of experiments to evaluate the mobile micro-containers performances and determine the overhead of the added migration. We decided to evaluate our two variants of mobile micro-containers against classical micro-container to evaluate their performances when they provide the same functionality (i.e. migration).

To do this, we have considered the same test collections of services (i.e. calculation of an arithmetic operation of two integers provided as inputs), the Tp template to instantiate hosting VMs and the same comparison criteria (i.e. server response time and memory resources consumption) used to evaluate micro-container against Axis 2.

The results of the experimentation of the two variants of the mobile micro-containers are detailed in the rest of this Section.

JADE-based service micro-container experimentations Response time values of both containers increase when we increase the number of deployed services. Response time values are approximately similar with a slight overhead for the JADE-based migration. We note also that the JADE platform crashes when deploying more than 2500 services even though there are available memory and computing resources in the hosting VM. For memory consumption experiments, we quantify that the used memory overhead for JADE-based micro-containers exceeds 50% regarding the classical microcontainer memory consumption. Based on these measurements, we can conclude that adding migration to service micro-containers using JADE platform does not aect service micro-container response time. However, JADE platform usage engenders an important memory consumption overhead and it crashes when a huge number of deployed services is reached. These limits are due to the architecture of JADE multiagent platform which is composed of agents' server that consume a lot of memory resources. This Agent server is a technical component of the JADE platform and mandatory for its deployment and execution. It is responsible of managing the life cycle of the mobile agents and maintaining an up-to-date list of agents with their location.

Migration-based service micro-container experimentations This overhead is due to memory resources consumed by the receiver but remains nevertheless neglected. Indeed, we need only one receiver per VM to manage all the micro-containers hosted in this VM. We conclude the migration overhead in this case is not signicant compared to JADE-based micro container overhead.

Use case: Provisioning of autonomic applications

In the following, we present a realistic use case resuming our ndings. This use case consists in provisioning applications with autonomic computing capacities in Cloud platforms. Autonomic applications are applications able to monitor and recongure their components autonomously based on specic technical components to be deployed with the application. We present in the rst part of the Section the context and the purpose of autonomic applications provisioning and management in Cloud platforms.

Then, we detail the implementations that we have performed to acheive the stated objective in the second part of the Section.

Context and purpose of the use case

According to studies that we carried, Cloud platforms do not support monitoring and reconguration for deployed applications together at the same time. Indeed, a human intervention is still required to interpret, as it should be, the application monitoring data and act based on these data in order to maintain the required execution of the application. Therefore, Cloud providers do not support provisioning of autonomic applications. These applications are able to manage, automatically and dynamically, their required resources to respect their Service Level Agreement (SLA). In this context, we propose a novel approach to provision autonomic applications in existing Cloud platforms.

To provision an autonomic application in a Cloud platform, we couple:

1. An OCCI-based autonomic resources description model and an API implementing this model [START_REF] Mohamed | Adding Monitoring and Reconguration Facilities for Service-Based Applications in the Cloud[END_REF],

2. Our OCCI-based platform and application resources description model and COAPS as its implementation.

Implementation and validation

Concretely, our approach proposes to dynamically add autonomic management facilities to applications when deploying them in a target PaaS. As for elastic SBPs provisioning approach, our novel framework requires no modication on the Cloud system side and can be deployed and supported by any PaaS thanks to our performed generic provisioning mechanisms.

The performed system is schematized in Figure 6.22. To establish our autonomic computing framework, we start by setting up an OCCI Server. This server encompass COAPS as the PaaS interface, implements both autonomic resources and platform/application description models and is responsible of instantiating and managing OCCI resources.

The rst Resource instantiated in this server is the Autonomic Manager Resource.

The Autonomic Manager is responsible of preparing the Application resource based on the provided SLA before its deployment. To perform that, the Autonomic Manager detects the attributes and/or services that need to be monitored for the application.

Then, it extends the application artifacts by adding necessary monitoring Mixins (i.e.

Polling and/or Subscription) and a Reconguration Mixin to enable reconguration facilities. After that, the Autonomic Manager sends a request to COAPS in order to instantiate resulting Application Resource (i.e., the basic Application Resource with their newly added Mixins), deploy it in the target PaaS and start it. We create rstly the hosting Environment resource. Then, we create the Application resource and we process deployment by associating the given EnvId to the AppId before starting the Application.

After that, the Autonomic Manager instantiates and customizes the needed Resources and Links in order to establish the autonomic framework. For ease of presentation, we refrain from presenting all the Mixins in Figure 6 The last step is to link the Planner to the Application Resource using an Action Link that can use the generated reconguration actions and applies them.

This work allows us to provision already performed autonomic computing framework and autonomic applications in Cloud platforms that do not provide basically monitoring and reconguration facilities. In addition to that, the use of COAPS allows us to make this provisioning PaaS-independent.

Conclusion

In this Chapter, we presented the implementations that we have done to validate our SPD approach and prove its feasability and good performance. The total metrics of all developed tools are 45 packages, 287 classes and 60325 instructions.

For the rst step of our approach, we achieved BPEL2Java and SCA2java tools that implements our dened slicing and aggregation algorithms for both BPEL-based processes and SCA-based applications. After that, for the second step, we provide details about the implementation procedure and technologies that we have used to implement the packaging framework and service micro-containers building. For the third step, we presented COAPS API that we have developed to implement our platform and application resources description model and to perform deployment in Cloud platforms. Results and interpretation of service micro-containers performance experimentations against Apache Axis 2 server in Cloud environment are also provided.

In the last part of the Chapter, we presented a realistic use case consisting in provisioning autonomic applications in Cloud platforms using COAPS API.

Chapter 7

Conclusion and Perspectives "

Conclusion

Service-based applications are described according to Service Oriented Architecture (SOA) and consist of assembling a set of elementary and heterogeneous services using appropriate service composition specications such as Service Component Architecture (SCA), Business Process Model and Notation (BPMN) or Business Process Execution Language (BPEL). These applications are built from components and services that may be heterogeneous in the sense that they (1) are not all implemented using the same programming languages (e.g. C++, Java, etc.), (2) do not support all the same communication protocols (e.g. RMI, SOAP/HTTP, etc.) and/or (3) do not run on the same hosting frameworks (e.g. POJO VM, .NET framework, etc.).

Provisioning a service-based application in the Cloud consists of: (1) allocation of adequate resources to host and execute the application and (2) upload of the application artifacts (e.g. binary code) on the allocated resources. This provisioning task requires then the delivery of appropriate frameworks and specic runtimes supporting the heterogeneity of the application components. In addition to that, such applications are often distributed and require occasionally deploying their components separately on multiple Cloud platforms. Meanwhile, existing Cloud platforms has proprietary description models to describe, manage and provision applications and their hosting resources. They expose also proprietary and heterogeneous user APIs (e.g.

proprietary operations, specic provisioning scenarios, etc.).

To tackle this issue, we dened in this thesis an approach that we called SPD to provision service-based applications in Cloud environments. The SPD approach consists in three steps:

1. Slicing the application into a set of elementary services, 2. Packaging the resulted services into service micro-containers, 3. Deploying the micro-containers in a target Cloud environment.

Since service-based applications have heterogeneous components it is dicult to satisfy its requirements by provisioning one allocated hosting environment based on existing Cloud environment capabilities. Therefore, we propose to slice the applications into a set of elementary and autonomous services before allocating a dedicated and appropriate environment for each one of the obtained services. In this step, we considered: (i) applications modeled as business processes and can be formally represented using Petri nets and (ii) applications modeled as composition of service components that can be represented using graph-based composition. The use of formal representations allows us to preserve semantics of sliced applications. For applications modeled as business processes, we dened algorithms to slice their correspondent Petri net into a set of dependent WF-nets and to determine the choreography schema to follow for their execution. We also provided the proof of preservationof initial business process business semantics when executing the WF-nets. We provide an implementation (i.e.

BPEL2Java) and an illustrative example supporting the slicing of a BPEL process and the aggregation of its obtained services according to transformation rules that we have dened. For applications modeled as composition of service components, we dened an algorithm to slice its correspondent directed graph into a set of elementary services and aggregate them. We provide an implementation of this algorithm (i.e.

SCA2Java) and an illustrative example supporting slicing SCA-based applications.

For the second step of our approach, we dene a packaging framework architecture that allows service micro-containers building around a given service from generic modules. Only necessary resources to implement service binding types, such as communication protocols, are selected from the packaging framework and encapsulated in the generated micro-container to host the service. We also propose extensions of this framework to include support of a set of non functional properties, such as migration, monitoring and elasticity, if they are required by the developer. We provide implementation of the packaging framework for Java services communicating in HTTP/SOAP.

We conduct several experimentations to (1) highlight the classical service containers limitations in Cloud environments, (2) show the superior performance of our microcontainers against these service containers and (3) determine the overhead of the migration facilities if they are included to a micro-container.

In the third step of our approach, we can deploy the service micro-containers in As a realistic use case of our contributions, we present and detail the process of provisioning autonomic applications in Cloud platforms. Autonomic applications are applications able to monitor and recongure its components autonomously based on specic technical components to be deployed with the application. Thanks to COAPS, the application and the related autonomic computing framework are provisioned and started in Cloud Foundry.

To conclude, our dened SPD approach provide exible deployment mechanisms to support the strong heterogeneity of the service-based application components and generic provisioning procedures to allow applications portability and automate and unify the resources allocation and applications deployment whatever is the target Cloud environment. Furthermore, the SPD approach easily integrates with existing applications and handled resources and requires no modication in the Cloud environment side.

Future work

In the future work, we aim at extending our proposed generic resources description model to include:

1. Cloud platforms management support, 2. Mobile collaborative computing devices and capacities support.

These two perspectives are detailed in the following.

Cloud platform management

Mobile collaborative computing applications and resources provisioning

The growth of mobile applications using Cloud resources for computing and storage The involved Cloud resources in this process are often specic. On one side, the handled applications are designed and developed for collaborative computing or include features to let users work together over networks (e.g. Microsoft Oce and Exchange, Lotus Notes, Videoconferencing applications, etc.). On the other side, mobile applications require often specic execution frameworks and runtimes (e.g. Shared Services Framework (SSF), Android application framework, etc.) to meet with the portable devices characteristics. Moreover, the relationships between the system components (i.e. applications, mobile end users and available Cloud resources) are particular. Indeed, the allocated Cloud resources for applications execution and data storage are ad-hoc while the application must be all the time available. Furthermore, the management of the incoming/outgoing resources must be transparent for the user.

All this therefore aects the way in which we describe the applications, their execution resources and the way in which we provision them.

In this context, we propose to (1) extend our resources description model to include describing and provisioning support of mobile collaborative applications and resources and (2) extend COAPS API by providing additional operations and descriptors to support provisioning and managing these resources.

Figure 2 . 3 :

 23 Figure 2.3: The online shop process.

  model-based Cloud platform upperware, is an European project that aims designing and implementing a platform for applications development and deployment in the Cloud using an appropriate predened methodology [2]. PaaSage's model-based methodology supports the Cloud lifecycle phases of conguration, deployment and execution. These phases are based on the Waterfall Model of Software Development [1] illustrated in Figure 2.6.

Figure 2

 2 Figure 2.6: Application lifecycle overview [1].

Figure 2 . 7 : 2 .

 272 Figure 2.7: Main PaaSage architectural stack [2].

Figure 2 . 9 :

 29 Figure 2.9: Cloud4SOA reference architecture [4].

Figure 2 .

 2 Figure 2.9 details the reference architecure introduced by Cloud4SOA. This architecture consists of 5 layers: • Service Front-end layer : provides a dashboard and a set of GUIs to access to the Cloud4SOA features • Semantic layer : provides the formal representation of information (e.g. PaaS resources, application dependencies, etc.). The 3 parts of the ecosystem are supported by this fomalization (i.e. the Cloud end-user, the Cloud-based application and the Cloud PaaS provider).

Figure 2 . 10 :

 210 Figure 2.10: Contrail architecure [5].

Figure 2 .

 2 12 schematizes a typical PaaS architecture as it is dened by CAMP. The PaaS provider implements a set of technical components in order to meet the deployed application requirements. These requirements are exposed 24 SIOPP is pronounced 'shop'

Figure 2 . 13 :

 213 Figure 2.13: CAMP platform resources and relationships [7].

Figure 2 .

 2 Figure 2.14 schematizes dened types of the core model, as it was introduced in [8], and relations between them. The Kind type is the core of the types classication system built into the OCCI core model. Kind is a sort of specialization of Category. It allows denition of all resource capabilities in terms of management actions. An Action represents an invocable operation applicable to a Resource instance. Any resource exposed through OCCI is a Resource or a sub-type of Resource instance. The Resource type is complemented by the Link type which associates one Resource instance to an

Figure 2 . 14 :

 214 Figure 2.14: UML class diagram of the OCCI core model [8].

Figure 2 .

 2 [START_REF]OASIS Web Services Business Process Execution Language (WSBPEL)[END_REF] illustrates dened types for the OCCI infrastructure model as it was introduced in[START_REF] Metsch | Open Cloud Computing Interface -Infrastructure[END_REF]. These infrastructure types inherit the OCCI core model Resource base type and all their attributes.

Figure 2 . 15 :

 215 Figure 2.15: Overview diagram of OCCI infrastructure types [9].

  need an object-oriented model specically designed for Cloud Computing and exible enough to be enriched with new extensions. For all of these reasons, we choose the OGF OCCI open standard. Indeed, to the best of our knowledge, OCCI is the only standard model compliant with these criteria. Moreover, OCCI is an open standard, that in addition to ensure interoperability and portability, allows not loosing the efciency and specicities of the Cloud systems. One of the objectives that we want to achieve in this thesis is to extend OCCI in order to dene unied platform and application resources description model and to propose a REST API implementing this model and allowing provisioning such resources in a unied way whatever is the target PaaS. Such unication upstream Cloud platforms facilitates cooperation and federation between them and probably will convince users who are still hesitant to adopt the PaaS economic model. A lot of works have already dealt with this aspect at

4

 4 Example: Slicing of the Online shop process . . . . . . . . . . . . . 42 3.3 Slicing of applications based on services compositions . . . . . 43 3.3.1 Preliminaries: graphs, directed graphs . . . . . . . . . . . . . . . . 44 3.3.2 Slicing of a directed graph corresponding to an application based on services compositions . . . . . . . . . . . . . . . . . . . . . . . . 44 3.3.3 Proof of preservation of semantics . . . . . . . . . . . . . . . . . . 46 3.3.4 Example: Slicing of the ComputePrice application . . . . . . . . . 46 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3. 2 . 1 . 1

 211 Petri nets Denition 1. A Petri net (Place-Transition net) is a bipartie directed graph N = P, T, F, W where:

  Each node x ∈ P ∪ T of the net has a pre-set and a post-set dened respectively as follows: • x = {y ∈ P ∪ T | (y, x) ∈ F }, and x • = {y ∈ P ∪ T | (x, y) ∈ F }. Adjacent nodes are then denoted by • x • = • x ∪ x • . Given a set of nodes S, | S | denotes the cardinality of S i.e. (the number of elements belonging to S).

  where any couple (sn 1 , sn 2 ) ∈ Ch × Ch, Dep(sn 1 , sn 2 ) = ∨. Moreover, Dep S , where Dep is the dependency function and S is a subset of subnets, denotes the projection of Dep on the subset S. Finally, Dep \ Dep S denotes the dependency function obtained by eliminating Dep S from Dep.

Algorithm 2 5 :

 25 Execution of the current subnet and determination of the next subnets. Require: Subnet CurSN, Set of subnets SN, Dependency f unction Dep Ensure: Executing CurSN and enabling next subnets 1: while Precondition of CurSN is not satised do Set of subnets Init = {sn i | ∃ sn j : Dep(sn j , sn i ) =→} 6: if | Init |> 1 then 7: for all Choice ch ⊆ Init do 8:

9 :

 9 Init = (Init \ Ch) ∪ {sn c } 10: Dep = Dep \ Dep Ch 11: SN = SN \ Ch 12: end for 13: end if 14: Dep = Dep \ Dep Init 15: SN = SN \ Init 16: for all sn i ∈ Init do 17:

Figure 3 . 1 :

 31 Figure 3.1: The Petri Net corresponding to the shop process.

Figure 3 . 2 :

 32 Figure 3.2: The decomposed Petri Net corresponding to the shop process.

3 . 1 :

 31 Dependency function of the decomposition of the shop process and the edge directions indicate the call ways. The slicing algorithm that we have addressed is presented in Section 3.3.2. This algorithm slices a given application into a set of elementary and autonomous services based on its directed graph representation and information in its descriptor (e.g. a .composite le in the case of an SCA-based application). The services compositions are replaced by remote calls. An illustrative example of an SCA-based application slicing is provided in Section 3.3.4.

k=k+1 13 :

 13 end while Algorithm 3 traverses the graph and assigns each node to a serviceList cell (line 5) before performing a call to AggregateService function (line 6).

  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2 Service packaging framework . . . . . . . . . . . . . . . . . . . . 50 4.3 Service micro-container . . . . . . . . . . . . . . . . . . . . . . . . 51 4.4 Adding migration facilities to service micro-containers . . . . . 52 4.4.1 JADE-based migration technology integration . . . . . . . . . . . . 52 4.4.2 Adding generic migration package to the packaging framework . . 53 4.5 Adding elasticity facilities to service micro-containers . . . . . 55 4.6 Adding reconguration and monitoring facilities to service microcontainers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.7 Example: Packaging of Shop process and ComputePrice services 57 4.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Section 4 . 3 .

 43 The service micro-container might include one or more non-functional properties if they are required by the developer such as migration, monitoring and/or elasticity. These extensions are detailed respectively in Sections 4.4, 4.6 and 4.5. Finally, illustrative examples consisting in packaging processes of services obtained from slicing the online shop process (See Section 3.2.4) and ComputePrice application (See Section 3.3.4) are detailed in Section 4.7.

1 .

 1 Receiving of the client request, 2. Extracting communication protocol envelops (e.g. HTTP SOAP header), 3. Invocation of the packaged service, 4. Building of the response message, 5. Send the response back to the client.

Figure 4 Figure 4 . 4 :

 444 Figure 4.4: Mobile micro-container migration steps.

5. 5

 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

  tions and PaaS resources to generalize the deployment procedure in Cloud platforms. Our dened model allows seamless interactions with dierent and heterogeneous PaaS and address applications portability issues (See Section 1.2). Our model extends the OCCI standard and provide unied operations through a REST API that we called COAPS for applications provisioning and management in Cloud platforms. Once deployed, the micro-containers are started and begin to listen to prospective client requests for invoking packaged services. To execute a deployed application, a client sends an invocation request to the micro-container that hosts the rst service of the application. The call sequence between the dierent micro-containers ensures the semantic functionality of the whole initial service-based application and returns the same execution result. This Chapter is organized as follows: We present and comment our dened generic description model for platform and application resources in PaaS in Section 5.2. COAPS API is a REST API implementing this model and providing generic interfaces for applications and PaaS resources provisioning. COAPS API specications are detailed in Section 5.3. Finally, the deployment procedures of the micro-containers packaging online shop and ComputePrice services are described in Section 5.4. 1 opennebula.org 2 openstack.org

Figure 5 . 1 :

 51 Figure 5.1: Overview of the dened OCCI platform types.

Figure 5 . 4 :

 54 Figure 5.4: State diagram and actions applicable to Router type instances

Figure 5 .

 5 Figure 5.5.).

Figure 5 . 5 :

 55 Figure 5.5: DatabaseLink type: A binding between Container and Database resources.

Figure 5 . 6 :

 56 Figure 5.6: ContainerLink type: A connector between Container and Router resources.

Figure 5 . 7 :

 57 Figure 5.7: RouterLink type: A connector between several Container resources.

Figure 5 . 11 :Figure 5 .

 5115 Figure 5.11: EnvironmentLink type: A connector between Application and Environment resources.

  this Section, we detail COAPS API specications. COAPS is a REST-based and OCCI-compliant API implementing our introduced description model (See Section 6.2.3 for COAPS implementation details). The choice of the REST architecture was motivated by the type of existing Cloud platforms APIs interacting with COAPS wich are almost all REST-based. COAPS exposes a set of generic interfaces for applications and PaaS resources provisioning and management and is based on a proxy system that we have designed to provide appropriate implementations of these interfaces when interacting with existing Cloud platforms. The full version of the COAPS API specications is available at[START_REF]A generic Cloud Application Provisioning and Management API[END_REF].

  the COAPS generic interfaces and the proprietary actions exposed by the selected PaaS API. Several COAPS interfaces can be coupled to a single PaaS operation if needed (e.g. POST Deployables and POST Application operations for Cloud Foundry implementation) and/or some COAPS operations can be ignored (and then not implemented) for the case where there are not supported by a specic PaaS (e.g. POST RouterLink operation for Cloud Foundry implementation insofar as Cloud Foundry manages itself the routage between DEA components). Cloud Foundry DEAs are the components which contains and manages the embedded service containers.

Figure 5 . 21 :

 521 Figure 5.21: Cloud Foundry Web graphic console screenshot showing deployed Com-putePrice application services.

Figure 5 .

 5 Figure 5.21 presents a screenshot of the Cloud Foundry Web graphic console 5 showing our three services deployed in Cloud Foundry. Generally, when deploying in PaaS through COAPS, we have only to provide required platform resources description. In fact, instantiation and parameterization of these resource (e.g. Tomcat instance in-5 console.run.pivotal.io/

  deploying the packaged services in micro-containers in the Cloud. Both deployment in Cloud infrastructures and Cloud platforms are treated. Briey, the deployment in IaaS consists on instantiating VMs and uploads the service micro-containers on them before starting their execution as standalone applications. For the deployment in a PaaS, we dened a generic description model for applications and PaaS resources. Our proposed description model is based on the OCCI standard. According to OCCI, each identied PaaS resource is characterized by a set of attributes, management actions and associate lifecycle. Based on this model, we are able to describe, provision and manage a given PaaS resource in an unied way whatever is the target Cloud platform. We also performed a PaaS-independent REST API called COAPS implementing this model to process applications deployment and management on target PaaS. We presented and commented the COAPS specications.

Figure 6 . 1 :

 61 Figure 6.1: SCA2java execution process sequence diagram.

Figure 6 .

 6 Figure 6.2 schematizes the performed packaging framework tool modules and the service micro-container generation process. The developed sources are composed of 10 packages, 155 classes and 4543 instructions.

Figure 6 . 2 :

 62 Figure 6.2: Service packaging and micro-container generation sequence diagram.

Figure 6 . 5 :

 65 Figure 6.5: CF-PaaS Proxy generic Web client.

  environment for Web components including safety and competition management, lifecycle, transactions, deployment and other services. Web containers can generally use their own Web server and also be used as a plug-in in a dedicated Web server (as is the case with Apache servers or Microsoft IIS). Examples of Web containers are Tomcat and Axis which are open sources projects from Apache foundation.

Figure 6 . 6 and

 66 Figure 6.6 and Figure 6.7 show respectively the behavior of the response time and memory resources consumption for Apache Axis 2 server regarding the number of deployed services. To perform these experiments, we have used one virtual machine with 0.5 GHz of CPU and 512 Mb of memory. We have also developed a test collection generator to obtain thousands of generated Java Web services code archives and their correspondent WSDL les. The functionality which implements these Web services is basic: calculation of an arithmetic operation of two integers.

Figure 6 . 6 :

 66 Figure 6.6: Apache Axis 2 server response time evolution.

Figure 6 . 8 :

 68 Figure 6.8: Response time evolution with dierent VMs templates (Axis 2 Vs MC).

Figure 6 . 9 :

 69 Figure 6.9: Memory consumption evolution with dierent VMs templates (Axis 2 Vs MC).

Figure 6 . 10 :

 610 Figure 6.10: Response time evolution-Axis 2 Vs MC (T4 VM template).

Figure 6 . 11 :

 611 Figure 6.11: Memory consumption evolution-Axis 2 Vs MC (T4 VM template).

Figure 6 . 12 :

 612 Figure 6.12: Response time evolution-Axis 2 Vs MC (T5 VM template).

Figure 6 . 13 :

 613 Figure 6.13: Memory consumption evolution-Axis 2 Vs MC (T3 VM template).

Figure 6 . 14 :

 614 Figure 6.14: Time response evolution-Axis 2 Vs MC (Tp VM template).

Figure 6 . 15 :

 615 Figure 6.15: Memory consumption evolution-Axis 2 Vs MC (Tp VM template).

Figure 6 . 16 :

 616 Figure 6.16: Time response evolution in multiple VMs-Axis 2 Vs MC (T6 VM template).

Figure 6 . 17 :

 617 Figure 6.17: Memory consumption evolution with multiple VMs-Axis 2 Vs MC (T6 VM template).

Figure 6 .

 6 Figure 6.18 shows behaviour of obtained response time values for both JADE-based micro-container and classical micro-container when we vary the number of deployed

Figure 6 . 18 :

 618 Figure 6.18: Response time curve (JADE-based migration Vs MC).

Figure 6 . 19 :

 619 Figure 6.19: Memory consumption curve (JADE-based migration Vs MC).

Figure 6 .

 6 Figure 6.20 shows behaviour of response time values for both mobile micro-container and classical micro-container. The two curves shape is almost identical except for a few minor dierences in some measures. This can be explained by our approach when we implemented the migration module. In fact, this module is implemented and integrated in classical micro-containers as an extension; we have not modied the architecture and the basic modules (i.e. communication module, invocation module) of the micro-container.

Figure 6 . 20 :

 620 Figure 6.20: Response time curve (M-MC Vs MC).

Figure 6 . 21 :

 621 Figure 6.21: Memory consumption curve (M-MC Vs MC).

Figure 6 .

 6 Figure 6.21 shows behaviour of the memory resources consumption for both containers. The curves shape is identical with a light overhead for mobile micro-container.

Figure 6 . 22 :

 622 Figure 6.22: Autonomic Computing framework overview.

  .22. Therefore, we kept just the needed Mixins instances of Strategies Mixin (i.e. Strategy1 and Strategy2) and Reconguration Actions Mixin (i.e. Action1, Action2). The Autonomic Manager instantiates the Analyzer and subscribes it to the Application Resource. The Analyzer may receive notications through an instance of the Notication Link. At the reception of a notication, the Analyzer uses Strategies Mixin to process incoming monitoring information. If one of the strategies is veried, the Analyzer may raise alerts to the Planner. Accordingly, the Autonomic Manager instantiates the Planner and links it to the Analyzer using an Alert Link. The Planner generates then a plan for reconguration actions. The used plans are responsible of generating reconguration actions.

existing

  Cloud infrastructures (IaaS) and Cloud platforms (PaaS). The deployment in IaaS consists in instantiating VMs and uploads the service micro-containers on them before starting their execution as standalone applications. For the deployment in a PaaS, we dened a generic description model for applications and PaaS resources. Our proposed description model is based on the OCCI standard. According to OCCI, each identied PaaS resource is characterized by a set of attributes, management actions and associate lifecycle. Based on this model, we are able to describe, provision, and manage applications and PaaS resource in a unied way whatever is the target Cloud platform. We also developed a PaaS-independent REST API called COAPS implementing this model to process applications deployment and management on tar-get PaaS. We provide COAPS specications proxy architecture and current available implementations (e.g. CF-PaaS API, OS-PaaS API, etc.). We comment and discuss the deployment of the micro-containers stemming from our illustrative examples. The deployment in IaaS is performed on Network and Cloud Federation (NCF) infrastructure deployed at Télécom SudParis, while the deployment in PaaS is performed in Cloud Foundry through COAPS.

  Our proposed description model (See Section 6.2) allows the description and the management of applications and generic platform resources. COAPS API which implements this model (See Section 6.3) enables provisioning and handling these resources in existing Cloud platforms.As perspective of this work, we propose to extend our model and its correspondent API to support management of not only the hosting and execution resources (e.g. service containers, databases, etc.) but also technical platform components (e.g. platform load balancers, monitoring services, etc.). This extension is indented to platform administrators prole and plans to add new mechanisms for managing eciently Cloud platforms. In fact, existing PaaS provides tools and admin APIs allowing administrating their technical resources (e.g. duplicate DEA component in Cloud Foundry, monitor the load balancer in Heroku, refresh Health Controller component in Cloud Foundry, etc.). As it is the case for applications and hosting resources, these resources and correspondent APIs are proprietary and specic per PaaS.In this Context, we propose to census all technical Cloud platforms resources and dene a novel generic model allowing their description and management. We plan also to propose a generic admin API allowing administrating these resources in a unied way whatever in the target PaaS.

  (e.g. Instagram, Dropbox, etc.) has induced the proliferation of mobile devices which collaborates each others, usually in real time, by taking advantage of underlying Cloud resources.Generally speaking, collaborative computing paradigm presents a unied data processing model in which Services, Processes and end users collaboratively work on shared data towards a common goal[START_REF] Caverlee | Editorial for CollaborateCom 2011 Special Issue[END_REF]. Mobile collaborative computing suggests that the end user devices are made for portability, and are therefore both compact and lightweight. Performances of such devices are limited hence the usefulness of using collaborative computing.

  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . COAPS API . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Cloud platform management . . . . . . . . . . . . . . . . . . .

	Table of contents	xv
			6.3.2	Service micro-containers experimentations . . . . . . . . . . . .
			6.3.3	Mobile service micro-container experimentations . . . . . . . .
		6.4	Use case: Provisioning of autonomic applications . . . . . . . . . . . .
			6.4.1	Context and purpose of the use case . . . . . . . . . . . . . . .
			6.4.2	Implementation and validation . . . . . . . . . . . . . . . . . .
	6.5 7 Conclusion and Perspectives 7.1	Chapter 1 Introduction
			"
	6.2	Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
		6.2.1	Application slicers and services aggregation tools . . . . . . . .
		6.2.2	Packaging framework tool . . . . . . . . . . . . . . . . . . . . .
		6.2.3

6.3 Experimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Service containers limitations in Cloud environments . . . . . . 7.2.2 Mobile collaborative computing applications and resources provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

  Cloud Application Management for Platforms (CAMP) . . . . . . 25 2.4.3 Open Cloud Computing Interface (OCCI) . . . . . . . . . . . . . . 27 2.4.4 Related academic work . . . . . . . . . . . . . . . . . . . . . . . . 30 2.5 Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

	Chapter 2 State of the Art

In the last part of the Chapter, we detailed two realistic use cases of applications provisioning in Cloud platforms based on our ndings. Finally, in Chapter 7, we summarize our work and give an outlook of the future work. Contents 2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.1 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2 Service Oriented Architecture (SOA) . . . . . . . . . . . . . . . . . 9 2.1.3 Business Process Execution Language (BPEL) . . . . . . . . . . . 10 2.1.4 Service Component Architecture (SCA) . . . . . . . . . . . . . . . 12 2.2 Related work evaluation criteria . . . . . . . . . . . . . . . . . . 14 2.3 Approaches for applications provisioning in the Cloud . . . . . 15 2.3.1 PaaSage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.2 mOSAIC project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.3 Cloud4SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3.4 Contrail Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.5 Other research projects . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.6 Related academic work . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4 Approaches for Cloud resources description . . . . . . . . . . . 23 2.4.1 Topology and Orchestration Specication for Cloud Applications (TOSCA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.4.2

Table 2 .

 2

				1: PaaSage project synthesis.
		SOA support Portability Standardized model Standardized API
		YES	NO	NO	NO
	2.3.2 mOSAIC project
	mOSAIC	15 , result of an European collaborative project, is an open-source API and
	platform for multiple Cloud systems. mOSAIC oer tools for developing portable
	Cloud-applications which can consume hardware and software resources oered by
	multiple Cloud providers [3].
	Figure 2.8 details the mOSAIC platform architecture. The Application Support
	includes the API implementations and Application Tools, as well as the Semantic
	Engine and Service Discoverer. The API exposes operations to build and manage
	14

http://www.eclipse.org/ Figure 2.8: mOSAIC platform overview [3].

Table 2 .

 2 2: mOSAIC project synthesis.

	SOA support Portability Standardized model Standardized API
	NO	YES	YES	YES
	2.3.3 Cloud4SOA
	Cloud4SOA 16 is an European research project that provides an interoperable multi-
	PaaS Cloud solution for SOA applications. Cloud4SOA oers to developers the ability
	to select, deploy and manage applications in several PaaS [4]. The main contributions
	of this project consists of providing facilities to developers to switch their applications
	from one PaaS to another with minimum change and adpatation eorts, so Cloud4SOA
	aims at enabling applications portability. Cloud4SOA establish an abstration layer,
	based on an appropriate dened ontology, upstream dierent PaaS and exposes a
	common generic management interface to ensure the interoperability of the solution.

Table 2 .

 2

		3: Cloud4SOA project synthesis.
	SOA support Portability Standardized model Standardized API
	YES/NO *	YES	YES	YES
	(*) Cloud4SOA provides mechanisms to provision applications described according
	to SOA in connected PaaS oerings as long as they support SOA applications hosting
	and execution.
	2.3.4 Contrail Project
	The Contrail 17 project aims to design, implement, evaluate and promote an open
	source computational Cloud wherein users can limitlessly share resources [28]. The
	Contrail vision is a federation of resources provided by public and private Clouds.
	17 contrail-project.eu

Table 2

 2

			.4: Contrail project synthesis.
	SOA support Portability Standardized model Standardized API
	NO	NO	YES	YES

Table 2 .

 2

			5: Other project syntheses.
	Project SOA support Portability Standardized model Standardized API
	Cloud-TM	NO	NO	YES	YES
	4CaaSt	NO	NO	YES	YES
	RESERVOIR	NO	NO	YES	YES
	2.3.6 Related academic work
	When considering generalist application architectures, provisioning procedures are
	basically based on resource allocation algorithms that match between applications
	requirements, provided by the end user, and available node resources at the provider
	side in order to maximize the performances and minimize the operating cost [33] [34]
	[35].
	18 www.cloudtm.eu/
	19 www.4caast.eu/
	20 www.reservoir-fp7.eu/

Table 2 .

 2

			6: TOSCA synthesis.
	SOA support Portability Standardized model Standardized API
	YES	NO	YES	YES

2.4.2 Cloud Application Management for Platforms (CAMP)

Table 2 .

 2 7: CAMP synthesis.

SOA support Portability Standardized model Standardized API YES NO YES YES 2.4.3 Open Cloud Computing Interface (OCCI)

Table 2

 2

.8 lists the OCCI infrastructure types and their related links. Compute, Storage and Network types inherit the Resource base type dened in OCCI core model. They represent respectively a generic information processing resource (e.g. virtual machine, CPU), networking devices (e.g. switch)

and data storage devices (e.g. disk). The StorageLink type represents a link from a Resource to a target Storage instance (e.g. Linking a VM to a disk) while the Net-workInterface allow interacting with a Network instance (e.g. network adapter). It can extended using the mix-in mechanism to support specic capabilities (e.g. Ipnet-

Table 2 .

 2

	Term	Scheme	Related Kind

8: The kind instances dened for the infrastructure subtypes of Resources, Links and related Mixins. Compute < schema > /inf rastructure# < schema > /core#resource Storage < schema > /inf rastructure# < schema > /core#resource Network < schema > /inf rastructure# < schema > /core#resource StorageLink < schema > /inf rastructure# < schema > /core#link NetworkInterface < schema > /inf rastructure# < schema > /core#link Ipnetworking < schema > /inf rastructure/network# them (e.g. start, stop, etc.). To summarize, OCCI entities are abstract and need to be extended to support SOA applications. In addition to that, OCCI specications and API are generic and are intented to unify Cloud resources provisioning and management. This standard is open source, so they allow interoperability and portability of resources applications included.

Table 2 .

 2

			9: OCCI synthesis.
	SOA support Portability Standardized model Standardized API
	NO	YES	YES	YES

Table 2 .

 2

10 details a synthesis of presented related work results. The cited research projects propose concrete approaches for services and applications provisioning in Cloud providers. Some of them provide solutions to address portability issues in order to enable multi-cloud deployment and address portability and vendor lock-in issues (e.g. mOSAIC, Contrail). However, the majority of them failed to provide ecient mechanisms to support the high heterogeneity of applications described according to SOA. For example, Cloud4SOA allow the deployment of service-based applications 25 www.getchef.com/chef/ in connected PaaS oerings if the target PaaS supports provisioning of its required resources.

Table 2 .

 2 10: Synthesis of related work results.

	Project SOA support Portability Standardized model Standardized API
	mOSAIC	NO	YES	YES	YES
	PaaSage	YES	NO	NO	NO
	Cloud4SOA	YES/NO	YES	YES	YES
	Contrail	NO	NO	YES	YES
	Cloud-TM	NO	NO	YES	YES
	4CaaSt	NO	NO	YES	YES
	RESERVOIR	NO	NO	YES	YES
	TOSCA	YES	NO	YES	YES
	CAMP	YES	NO	YES	YES
	OCCI	NO	YES	YES	YES

For the cited academic and existing related work, we noticed that approaches which are based on the integration of classical service containers in Cloud environment have limitations. These features are extensions of the Cloud system predened resources rather than the support of service-based applications execution and hosting (e.g. FRASCATI-based PaaS solutions, Apache Tuscany cloudware, etc.). Indeed, based on experimentations results that we have conducted (See Section 6.3.1), we demonstrated that classic service containers design is still neither elastic nor scalable

[START_REF] Yangui | Scalable Service Containers[END_REF]

[START_REF] Mohamed | Web Service Micro-Container for Service-based Applications in Cloud Environments[END_REF]

.

  The set of markings reachable from a marking

• t, W (p, t) ≤ m(p). If a transition t is enabled by a marking m, then its ring leads to a new marking m (denoted by m t -→ m ) s.t. ∀p ∈ P : m (p) = m(p) + C(p, t).

  2. Let N 1 = P 1 , T 1 , F 1 , W 1 and N 2 = P 2 , T 2 , F 2 , W 2 be two Petri nets such that P 1 ∩ P 2 = ∅ and T 1 ∩ T 2 = ∅. The composition of N 1 and N 2 by merging of common places, denoted by N 1 ⊕ N 2 , is a Petri net P, T, F, W where P = P 1

	2 , sharing a subset
	of transitions (resp. places), can be composed by merging these transitions (resp.

places) leading to a Petri net regrouping the local attributes of N 1 and N 2 . In the approach presented in this paper, we manage to compose Petri nets with disjoint sets of transitions (i.e., sharing only some places). Denition

  Then, there exists a set of subnets P ar i such that ∀sn k ∈ P ar i , ∀sn ∈ P ar i there exists a run σ k of sn k s.t. σ m ksn k

l ∈ P ar i , Dep(sn k , sn l ) = || ∧ Dep(sn k , sn j ) =→ . If such a set is empty let P ar i = sn i . There exists m < n s.t. for any subnet sn k

Table 5 .

 5 2: Database type attributes. Every dened action is identied by a Category instance using a /database/action# categorization scheme.

	Attribute	Type	Multiplicity Mutability Description
	occi.database.name	String		0...1	Mutable	Name of the in-
						stance.
	occi.database.type	Enum {relational,	0...1	Mutable	Scheme type of the
		KeyValue,				instance.
		document, graph}
	occi.database.	Enum {x86, x64}	0...1	Mutable	CPU architecture
	architecture					of the instance.
	occi.database.version	String		0...1	Mutable	Version label of the
						instance.
	occi.database.state	Enum {available,	1	Immutable Current state of the
		unavailable}				instance.
	Action Term Target state Attributes
		StartDB	Available		DB credentials
		StopDB	Unavailable	-
		RestartDB	Available		DB credentials
		BackupDB	None		-
	Figure 5.2: State diagram and actions applicable to Database type instances
	Table 5.2 details the attributes describing the Database type through its Kind
	instance (Database scheme). The state attribute indicates the current state of a
	given instance. The execution of an action induces to the modication of its value
	according to the diagram presented in Figure. 5.2. For example, for an already created
	and unavailable Database instance, the execution of the StartDB action brings the
	instance state to available by updating the state attribute value. Action Term refers
	to the term of the Action's category identier.
	The Database resource attributes and actions are exposed by all Database type
	instances and are necessary to describe and handle the context of these instances

(e.g. provisioning of a new instance, updating an existing instance, etc.). Database resource actions are used to manage these instances (e.g. start an instance, backup an instance, etc.).

Table 5 .

 5 6: Service micro-container mixin attributes.

	Attribute	Type	Multiplicity Mutability Description
	File_name	String	1	Mutable	MC le name (e.g.
					JAR name).
	Requirements	Set of String	0...1	Mutable	Running requirements
					(e.g.	JRE version,
					start command, etc.).
	state	Enum {available,	1	Immutable Current state of the in-
		migrating, restarting,			stance.
		unavailable}

The service micro-container mixin attributes are listed in Table

5

.

6

. Relative actions and associated state diagram are presented in Figure 5.8. Note that the micro-container mixin extends the state diagram of the Container resource type (See Figure 5.3) with an additional state i.e. migrating related to migration time (i.e. the MigrateMC action is being executed) from one host to another (See Section 4.4).

A second example of platform mixin might be a WSO2 ESB router mixin. This mixin is specialized from the Router resource type. WSO2

3 is an Open Source Enterprise Service Bus (ESB) router which allows users to congure message routing, virtualization, intermediation, transformation, logging, task scheduling, load balancing, failover routing and event brokering. WSO2 ESB design is specic and strongly extensible to allow integrating new modules if needed from a remote P2 repository (e.g. installing the Carbon UI Feature)

  See Figure5.10). Table5.7 describes the Kind instances dened for each one of the application Resource or Link sub-types.

	OCCI core model (
	any computer software or program) that can be hosted and executed by a PaaS us-
	ing dened platform resources. Quite like our dened platform resource types, the
	application resource types extends OCCI core types. Both applications resources and
	the links between them are respectively derived from Resource and Link types of the
	3 wso2.com

Figure 5.10: Overview of the dened OCCI application types.

The dened OCCI application types are:

Table 5 .

 5 7: The kind instances dened for the application subtypes of Resources and related

	Links.
	Term	Scheme	Title	Related Kind
	Environment	< schema > /application# Environment Resource < schema > /core#resource
	Application	< schema > /application#	Application Resource < schema > /core#resource
	Deployable	< schema > /application#	Deployable Resource < schema > /core#resource
	EnvironmentLink < schema > /application#	Environment Link	< schema > /core#link

Table 5 .

 5 8: Environment resource type attributes.

	Attribute	Type	Multiplicity Mutability Description
	occi.environment.	String	0..1	Mutable	Name of the instance.
	name
	occi.environment.	String	0..1	Mutable	Human readable de-
	description				scription of the in-
					stance.
	occi.environment.	Float, 10 9 (GiB)	0..1	Mutable	RAM allocated to the
	memory				instance.
	occi.environment.	Set of (var,	0..1	Mutable	Environment variables
	variables	value)			associated to the in-
					stance.
	occi.environment.	Set of URIs	0..1	Mutable	Set of URIs of Con-
	containersList				tainer instances associ-
					ated to the instance.
	occi.environment.	Set of URIs	0..1	Mutable	Set of URIs of
	databasesList				Database	instances
					associated to the
					instance.
	occi.environment.	Set of URIs	0..1	Mutable	Set of URIs of Router
	routersList				instances associated to
					the instance.
	occi.environment.	Set of URIs	0..1	Mutable	Set of URIs of
	databasesLink				DatabaseLink	in-
					stances associated to
					the instance.
	occi.environment.	Enum {avail-	1	Immutable Current state of the in-
	state	able, unavail-			stance.
		able}
	The Application resource type

The Application resource type models any computer software or program that can be deployed on top of a PaaS. Dened Environment resource type instance enables

Table 5 .

 5 9: Actions applicable to Environment type instances.

	Action Term Target state	Attributes
	Update	None	Platform resources list
	hosting and executing one or more Application resource type instance(s). This hosting
	Environment is set up thanks to the instantiation and the conguration of necessary
	platform resources, links and mixins.

Table 5 .

 5 10: Application type attributes.

	Attribute	Type	Multiplicity Mutability Description
	occi.application.	String	0..1	Mutable	Name of the instance.
	name
	occi.application.	String	0..1	Mutable	Human readable de-
	description				scription of the in-
					stance.
	occi.application.	integer	1..N	Mutable	Number of the instance
	instances				copies.
	occi.application.	URL	0..1	Mutable	The public URL asso-
	url				ciated to the instance.
	occi.application.	Set of URIs	0..1	Mutable	Set of URIs of Deploy-
	deployables				able associated to the
					instance.
	occi.application.	Enum {started,	1	Immutable Current state of the in-
	state	stopped}			stance.

Table 5 .

 5 11: Actions applicable to Application type instances.

	Action Term Target state	Attributes
	Update	None	Application description
	Start	started	-
	Stop	stopped	-
	Restart	started	-

Table 5 .

 5 12: Deployable type attributes.

	Attribute	Type		Multiplicity Mutability Description
	occi.deployable.	String		0..1	Mutable	Name of the instance.
	name
	occi.deployable.	String		0..1	Mutable	Human readable description
	description					of the instance.
	occi.deployable.	Enum	{arti-	0..1	Mutable	Archive types of the instance.
	content_type	fact, war, jar,
		ear}
	occi.deployable.	URL		0..1	Mutable	Location of the artifact associ-
	location					ated to the instance. It can be
						a le path or a logical Name.
	occi.deployable.	Enum	{avail-	1	Immutable	Current state of the instance.
	state	able,	unavail-
		able}

Table 5 .

 5 13: Actions applicable to Deployable type instances.

	Action Term Target state Attributes
	Update	None	Artifacts

  Contents 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.2.1 Application slicers and services aggregation tools . . . . . . . . . . 88 6.2.1.1 BPEL2Java tool . . . . . . . . . . . . . . . . . . . . . . . 88 6.2.1.2 SCA2java tool . . . . . . . . . . . . . . . . . . . . . . . . 90 6.2.2 Packaging framework tool . . . . . . . . . . . . . . . . . . . . . . . 91 6.2.3 COAPS API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.2.3.1 COAPS realistic use cases . . . . . . . . . . . . . . . . . . 94 6.2.3.2 Examples of existing COAPS implementations . . . . . . 96

6.3 Experimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 6.3.1 Service containers limitations in Cloud environments . . . . . . . . 97 6.3.2 Service micro-containers experimentations . . . . . . . . . . . . . . 99 6.3.3 Mobile service micro-container experimentations . . . . . . . . . . 106 6.4 Use case: Provisioning of autonomic applications . . . . . . . . 109 6.4.1 Context and purpose of the use case . . . . . . . . . . . . . . . . . 109 6.4.2 Implementation and validation . . . . . . . . . . . . . . . . . . . . 109 6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Table 6 .

 6 2: Examples of dened transformation rules of SCA annotations to Java instructions.

  CLOUDS project stands for Extendable Architecture and Service Infrastructure for Cloud-Aware Software. This project aims at oering novel and benecial solutions for both Cloud consumers and providers. The major expected outcome is an

	EASI-
	(See Sec-
	tion 5.2). COAPS API handles Application and Environment resources. Environment
	resources are in turn composed of platform resources (e.g. Container, Router, DatabaseLink,
	etc.). COAPS sources are composed of 2 packages, 2 classes and 312 instructions.
	COAPS API is based on both Representational State Transfer (REST) architec-
	ture [90] and the OCCI HTTP Rendering [54]. OCCI HTTP Rendering denes how
	to interact with an OCCI model to manage its resources while REST architecture
	describes a style for building distributed systems. REST architectural style is based
	on resources associated to unique identiers (e.g. URI). The interactions with these

  The rst series of experiments was carried out to highlight classical service containers (e.g. Apache Axis, Apache Tomcat, etc.) limitations in Cloud context. The results and ascertainments of these experiments are presented in Section 6.3.1. The second series of experiments was performed to evaluate our service micro-container performances against classical service containers in Cloud environments. The results of these experiments are detailed in Section 6.3.2. Finally, we conducted experiments to evaluate mobile micro-containers performances and migration overhead. The results of these experiments are detailed in Section 6.3.3.

Table 6 .

 6 3: Used templates details for VMs instantiation.

	Template name CPU (MHz) Memory (kb)
	T1	1	1024
	T2	1	512
	T3	0.5	1024
	T4	0.5	512
	T5	0.25	512
	T6	0.25	128
	T7	0.25	64
	Tp	3	4096

  These experiments show that for the same deployed service and whatever is the template used to instantiate the hosting VM, the micro-container performances are better than Axis 2. The micro-container sends back responses faster than Axis 2 and consumes less memory. However, for both service containers, we do not notice any For this experimentation scenario, we have chosen to use identical VMs to host the two containers and vary the number of deployed services. The template we used to instantiate VMs is T4, a low memory template. Figure6.10 shows the dierent stored values for response time experiments.

	major changes in performance when changing the VMs template except when using
	T7 template. Indeed, for this template increases for Axis 2 server and decreases for
	service micro-containers.
	Axis 2 Versus Micro-container with less memory VM (T4 template)

http ://www.paasage.eu/

http://jade.tilab.com/

one-jar.sourceforge.net/

http://jade.tilab.com/

Remerciements

Dep(curServ, S) =→

add S to BuiltSlices(initN ode) The function Dep(S, S ) determines the occurrence dependency between the subnets (services) S and S . Such a dependency can be of three kinds:

1. S → S means that once the execution of S is nished, the execution of S should start, also performed packaging framework extensions to add non-functional service properties support in generated micro-containers if needed. At the end of the Chapter, we provided details about packaging obtained services after online shop process and ComputePrice application slicing.

In the next Chapter, we present the third step of the SPD approach i.e. deploying the packaged services in existing Cloud environments. Chapter 5 Service Deployment

Contents

• Database resources which are data store resources for platform applications processing persistent data (e.g. MySQL, PostgreSQL, CouchDB, etc.),

• Container resources which are engines to host and run applications (e.g. Apache Axis container, Bonita, IBM WebSphere, etc.),

• Router resources which are resources that provide protocols, message format transformations and routing (e.g. ESBPetals router, Apache Synapse, etc.).

We also dene a set of links to connect and interact with these resources:

• ContainerLink to connect to Container resources,

• RouterLink to connect to Router resources,

• DatabaseLink to connect a Container resource to a Database resource.

The Kind instances dened for each one of the platform Resource or Link subtypes are described in Table 5.1. In addition to that, a set of platform mixin resources can be dened if needed through this extension to support specic platform resource features (e.g authentication PaaS features, logging PaaS features, etc.). After that, we call the DeployApplication operation to process the uploading of the sources and deployment of the application in the target PaaS provider. Specically, this operation requires the already created envId and appId to perform the link between them ( EnvironmentLink resource ).

Once the application is deployed, we call the StartApplication operation to run it and make it available to prospective request calls

Deployment of ComputePrice application

The ComputePrice SCA-based application has an external component in the form of remote Web service ( DetermineTaxRate component) and a database instance (See Section 2.1.4). So, provisioning the ComputePrice application requires the deployment of: (i) its correspondent micro-containers, (ii) DetermineTaxRate Web service on a reachable Tomcat instance and (iii) the used database instance. The provisioning is performed in both NCF infrastructure and Cloud Foundry PaaS.

Deployment of ComputePrice application in NCF infrastructure

An overview of the performed deployment is detailed in Figure 5.20. The Com-putePrice application provisioning in NCF infrastructure is performed as follows:

4. Generate and aggregate services code corresponding to the WF-nets. • Each Petri Net transition is equivalent to its correspondent BPEL activity,

• None of the Petri net places has equivalent in BPEL. Places make sense only in a Petri net network.

BPEL2Java sources are available at [START_REF]The SPD approach to deploy service-based applications[END_REF]. These sources are composed of 11 packages, 155 classes and 28131 instructions. The java code generation is based on transformation rules that we have dened to be able to convert a BPEL activity to an equivalent java sequence instructions (e.g. an Invoke:oneway BPEL activity will be transformed to a Java asynchronous remote call, an Invoke activity to a Java resources are based on a standardized communication protocol (e.g. HTTP).

COAPS API exposes a set of generic and RESTful HTTP operations (i.e. GET, POST, PUT and DELETE) for Cloud applications management and provisioning (See Section 5.3). Concretely, these operations implement actions that can be applied to Environment and Application resources according to our dened model. We implemented these resources based on the OCCI4java 8 project. OCCI4java implements the OCCI core specications and the OCCI infrastructure extension. We extended this project to include implementations of our platform and application extensions.

We also developed a generic Web client (see Figure 6.5) for applications provisioning and management in existing PaaS. The Web client acts as an access point for the API implementations and allows the user to call the Environment/Application management operations. Through this client, we show that our API allows a seamless (i.e.

using (1) the same application/environment manifests structure and (2) the same management actions) PaaS application provisioning.

In the following, we discussed two realistic use cases of COAPS API before detailing its current available implementations. environments [START_REF] Laisne | Next-Generation Cloud Management. The CompatibleOne Project[END_REF]. The ACCORDS platform authorizes application developers to choose the runtimes and frameworks of their choice to deploy their applications. The developers are not supposed to consider proprietary characteristics related to a specic PaaS. To ensure these requirements, COAPS API and its related resources description model were proposed [START_REF] Yangui | Com-patibleOne: The Open Source Cloud Broker[END_REF]. Indeed, describing applications using a generic model and using a unied API for their provisioning enabled us to meet the portability challenges across several PaaS.

As a proof of concept for the COAPS module, the demonstration illustrated in