Clément Quinton

Nicolas Haderer

Romain Rouvoy

Laurence Duchien

Towards Multi-Cloud Configurations Using Feature Models and Ontologies

Keywords: D.2.10 [Software Engineering]: Design-Methodologies, Representation, D.2.13 [Software Engineering]: Reusable Software-Domain engineering, Reuse models Cloud Computing, Model-Driven, Configuration Cloud, Ontology, Feature Model, Multi-Cloud, Variability

  L'archive ouverte pluridisciplinaire

INTRODUCTION

In cloud computing, resources are accessed on demand by customers and are delivered as services by cloud providers in a pay-per-use approach [START_REF] Armbrust | Above the Clouds: A Berkeley View of Cloud Computing[END_REF][START_REF] Buyya | Cloud Computing and Emerging IT Platforms: Vision, Hype, and Reality for Delivering Computing as the 5th Utility[END_REF]. This service provisioning model brings flexibility to companies that rely on cloud providers' infrastructure to run their applications. The whole software stack required to host the application can be either configured by hand in a Virtual Machine (VM) [START_REF] Quinton | Leveraging Feature Models to Configure Virtual Appliances[END_REF] or directly provided by cloud PaaS providers.

When deploying an application into the cloud, companies have to deal with a wide range of resources at different levels of functionality among available cloud solutions. This leads to complex choices which are usually made in an ad hoc manner. Dealing with this cloud variability and resources dimensions, e.g., database size, ends up in selecting a cloud solution by adopting ad hoc criteria. It is all the more true when considering a multi-cloud configuration, i.e., the deployment of an application over several cloud providers [START_REF] Grozev | Inter-cloud architectures and application brokering: taxonomy and survey. Software: Practice and Experience[END_REF], e.g., when a cloud provider does not provide the whole functionalities required by the application.

We argue that this selection can be partly automated using Feature Models (fms) combined with ontology engineering [START_REF] Gruber | A Translation Approach to Portable Ontology Specifications[END_REF]. Cloud variability can thus be described using fms and cloud resources specification, defined in this paper as dimensions, can be done using feature attributes extending the fm [START_REF] Benavides | Automated Reasoning on Feature Models[END_REF]. In addition, we propose to use ontologies to capture cloud knowledge and deal with the range of different terms used to define the same cloud concept among cloud providers. We give an overview of the SPLE application engineering process by explaining how cloud features are selected and dimensions specified. Therefore, we present an approach based on the combination of ontologies with fms to identify cloud or multi-cloud configurations whose functionalities and resources fit the application's technical requirements and their resource dimensions. The approach is implemented in a framework named Saloon, and we use as a running example the ApiSense platform, that contains up to 130 different configurations. Nonetheless, the approach proposed here is not specific to this application and can cover different domains.

The remainder of this paper is organized as follows. In Sec. 2, we discuss the motivation behind the presented approach and describe the challenges to tackle. In Sec. 3 we describe the approach and the way by which ontologies and fms can be combined to support cloud or multi-cloud configurations. Sec. 4 presents the implementation and the first results obtained from applying the approach. Finally, Sec. 5 compares our approach with close-related work in the literature and Sec. 6 concludes the paper.

MOTIVATIONS & CHALLENGES

In this section, we analyze the difficulties of selecting one or several clouds from application's requirements, we discuss the reasons that lead to select a multi-cloud configuration and we identify several related challenges. We then present ApiSense, a motivating example for our approach.

Selecting Among Cloud Providers

With the cloud computing paradigm, computing resources are delivered as services. Such a model is usually described as Anything as a Service (XaaS or *aaS), where anything is divided into layers from Infrastructure to Software including Platform. At IaaS level, configuring the cloud environment means configuring the whole software stack running inside the VM as well as the infrastructure concerns: number of VMs, bandwidth, input/output activities, number of nodes, of hard drives, database configuration, etc. Regarding platforms provided by PaaS clouds, the configuration part focuses on software that compose this platform: which application server(s), database(s), compilation tool, libraries, etc. In a multi-cloud configuration perspective, parts of the application can be deployed either at PaaS, IaaS or both levels. The wide range of cloud providers [START_REF] Cloudtimes | Cloud Computing Ecosystem[END_REF] likely to host the application makes the choice difficult, and there is a lack of visibility among them to select one that matches the application technical requirements. To fit these requirements and dimensions, we find several possibilities. First, in the case depicted by Fig. 1 a), the whole application is deployed on one given cloud. Second, a multi-cloud configuration can be used in case of b) privacy reasons, c) dimension reasons, in this case it's less expensive to store data on Cloud A or d) when a required element is not provided. To the best of our knowledge, no approach based on configuration making tool has been proposed up to now enabling fine-grained selection of the ideal cloud or multi-cloud configuration, or at least the most suitable with the application's technical and non-functional environment. Nowadays, this choice relies on cloud computing experts' knowledge and raises issues about reliability and exhaustiveness of such a knowledge [START_REF] Quinton | Leveraging Feature Models to Configure Virtual Appliances[END_REF]. The approach described in this paper is one solution to help the user identifying and selecting among cloud providers.

Challenges

This contribution aims at selecting a cloud or multi-cloud configuration for the application to be deployed and faces the following challenges: C1: Support clouds variability. The main difficulty is to deal with the wide range of clouds resources and functionalities at different layers to find clouds whose compatibility with the application's architecture and requirements is ensured.

C2: Support configuration dimensions. Among potential cloud providers identified with C1, a more accurate choice can be done by specifying resource dimensions related to the cloud configuration, e.g., database size.

C3: Support multi-cloud configurations. Challenges C1 and C2 can be applied on multi-cloud based applications to find a valid configuration distributed over several cloud providers.

Case Study

To illustrate our proposition, we introduce ApiSense, a configurable software platform for developing crowd-sourcing applications divided into two main components: a serverside infrastructure and a mobile phone application [START_REF] Haderer | A Preliminary Investigation of User Incentives to Leverage Crowdsensing Activities[END_REF]. A participant uses the mobile application to download experiments, execute them and upload the collected datasets on the server-side Java-based application, built as an assembly of services. Three of these services are mandatory. The Collector retrieves datasets uploaded by participants. The Publisher makes the experiment available to participants once defined by the scientist. Finally, the Export service extracts data in a computable format. Collected datasets are stored in a Database, either BaseX or MongoDB. The whole ApiSense fm represents up to 130 different configurations. Configuring it to be deployed in the cloud is a good way to avoid the server crashing when peak loads arise. Indeed, scientists cannot foresee how many participants are going to install their experiments on their mobile phones and send data to the server. In a multi-cloud configuration scenario, the ApiSense database and the services are deployed on different clouds. Another scenario could be the deployment of different services on several clouds (nodes).

PROPOSAL

To face the challenges identified in Sec. 2.2, we define a model-based approach used to (i) capture cloud providers' offer knowledge and (ii) bridge the gap between an application requirements and cloud providers available configurations. We propose in this contribution to combine ontologies and fms into a single solution that gives strong support to all stakeholders involved in cloud deployment. The approach allows its user to (i) define a technical requirements configuration for the cloud providers likely to host the application considering the application configuration and (ii) add resource dimensions to this configuration. Ontologies and fms form the core architecture of the approach (Fig. 2). We propose in a first step to tackle challenge C1 by (i) defining cloud providers fms, more precisely one fm per cloud provider and (ii) mapping cloud ontology Onto Cloud concepts to cloud providers fms' features. In a second step, we handle challenge C2 by proposing a dimension ontology OntoDim whose concepts represent resource dimensions and are mapped to cloud providers fms' attributes. At the end, the application configuration is mapped with each cloud provider fm, and each fm configuration validity is checked. Finally, challenge C3 can be tackled by combining several valid cloud configurations to fit the application's requirements.

The architecture distinguishes between two roles, the domain experts and the user. Cloud computing experts are involved in the domain description. They describe their cloud variability and commonality points, thus providing the corresponding fm to the architecture. They interact with other cloud experts to formalize the domain semantics and model the ontologies and they establish mapping between ontologies and fms. The users are all stakeholders involved in cloud deployment, such as an application developer, a software architect or even a cloud provider, e.g. to test its own SaaS. Using such an approach only requires to have necessary knowledge to properly configure the application's requirements.

Cloud Systems Variability Modelling

The architecture relies on two distinct parts, fms on one hand and ontologies on the other hand. fms define the commonalities and variabilities of cloud providers while ontologies represents the scope, i.e., the set of cloud providers. The definition of the commonality, the variability and the scope is part of the Domain Engineering process in a spl approach [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF]. A Feature Diagram (fd) (see Fig. 3 that depicts an excerpt fm of a cloud CloudA) consists of a hierarchy of features (typically a tree), which may be mandatory (commonality) or optional (variability) and may form Xor or Or-groups. Constraints, e.g., implies or excludes, can also be specified using propositional logic to express inter-feature dependencies. In the above example, the Tomcat application server is mandatory while the Balancer feature is optional. Configuring the CloudA to have more than one configured Tomcat implies such a cloud configuration to have a load Balancer. Such a relation is described as a constraint between features and is associated to the fd. We consider that a fm consists of a fd and the associated set of constraints.

In our approach, we defined a fm metamodel based on the concepts proposed in [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF]. We extend those concepts to include more information about features. First, we extend the fm with feature cardinalities [START_REF] Czarnecki | Formalizing Cardinality-based Feature Models and their Specialization[END_REF]. This kind of fms is said cardinality-based fms. A feature cardinality is an interval [m..n] with m as lower bound and n as upper bound of this interval. This interval determines the number of instances of the feature allowed in the product configuration. For example, one possible configuration of the F M CloudA allows up to 4 Tomcat instances. The second extension is done by adding attributes related to features, as proposed in [START_REF] Benavides | Automated Reasoning on Feature Models[END_REF]. These attributes are used to fill the lack of information in the basic fm notation. fms with additional information are called extended fms. As these proposals, we consider a feature attribute as a triplet <name, domain, value>. Thus, the CPU feature attribute in the F M CloudA specifies the frequency provided by this feature. Constraints related to fms can also be cardinality-based, as described by the card(Tomcat) > 1 → Balancer constraint: if the number of Tomcat instances is upper than one, then a load Balancer must be selected. By means of constraints, we assume that the resulting configuration is fully functional.

Ontologies

Each cloud fm differs syntactically and semantically from each other, since defined by different experts and representing different clouds. The heterogeneity of the different underlying clouds needs to be abstracted to model the domain knowledge and define the semantics of features and their relationships. This abstract model is defined using ontologies. In computer science, ontologies were first introduced by [START_REF] Gruber | A Translation Approach to Portable Ontology Specifications[END_REF] back in 1993. An ontology is "a formal, explicit specification of a shared conceptualization" [START_REF] Corcho | Ontological Engineering: Principles, Methods, Tools and Languages[END_REF]. They are used to describe the concepts and the relationships between these concepts, thus providing a vocabulary [START_REF] Gasevic | Model Driven Engineering and Ontology Development[END_REF] and a knowledge representation of a domain, here the cloud. We propose to use ontologies to semantically bridge the gap between the application's requirements and the architecture reasoning part, the fms. In our approach, we define two ontologies as depicted by Fig. 4 that conforms to an ontology metamodel we defined based on the concepts proposed in [START_REF] Corcho | Ontological Engineering: Principles, Methods, Tools and Languages[END_REF]. The first one, Onto Cloud , models technical requirements supported by cloud providers, e.g., application server or database, and the relationships between these concepts. The second ontology, OntoDim, describes the dimension properties the user can specify and associate to the technical requirements selected in Onto Cloud , e.g., database size or CPU frequency.

Mapping Ontologies with FMs

We define two kinds of mapping to link these two ontologies with the cloud providers' fms as depicted by Fig. 5. On the one hand, Onto Cloud Concepts are mapped to fms Features. Two syntactically different Features in different Feature Models can be semantically equivalent and thus mapped with the same Onto Cloud Concept. On the other hand, regarding OntoDim, Concepts are mapped to feature Attributes. More precisely, Concept's properties are mapped to feature Attributes the following way: (i) Property's domain name (i.e., Concept's name attribute) with Attribute's name, (ii) Property's value with Attribute's value and (iii) Property's range with Attribute's domain. These two mappings bridge the gap between application's requirements and the range of cloud fms.

Clouds Configuration & Selection

Thanks to the previously described mappings, the user makes only the selection of ontologies concepts and avoids a tedious and error-prone task involving the selection of features for each cloud provider's fm. The selection of a valid combination of features identified in the domain engineering process is part of the Application Engineering process [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF]. The user selects by hand among ontologies concepts those necessary for her/his application requirements. She/He also specifies related dimension's value when required. Let us now consider the following ApiSense configuration: conf1 = {Database, MongoDB, Collector, Publisher, Export}. Based on the description given in Sec. 2.3, the ApiSense architect defines the set of conf1 requirements as: req1 = [Java, MongoDB {capacity, real, 5}], the last number being the wished amount of GigaBytes, here given as an example. The Storage concept is selected and defines a property with the required information, MongoDB as domain, real as range and 5 as value. Once the concepts selection done, features are automatically selected in the different fms thanks to the mapping between ontologies and fms previously described: (i) Onto Cloud concepts are mapped with features and (ii) OntoDim concepts are mapped with feature attributes (roughly).

The Algo. 1 informally describes the process of feature selection for a given cloud provider fm. Running Algo. end for 12: end for with concepts related to req1 and F M CloudA as parameters results in the following F M CloudA configuration: [Database, MongoDB {capacity, real, 5}, Language, Java]. This feature selection process is applied on each cloud fm. The validity of a cloud configuration is then checked using related fms constraints.

Multi-Cloud Configurations

The previously described approach can be used in a multicloud configuration perspective and tackles challenge C3. Indeed, a fm configuration can be valid even if not fully covering application's requirements. In this case, it can be associated with another cloud fm valid configuration for a multi-cloud application to be deployed. Let us now consider the following [Java, MySQL] set of requirements req2. conf2 = [Language, Java] is a valid configuration for F M CloudA where CloudA supports Java-based application but does not provide the MySQL database. conf2 does not fulfill req2. Regarding Fig. 1 case d), there could be another CloudB providing the MySQL support. Thus, the multi-cloud configuration required to deploy the application is conf multi = {[Language, Java] CloudA , [Database, MySQL] CloudB } with [Language, Java] and [Database, MySQL] valid configurations for CloudA and CloudB respectively.

In this section, we described how our approach is used to deal with cloud variability and provide valid cloud configurations. It faces challenges C1 and C2 by defining a mapping between ontologies concepts and features and/or feature attributes. Challenge C3 can be tackled the same way by combining several configurations obtained from handling C1 and C2. Each fm configuration validity is then checked to determine wether the corresponding cloud(s) fits user's technical requirements and resources dimensions choices or not.

PRELIMINARY VALIDATION

In this section, we present the details of the Saloon framework we developed to implement the approach described in Sec. 3, as well as the results obtained from first experimentations we led to handle the challenges identified in Sec. 2.2.

Implementation

Regarding the implementation, the Saloon framework relies on Eclipse Modeling Framework (EMF) 1 metamodels, which is one of the most widely accepted metamodeling technologies. Each metamodel is described as an ecore file and allows us to create a dynamic instance as XMI model. These models represent either an ontology, either a fm or even a mapping model. During the cloud fms configuration process, ontology models are loaded and the user selects the required concepts. Then, mapping and fms models are loaded. The former is used while looping on the latter ones to select the corresponding features. This choice brings high flexibility to the Saloon framework. Indeed, one can target a new cloud provider by adding corresponding fm model that conforms to the fm metamodel. Once features are selected, fms are translated to propositional logic and constraints are loaded and checked against each cloud fm. The translation of fms to propositional logic is well known [START_REF] Mendonca | SAT-based Analysis of Feature Models is Easy[END_REF] and off-theshelf SAT solvers such as Sat4j [START_REF] Berre | The sat4j library, release 2.2[END_REF] can be used to check fms configuration validity.

Experimentation

To validate our approach, we used two different ApiSense configurations as Saloon inputs: conf1, described in the previous section and conf2 = [Database, MongoDB, Collector, Publisher, Export, DataAnalysis], where DataAnalysis is a PHP-based algorithm used to compute collected datasets. Regarding these configurations, the associated sets of requirements are req1 = [Java, MongoDB] and req2 = [Java, MongoDB, PHP] respectively. We ran Algo. 1 with four different PaaS fm describing Cloudbees2 , Cloud Foundry Cloudbees and dotCloud are the only PaaS to provide both Java and PHP support. As they also provide a configured environment to deploy a MongoDB instance, they cover entirely the application's requirements and are able to host the two ApiSense configurations corresponding to req1 and req2. Cloud Foundry does not provide a PHP support, and cannot be configured to host ApiSense in its conf2 configuration. Finally, Heroku can be configured to host Java-based applications, but only PostgreSQL database instances are provided. We then checked these results by deploying the two ApiSense configurations on the four real cloud PaaS named before. As described by Table . 1, we were able to deploy conf1 on Cloudbees, Cloud Foundry, dotCloud and conf2 on Cloudbees and dotCloud. Although successful, we achieved these deployments not without difficulty. Indeed, some modifications can be required before the application upload, e.g., setting a correct database connection URL.

Used as a multi-cloud configurator, Saloon proposes several solutions. One possibility, described in Table . 1, is to configure the MongoDB database on the Cloudbees cloud, that provides fully managed Databases-as-a-Service and in particular a large MongoDB instance with 5GB storage, while the rest of the application is hosted on Heroku.

RELATED WORK

Multi-Cloud & Configuration. Some recent works were proposed to deal with the problem of multi-cloud and configuration. In [START_REF] Sampaio | Uni4Cloud: An Approach based on Open Standards for Deployment and Management of Multi-cloud Applications[END_REF], the authors propose a model-based approach that helps to model, deploy and configure complex applications in multiple IaaS. The application to be deployed is modeled and configured as an OVF appliance to be run in VMs whereas we configure the cloud(s) likely to host the application considering its requirements. In [START_REF] Brandtzaeg | Towards a Domain-Specific Language to Deploy Applications in the Clouds[END_REF], a DSL is used to model the application to be deployed in the clouds while an interpreter is provided to identify which resources have to be used in the infrastructure to fulfill application's requirements. These authors pursue the same goal than us but they do not manage the cloud offer heterogeneity and can not check the validity of the obtained cloud configuration. Leusse et al. [START_REF] De Leusse | Towards governance of rule and policy driven components in distributed systems[END_REF] propose in their vision paper an architecture to facilitate the deployment of different components of a same application onto different clouds. They point out the lack of visibility among cloud providers that is one of the challenges we face in this paper. In [START_REF] Paraiso | A Federated Multi-cloud PaaS Infrastructure[END_REF], the authors present a federated multi-cloud PaaS infrastructure deployed on top of several existing IaaS/PaaS. This infrastructure is based on an open service model used to design both the multi-cloud PaaS and the SaaS applications running on top of it. Contrarily to our approach, they don't need to configure the multi-cloud platform since both SaaS and PaaS are implemented using the same service model.

Ontologies, FMs & Cloud. Several related work propose an ontology or fm-based approach to discover a cloud provider. In [START_REF] Kang | Cloudle: An Ontology Enhanced Cloud Service Search Engine[END_REF][START_REF] Dastjerdi | An Effective Architecture for Automated Appliance Management System Applying Ontology-Based Cloud Discovery[END_REF], ontologies are used to describe services available at IaaS and PaaS level. They both propose to reason on these ontologies to select one service that fits best user's requirements using similarity reasoning. Our approach goes in the same direction but add support to manage cloud heterogeneity and variability and check the configuration of several services thanks to fms. Other authors such as [START_REF] Quinton | Leveraging Feature Models to Configure Virtual Appliances[END_REF][START_REF] Dougherty | Model-driven Auto-scaling of Green Cloud Computing Infrastructure[END_REF] present an fm-based approach to select and manage software configurations and deploy virtual appliances on IaaS providers. They consider virtual appliances as spl products and rely on fms to describe and select configurations. Using this approach, one can not select among several clouds and only configure IaaS VMs. Cavalcante et al. propose an adaptation of the SPL-based development process to deploy their Health Watcher system [START_REF] Cavalcante | Exploiting Software Product Lines to Develop Cloud Computing Applications[END_REF]. Regarding the application to be deployed, they include in its fm "cloud features", e.g., Amazon S3 for the storage feature, that have been collected by studying applications already deployed in the cloud. Contrarily to our approach, they modify the original application fm and, in a way, they influence the cloud provider final choice. Moreover, they do not provide any means of selecting among several clouds. In [START_REF] Schroeter | Dynamic Configuration Management of Cloud-based Applications[END_REF], the authors propose an approach based on spl engineering to configure multi-tenant cloud applications. They rely on an ex-tended fm to describe functionalities and quality of services for the application to be deployed and plan to use in their future work an adaptive staged configuration process for reconfiguration of fm variants. A stakeholder for each cloud level (IaaS, PaaS, SaaS) selects features for its level. Cloud provider choice is thus limited to the IaaS/PaaS selected by the corresponding stakeholder.

CONCLUSION

Selecting a cloud provider to host its application leads to complex choices to deal with a wide range of resources at different levels of functionality among available cloud solutions, in particular when migrating services from one cloud to another and managing distributed applications spanning multiple clouds. In this paper, we proposed a model-driven approach implemented in the Saloon framework that uses feature models to represent clouds variability, as well as ontologies to describe the heterogeneous aspect of the cloud ecosystem. A semantic mapping is defined between ontologies concepts and fms features, that bridges the gap between application requirements and cloud providers configurations. This mapping is automated and avoids the Saloon user to select features for each cloud provider fm manually. By combining several valid cloud configurations, our approach supports multi-cloud configuration and thus faces the challenges identified in Sec. 2.2. As a preliminary validation, we used our framework on four cloud providers and showed that Saloon can be used to (i) check wether a cloud configuration is valid or not and (ii) if invalid, wether another cloud could be used in a multi-cloud configuration or not.

For future work, we plan to extend our approach to help the user in its configuration process by using previous configuration decisions as a feedback for quite equivalent application's requirements. We currently work on applying our approach as the entry point of a whole spl, adding assets composition and product generations steps to Saloon.

Figure 1 :

 1 Figure 1: Cases of multi-cloud configurations

Figure 2 :

 2 Figure 2: Approach overview

3. 1 . 1 Figure 3 :

 113 Figure 3: Excerpt of the CloudA FM (F M CloudA )

Figure 4 :

 4 Figure 4: Onto Cloud and OntoDim ontologies (excerpt)

Figure 5 :

 5 Figure 5: Example of mapping regarding F M CloudA

1

  Algorithm 1 conf igureF M (concepts, f m) Require: a set of Onto Cloud and OntoDim concepts Ensure: a f m configuration conf ig 1: for all Concept c in concepts do

	2:	for all Feature f in f m do
	3:	if findMapping(c, f ) then
	4:	select f
	5:	if c.properties = ∅ then
	6:	for all Property p in c.properties do
	7:	f.attribute ← p
	8:	end for
	9:	end if
	10:	end if
	11:

Table 1 :

 1 3 , dot-Cloud4 and Heroku 5 PaaS providers. Saloon gave us as output the results reported in Table.1. PaaS FM configuration using Saloon

	PaaS	Req. set Req. cover. Missing	Multi
	Cloudbees	req1 req2		--	MongoDB
	Cloud	req1		-
	Foundry	req2	×	PHP
	dotCloud	req1 req2		--
	Heroku	req1 req2	× ×	MongoDB MongoDB	Java

http://www.eclipse.org/modeling/emf/

http://www.cloudbees.com

http://www.cloudfoundry.com

https://www.dotcloud.com

http://www.heroku.com

Acknowledgments

This work is supported by Ministry of Higher Education and Research, Nord-Pas de Calais Regional Council, the FEDER through the Contrat de Plan Etat Region Campus Intelligence Ambiante (CPER CIA) 2007-2013 and the EU FP7 PaaSage project.