Prof Olivier Bonnaud
email: olivier.bonnaud@univ-rennes1.fr

Dr Hélène Frémont

Prof Jean-Marc Thiriet

On the way of harmonization of PhD in Europe in Electrical and Information Engineering: status and recommendations

Keywords: component; doctoral studies, mobility of PhD student in Europe, harmonization in the frame of Bologna process

In the frame of the thematic networks devoted to the development of LifeLong Learning (LLL) in Europe, the ELLEIEC project, more especially focused on Electrical and Information Engineering, the situation of PhD students in Europe was analyzed. Thanks to a questionnaire submitted to all the members of this network, an overview on 23 European countries was obtained. This paper tries to highlight the several aspects of the status and proposes recommendations in order to make easier the mobility and exchange in Europe at PhD level. The final part of this work is devoted to recommendations to the European partners in order to improve the present situation and to create a real European space for doctoral studies.

INTRODUCTION

Following the set-in of the doctoral studies in the frame of the Bologna process (B, M, D) [START_REF]The Bologna Declaration on the European space for higher education: an explanation[END_REF], the associated structures, called doctoral schools or post-graduate study departments depending on the countries, have now almost ten years of functioning for most of them. It is clear that the complete harmonization is not reached in Europe yet but in the field of Electrical and Information Engineering their missions and their evaluation criteria are now well established and discussed; these activities constituted a part of the work of previous networks, more especially THEIERE [START_REF]THEIERE Thematic Harmonisation in Electrical and Information EngineeRing in Europe[END_REF] and EIE-Surveyor [START_REF]EIE-Surveyor, reference point for electrical and information engineering in Europe[END_REF][START_REF] Thiriet | EIE-Surveyor: a new Thematic Network dedicated to competences and accreditation in Electrical and Information, Engineering, Oral communication[END_REF]. Even if some differences remain in the functioning and in the policy of the European academic institutions (European Higher Education institutions); similar activities are now well established and performed. In parallel, a Communiqué of the European Commission [START_REF]Towards the European Higher Education Area: responding to challenges in a globalised world[END_REF] established between the Ministries of Higher Education aims to encourage and develop the lifelong learning and the validation of professional experience through the European space.

On the basis of the first approach made in the frame of the final report of the EIE-Surveyor program [START_REF] Thiriet | Overview of Bologna Process Implementation in Europe In Electrical and Information Engineering[END_REF][START_REF] Bonnaud | New Trends of Doctoral Studies in Europe: Special Considerations for the Field of Electrical and Information Engineering[END_REF], and following a review on the doctoral studies in electrical and information engineering for the Bologna handbook [START_REF] Bonnaud | New challenges of doctoral studies in Europe in the field of electrical and information engineering[END_REF], this paper wants to highlight several weaknesses in the global harmonization at the doctoral level, following a survey based on a dedicated questionnaire analyzed in the frame of ELLEIEC network [START_REF]ELLEIEC: Enhancing Lifelong Learning for the Electrical and Information Engineering Community[END_REF]. Several aspects will be approached:

-organization of doctoral studies, -missions of doctoral schools, -administrative approach for the diploma delivery, -conditions of defense and diploma delivery -recognition in the European space -need of additional lectures; European credits, -validation and acceptance of the diploma by the socioeconomical world, -European extension of this approach in the frame of the ELLEIEC [START_REF]ELLEIEC: Enhancing Lifelong Learning for the Electrical and Information Engineering Community[END_REF] project and LLL (LifeLong Learning).

After a presentation of the context and after the development of the mentioned points, the aim of this paper is to give some suggestions towards a European Union harmonization of the Higher Education in order to foster the European mobility of doctors and researchers, with a real equivalence of PhD diploma through Europe, even if parts of these recommendations are already made by the European Commission.

II. COMMON APPROACH FOR DOCTRAL STUDIES

Whatever the differences that can remain within European Space, common approaches already exist for the doctoral studies. To prepare a doctorate, the student must reach a specific environment that allows developing new researches that include original approach, innovating applications, international recognition of the main results. After the doctorate diploma, the doctor must manage research activities that include several aspects as shown Fig. 1. The doctor may manage some technical experiences, create new tools, design and set-up new instruments, analyze the existing results in the international environment by a way of a deep bibliography, propose modeling and simulation involving recent tools, suggest innovating ideas, etc. However, this approach reduces the education of the doctorate to a scientific work, while several aspects are presently mandatory to well perform doctorate and to prepare the future doctor to his (her) future professional position.

In addition of this scientific environment and scientific work, the doctors must have gained and also proved several skills and competences, which would provide their future job in an academic institution or in a research organism, as well as in a department of Research and Development (R & D) of an industrial company. These skills and competences are summarized in Fig. 2. Discussions and comments were given in previous published studies [START_REF] Bonnaud | New Trends of Doctoral Studies in Europe: Special Considerations for the Field of Electrical and Information Engineering[END_REF][START_REF] Bonnaud | New challenges of doctoral studies in Europe in the field of electrical and information engineering[END_REF][START_REF] Bonnaud | Accreditation and functioning of French doctoral schools following the Bologna process in Electrical and Information Engineering, Oral communication[END_REF][START_REF] Bonnaud | Complementary formations of Doctorate in Electrical and Information Engineering: Internal Credits or ECTS? Oral communication[END_REF][START_REF] Bonnaud | Set-in LifeLong Learning for PhD students in Electrical and Information Engineering, Oral communication[END_REF]. However, it is important to notice that the main aim corresponds to the capability of the doctor to manage researches, not only thanks to scientific knowledge and knowhow, if possible close to excellence, but also to prove a very good knowledge of the economical and industrial environment, and a high intrinsic knowledge including languages and communication.

Although the students are severely selected at the entrance of doctorate studies by the doctoral schools (or post-graduate schools) and the associated research units, due to the permanent and very strong increasing of the general scientific level, some complementary knowledge and skills must be acquired during their studies [START_REF] Bonnaud | Complementary formations of Doctorate in Electrical and Information Engineering: Internal Credits or ECTS? Oral communication[END_REF]. Thus, one of the main roles of the doctoral school is to organize such additional education or training, to ensure the quality of the additional knowledge, or in other words the improvement of the global capabilities of the doctors [START_REF] Yahoui | ELLEIEC Project: A contribution to harmonise the European Higher Education Area[END_REF]. Fig. 2 summarizes the main skills and competences learnt and acquired by a doctor during the PhD preparation. The doctoral school [see for example 14] and the institution where the student is enrolled must ensure their skills and competences, with a large spectrum in order to cover all the aspects of their future job. The main question arisen at this stage is what is the situation in Europe? Is there some difference on recruitment of PhD students, on duration of the studies even though European recommendations already exist, on the condition of defenses, and on the application of LifeLong Learning European rules [START_REF] Thiriet | ELLEIEC implementation issues in EIE: State of advancement, Oral communication[END_REF][START_REF] Bonnaud | Obtenir un doctorat en EEA par la voie de la formation continue en Europe : les pistes[END_REF]? To try to answer to these questions, the task 4

Doctor

Simulation modeling skills

Management of experiences

Creation of new tools

Design and set-up of new instruments

Analysis of scientific results

Deep bibliography

Benchmarking of the world situation

Innovating ideas

Competences and skills of a doctor

Profond knowledge

Bibliography

Scientific behaviour

Research managing

Critical analysis

Work in a team

Team managing

Knowledge transfer

Research financing

working group of the ELLEIEC network [START_REF]ELLEIEC: Enhancing Lifelong Learning for the Electrical and Information Engineering Community[END_REF] set-up a survey and analyzed the results. The next section deals with this point.

III. RESULTS OF A SURVEY

In the frame of the ELLEIEC network, a survey dedicated to doctoral studies was set-up in order to evaluate the approaches developed in Europe for this purpose. Initially devoted to analyze the organization of LLL at this high level [START_REF] Thiriet | ELLEIEC implementation issues in EIE: State of advancement, Oral communication[END_REF][START_REF] Bonnaud | Obtenir un doctorat en EEA par la voie de la formation continue en Europe : les pistes[END_REF], the results given by the specific questionnaire was also able to highlight the following points:

-information about the target population, -admission process of doctoral students, -administrative situation of students in doctoral position, -organization of complementary lecture leading to credits, -requirement for defense of the PhD, -organization of defense. 27 partners of the network answered, representing 19 different European countries. This means that the results may be considered as significant.

Let us note that during the preparation of the questionnaire and brainstorming between the European partners of this network, the first major information that arose is the different interpretations of LLL at the doctoral level [START_REF] Bonnaud | Set-in LifeLong Learning for PhD students in Electrical and Information Engineering, Oral communication[END_REF][START_REF] Yahoui | ELLEIEC Project: A contribution to harmonise the European Higher Education Area[END_REF][14][START_REF] Thiriet | ELLEIEC implementation issues in EIE: State of advancement, Oral communication[END_REF][START_REF] Bonnaud | Obtenir un doctorat en EEA par la voie de la formation continue en Europe : les pistes[END_REF]. For many institutions in Europe the field of Electrical and Information Engineering, the doctorate position corresponds to a first professional experience or job and thus the diploma is considered as delivered in a LifeLong Learning frame. In several countries, the major part of the PhD students is considered in this situation because a significant part of the research work is performed in a company or in the frame of a joint program with industry.

Even though the definition of LLL can be a little bit different, including or not the APEL (accreditation of prior experiential learning) [START_REF] Bonnaud | Set-in LifeLong Learning for PhD students in Electrical and Information Engineering, Oral communication[END_REF], the final goal is the same for all the countries and institutions: the scientific quality of the results and thus the recognition of the PhD everywhere in Europe whatever the approach. Fig. 3 shows an example of the answers. In this case, the question was the requirement of the master diploma to get a PhD position in the institutions of your countries. Depending of the countries, the recruitment can be made with or without the master diploma, the selection being processed by the advisers, the laboratories and the doctoral schools. One fourth countries enroll students without the master diploma, but in continuation of the master studies. Whatever the local rules, the first objective is to recruit good applicants. We can notice than more and more of the candidates in the field of Electrical and Information Engineering are coming from outside Europe. This is a consequence of the observed decreasing since more than ten years of the attractiveness of scientific studies (physics, chemistry, electronics, electrical engineering, etc.) in more and more European countries. We have detected that some doctoral schools (or postgraduate study departments) could have now more than fifty per cent of PhD students coming from outside Europe [START_REF] Thiriet | ELLEIEC implementation issues in EIE: State of advancement, Oral communication[END_REF].

In addition we may notice that to recruit PhD students, previous research experience is not mandatory if the master is mandatory. The experience becomes mandatory in the contrary. Because the majority of masters include research activities in Europe, usually in the frame of an internship either in a research laboratory or in R &D department of a company, this means a mandatory research experience before in all cases.

A major part of the students receive a grant, a scholarship or a financial support based on contracts with industry or with the academic institution. Some of them have a temporary position in the university as assistant professor. In some institutions, the PhD students are enrolled only after they have found by themselves a financial support for the duration of the thesis. More than ten percent have a scholarship supported by their origin country (outside of Europe, such as Brazil, China, Vietnam, Middle East countries). As a conclusion, almost all the PhD students have some financial resources to ensure the minimum daily expenses of life. Let us notice that it is not the same situation for the PhD students in Human Sciences; in average, fifty per cent have no financial support during their thesis.

The duration of the thesis is at least three years, following by this way the European recommendations (see Communiqués [START_REF]Towards the European Higher Education Area: responding to challenges in a globalised world[END_REF]). However, the average duration of the thesis is in practice, close to four years. One of the reasons is the parallel activities of the PhD students: some of them are teaching; others are producing some professional activities linked to the industry. The additional lectures useful for professional purpose lead also to an increase of the duration. The last major reason is due to the long process for publication by the international journals; indeed, the reviewing procedure can take several months and for some prestigious journals more than one year. Some institutions impose the effective acceptation for publication that frequently postpones the date of the defense.

We have detected no significant difference on the requirements for the defense, and attribution of the diploma. In each case, recognition by the international scientific community via the publication in journals or in major prestigious conferences is needed even if the number of items can vary from one institution to another; the average is two major items in the analyzed data.

The composition of the jury varies from one country to the other. Fig. 4 shows the variation of the composition of the final jury. Reports, before and/or after defense, are requested in the wide majority of cases. A strong majority requires two or more reviewers for the final evaluation of the work. In almost all cases, the complementary credits are needed. For some countries, credits are delivered similarly to ECTS at bachelor and master levels. In other countries, a supplement to diploma is produced; this document details the lectures attended by the doctor during the preparation of the thesis.

To summarize, some minor differences between European countries remain but the main goal to ensure a high quality of the research activities is globally respected everywhere. In order to decrease the remaining differences, the team group of the network has emitted some suggestions and recommendations.

IV. RECOMMENDATIONS

All the partners agree with the need to take care of the scientific quality of the research whatever the path. This good behaviour must be followed in all the new procedures.

The organization of the defense with some specific local requirements is built to get the same diploma that can be recognized everywhere in Europe and elsewhere. At the end, there should be no difference, the diploma is unique. However, the choice of two reviewers for each defense should be a good way to have comparable evaluations.

Even if the institutions in Europe are more and more free about their own organization and on the delivery of their diplomas, the Bologna process and the related recommendations via several Communiqués [START_REF]Towards the European Higher Education Area: responding to challenges in a globalised world[END_REF] must be considered. The attributed freedom must also ensure a high quality of the diploma.

During the preparation of Doctorate, almost all the institutions propose to organize some additional courses that are mainly oriented to an improvement of the scientific skills and competences of the future doctors. These courses include summer schools, winter schools, and high level seminars, in very specialized fields. These courses may lead to the delivery of credits that can be available for all the European Institutions. There are not really ECTS because in many countries there are not credits required to deliver the diploma but they can appear in the diploma supplement, a paper that is validated by the graduate school or doctoral school and the scholarship office of the institution where the student is enrolled. Maybe a European harmonization could consist to create a credit reference for all the PhD. The European institutions if possible with the support of the European Commission should continue to organize at least annually, some seminars of reflection on the policy about doctoral preparation in order to adapt the procedure with the very fast evolution of the environment. ELLEIEC network has enough experience to confirm this general interest. EAEEIE European association [17] can play the role of European reference in this domain. A European financial support to the EAEEIE association allowing a continuation of ELLEIEC network should be a good way to perpetuate the efforts.

V. CONCLUSION

This mentioned thinking is a starting point for European harmonization of doctorate studies in the frame of Electrical and Information Engineering. Of course, the first objective is to ensure quality of the doctoral studies in such a field. This means a high level of competencies in a dedicated domain. The doctoral studies as well as the institution that delivers the doctorate are now evaluated. In France the new Evaluation Agency [START_REF]The new French Agency for Assessment of Research (AERES) is now operational[END_REF] is expected to evaluate the doctoral schools and the research units, each five years. The criteria of the evaluation include the quality, the organization of the validation of complementary courses and probably in a short future the capability to develop a procedure of lifelong learning at this higher education level.

We have made some suggestions in order to minimize the difference, mainly on the possible appreciation of international evaluation. Of course, if some differences will remain, the most important point will be to ensure a quality of the diploma with an international recognition, everywhere in the world.

Figure 1 .

 1 Figure 1. Main activities of a doctor. The doctor is able to manage research activities whatever the professionnal environment. The main skills and competences are displayed in this figure.

Figure 2 .

 2 Figure 2. Required skills and competences at the Doctoral level[START_REF] Bonnaud | Accreditation and functioning of French doctoral schools following the Bologna process in Electrical and Information Engineering, Oral communication[END_REF]. Whatever the way to obtain the doctorate these skills and competences should be reached by the doctor.

Figure 3 .

 3 Figure 3. Exemple of results extracted for the questionnaire. The presented answers concern the requirement of the master diploma to acceed to PhD position. In this example, Germany and Malta institutions do not require the master diploma.

Figure 4 .

 4 Figure 4. Number of reviewers in the final jury for the defense of PhD. A strong majority requires two or more reviewers for the final evaluation of the work.

ACKNOWLEDGMENT

The authors would like to thank all the active partners of EIE-Surveyor and ELLEIEC networks and the member of EAEEIE association that were involved in the workshops related to doctoral studies, for their fruitful discussions and for their answer to the questionnaire.

I.

This work is supported by ELLEIEC project: Project number: 142814-LLP-1-2008-FR-ERASMUS-ENW.


Ikbel Guidara
email: iguidara@laas.fr

Nawal Guermouche

-Tarak Chaari
email: tarak.chaari@redcad.org

-Said Tazi
email: tazi@laas.fr

Towards a novel framework for handling multi-level SLA in cross-organizational enterprise collaboration

Keywords: Service level Agreement (SLA), SLAs composition, collaborative services, SLAs management

Towards a novel framework for handling multi-level SLA in cross-organizational enterprise collaboration

Ikbel Guidara, Nawal Guermouche, Tarak Chaari, Saïd Tazi

Introduction

Nowadays, enterprises are outsourcing their business applications to enable and automate cross-organization collaboration in order to create new value added services. In fact, the rapid globalization of business makes such inter-collaboration very necessary to handle complex business requirements. Opening organizational boundaries aims to promote building, integrating and maintaining large-scale business applications. New mechanisms of exchanges and collaborations to adapt process management to these new organizational models are needed. In this context, SLAs (Service Level Agreement) are becoming an essential tool to govern relationships between different involved partners (Theilmann et al.,10).

Intuitively, an SLA allows defining, in accurate and unambiguous manner, all the features related to requirements and agreements between involved organizations. It clearly spells out rights and obligations of involved parties under a common contract (Lamanna et al.,03). Many efforts have been spent on defining languages (e.g., WSLA (Keller et al.,03)) and tools to handle the life cycle of these SLAs starting from their specifications to their termination passing through their negotiation, validation and execution. These efforts consider simple client-provider patterns involving only the end client and the direct providers that will fulfil his requirements (Haq et al.,11). With the proliferation of service providers and with the growth of complexity of business needs, such patterns are very restrictive. Usually a composition of different service's partners, which can hold collaborative and competitive relationships, is inevitable to satisfy complex business requirements. With such configuration, apart from client-producer SLA pattern, there is a great need to define composite SLAs that can involve collaborative and competitive producer/consumer partners.

In this position paper, we are particularly interested in the problem of building and managing composite SLAs for collaborative-networked enterprises. In this context, it is crucial to define an expressive and rigorous SLA specification to clearly describe the consumer/provider features such as functional and nonfunctional requirements, offers, and priorities. Based on such SLA model, we intend to provide a framework to automatically and dynamically generate and manage multi-party SLAs composition. Generating and managing a composition of SLA in an automatic way is not a trivial task. Indeed, to fulfil such a goal, we need to define a complete chain that allows building complex SLAs, negotiating the incompliant requirements, selecting the most suitable composite SLA and finally validate the multi-party SLAs composition. Since we consider collaborative and competitive relationships, defining a negotiation step is relevant to reach a mutually acceptable agreement.

The remaining of this paper is organized as follows. Section 2 presents the background knowledge and related work. Section 3 introduces an overview of our framework for SLA composition and gives an idea about the different steps of our approach. We conclude this paper in section 4.

State of the art

Several efforts and languages have been proposed in the field of SLA management. In this section we focus on the existing work on the used languages to implement composite SLAs and the proposed frameworks to manage them. In (Keller et al.,03), the authors describe the language WSLA (Web Service Level Agreement) which defines three main components of an SLA: contract parties, service description and obligations (Service Level Objectives (SLOs) and action (guarantees). WS-Agreement (Pichot et al.,08) language allows the specification of the capabilities of service providers and the monitoring of SLA. These two languages don't allow the specification of multiple parties in the SLA. This is not suitable with the requirement of new enterprises collaboration in which multiple parties can collaborate together and share a global SLA.

In (Haq et al.,11) authors are interested in hierarchical SLAs aggregation and don't cater for collaboration capabilities between collaborative/competitive services. In (Blake et al.,07), the authors have highlighted the importance of SLAs composition associated with Web service workflow compositions. Their approach is limited to predefined aspects and measures and it considers only a single-level composition. Another work on SLA has been proposed in (Ludwig et al.,08) allowing dynamic management of SLAs in a service composition. As presented, producer-to-producer patterns are not taken into account. In (Winkler et al.,10), the authors propose an approach to automatically manage composite SLAs. They define a dependency model to validate and evaluate dependencies between SLAs. Despite that this work takes into account dependencies between different services in the composition, it doesn't allow generating SLAs composition. Comuzzi et al, (Comuzzi et al.,09) and Theilmann et al, (Theilmann et al.,10) propose multi-layer SLA management approach. The implemented SLA hierarchy captures dependencies between three layers: business layer, software layer and infrastructure layer. These two works focus on the translation of metrics from business layer to various lower layers and don't consider composite SLAs of multi-partners.

Comparing to existing works, our aim is to provide automatic SLA composition framework to build and manage multi-party SLAs composition in which several relationships can take place. In the next section, we discuss the related features of this framework.

SLA composition approach

The aim of this ongoing work is to provide a framework to generate the most suitable and efficient SLA composition to govern end-to-end functional and nonfunctional requirements of networked enterprises. To do so, the first important ingredient of such a framework is to define an SLA model to formalize all the related non-functional requirements associated to functional requirements. Based on this model, the next step consists in building and providing a global SLA based on composition, negotiation, selection and validation processes. This framework considers several kinds of relationships that can hold between different partners. For instance, in this ongoing work, we are considering an aircraft-building scenario in which multiple aerospace manufacturers must collaborate together to ensure the product provision throughout the production lifecycle (Figure 1). These partners have different roles and maintain different relationships. For example, some partners are affiliated with the main aircraft factory and other partners maintain a subcontracting business relationship. Each partner will provide parts of the product and may require other services from other partners. To fulfil the global aircraftbuilding objectives, it is mandatory to compose the suitable services and to generate the corresponding composite SLA which complies with functional and QoS requirements (Andrikopoulos et al., 10) during the aircraft construction.

In such setting, and as said previously, partners can maintain different relationships such as subcontracting relationships (e.g., Partner 2 and Partner 3 in Figure 1) or collaborative relationships (e.g., Partner 4 and Partner 5 in Figure 1).

Figure 1. Subcontracting and collaborative relationships

To summarize, our approach is built upon four steps: (1) definition of a rigorous model to specify all the necessary elements of SLA, such as offers, requirements, and priorities of each partner, (2) definition of SLA composition primitives, (3) definition of SLA negotiation process, and (4) selection of the most suitable SLA composition. Hereafter, we present each step.

Offers and requirements model of each partner

In the literature, involved parties in an SLA can play exactly one role: either consumer or producer. Based on this pattern, existing approaches aim at defining techniques to govern producer-consumer relationships. This is very restrictive and doesn't consider the case in which each party can play multiple roles. In fact, in inter-organizational enterprises, each party provides multiple services to other parties and consumes services from other parties. To cope with theses configurations, it is mandatory to define a flexible and efficient framework which considers multi-party SLA management where the involved partners can be producer, consumer, competitor, and/or collaborator at the same time. To reach this goal, the first basic step consists in providing a model to specify both requirements and offers of each party associated with important concepts such as those related to priorities and penalties.

As can be seen in Figure 1, in the model we distinguish two view parts: (1) producer view, and (2) consumer view. The producer view specifies what the partner can offer. This view is exposed to consumers and is hidden to producers. The consumer view states requirements that must be satisfied by other partners. It is hidden to customers and exposed to producers. We note that offers of each partner can be assigned to requirements. For instance, in Figure 1, to perform the required service "Aircraft construction", the partner 1 requires the service "Aircraft central part construction" from other partners.

Apart from offers and requirements, it is important to consider the concepts of requirement priority and negotiability. To capture the priority concept, our model relies on weights associated to requirements. A requirement with a highest weight must be satisfied in priority. These weights are required in the selection and the negotiation phases. Regarding the requirement/offer negotiability, it allows to state clearly if the requirement/offer can be negotiable or not.

Based on the model we define, our first goal consists in providing SLA composition process. This step is described below.

SLA composition

As discussed above, to satisfy given consumer requirements, SLA composition is required. With the proliferation of services, several possible SLA compositions can exist. We intend particularly to provide mechanisms to build composite SLA which matches the intended requirements. -Collaborative relations: which hold between partners offering different complementary services (e.g., partner 4, and partner 5) -Competitive relations: which hold between partners offering the same service (e.g., partner 3 and partner 5)

Back to the example depicted in

The composition process will provide composite SLAs that correspond to each possible service composition. In case there is no a composition that fully satisfies the given requirements, we aim to provide a multi-criteria approach to select a set of relevant possible SLA compositions, which will be the input of the negotiation process (see Section 3.3). The selection will be performed based on several parameters, such as priorities, arguments, and negotiability.

SLAs Negotiation Process

In SLA composition, it is necessary that end-to-end functional and associated non-functional parameters comply with the consumer expectations. As said previously, we look for the best SLA composition that covers all functional and nonfunctional requirements. If there is no SLA composition that satisfies all the consumer requirements, we adopt a multi-party SLA negotiation process. Automated SLA negotiation aims at resolving disagreements between collaborative parties in order to reach a mutual agreement. Several negotiation strategies can be considered such as the trade-off and the concession strategies (Yan et al., 07. Each party negotiates multiple requirements/offers with different partners giving different arguments (Rahwan et al.,03). Argument is an interesting concept in SLA management, and more particularly, in SLA negotiation step. It allows partners to improve and justify their offers and requirements. The most used argument types in the literature are: appeals, rewards and threats (Monteserin et al.,11). In our work, we propose to define classes of arguments to be used in the negotiation process which can be associated to the requirement's priority. More particularly, we aim to define appropriate arguments generation rules, negotiation techniques, protocols, and strategies.

SLAs Selection Process

The result of the previous step will be a set of negotiated SLA compositions. In this context, it is important to define selection mechanisms to choose the best and the most appropriate SLA composition. To do so, we plan to define functions and metrics to measure the relevance and utility of each composite SLA. This will allow comparing the different SLAs and choosing the appropriate one. The relevance and utility of each composite SLA will be characterized using several parameters to define decision-making mechanisms. Aggregation and logical patterns (Haq et al.,11) can be studied, enhanced, and integrated.

Conclusion

Usually, SLA is a bilateral contract between a consumer and a provider. Nowadays in business environments, multiple parties playing different roles must collaborate to fulfill complex requirements. Therefore, defining SLAs between each pair of consumer-provider participating in the collaboration is no longer suitable. In fact, multiple dependencies between producer's offers and requirements can arise. Therefore, we need to define mechanisms to build a multi-party composite SLA. In this paper, we presented the global overview of our ongoing work to handle these compositions in a novel SLA management framework. First, we aim to propose an SLA model to specify all the required features such as functional and non-functional parameters associated to several concepts such as priority and negotiability where partners can maintain different kind of relationships. This model is the input of the composition process whose goal is to build an SLA composition that fulfils every partner requirement. In case there is no an ideal SLA composition, we believe that we must enhance SLA composition lifecycle by a negotiation process. This latter will try to enforce agreements between the different partners. This negotiation should be done with a minimum human interaction due to the proliferation of partner's services and to the dynamic nature of business relationships. The automation of the negotiation process is a challenging problem and requires deeper investigations. In this context, we aim to propose a generic SLA composition and management framework. This framework relies on several phases which consist in modeling, composing, selecting, negotiating, and finally validating the generated multi-party composite SLA. In our ongoing work, we intend to define the corresponding techniques to implement these different phases.

Figure 1 .-

 1 For instance, we can see two possible SLA compositions: -Composition 1: Partner 1, Partner 2 and Partner 3 Composition 2: Partner 1, Partner 4 and Partner 5 These two compositions are competitive. In fact, two kinds of relations can hold between stakeholders:

Road Materials and Pavement Design. Volume X -No. X/2001

Road Materials and Pavement Design. Volume X -No. X/2001


Imen Tounsi
email: imen.tounsi@isimsf.rnu.tn

Mohamed Hadj Kacem
email: mohamed.hadjkacem@isimsf.rnu.tn

Ahmed Hadj Kacem
email: ahmed.hadjkacem@fsegs.rnu.tn

Khalil Drira
email: khalil@lass.fr

Modeling and renement SOA design patterns with Event-B method

Using design patterns has become increasingly popular. Most design patterns are proposed in an informal way, which can give rise to ambiguity and may lead to incorrect usage. Patterns, proposed by the SOA design pattern community, are described with an appropriate notation. So they require modeling with a standard notation and then formalization. In this paper, we propose a formal architecture-centric approach that aims rst to model message-oriented SOA design patterns with the SoaML standard language and second to formally specify these patterns at a high level of abstraction using the Event-B language. These two steps are performed before undertaking the eective coding of a design pattern providing correct by design solutions. Our approach is experimented through an example we present in this paper. We implemented our approach under the Rodin platform which we use to prove model consistency.

Introduction

The communication and the integration between heterogeneous applications are great challenges of computing science research works. Several researches have tried to solve them by various methods and technologies (message-oriented middleware, EAI, etc.). They have tried to bring a response to these problems but without leading to real decisive success. The stack of applications led to an unbearable situation. The lack of an ecient architectural solution led information systems to a deadlock with respect to trade requirements.

Service-oriented architectures (SOA) is a technology that oers a model and an opportunity to solve these problems [START_REF] Thomas | SOA Design Patterns (The Prentice Hall Service-Oriented Computing Series from Thomas Erl)[END_REF]. Nevertheless these architectures are subject to some quality attribute failures (e.g., reliability, availability, and performance problems). Design patterns, as proven solutions to specic problems, have been widely used to solve this weakness.

Most design patterns are proposed in an informal way that can raise ambiguity and may lead to incorrect usage. Patterns, proposed by the SOA design pattern community, are described with an appropriate notation [START_REF] Thomas | SOA Design Patterns (The Prentice Hall Service-Oriented Computing Series from Thomas Erl)[END_REF]. So they require modeling with a standard notation and then formalization. The intent of our approach is to model and formalize message-oriented SOA design patterns.

These two steps are performed before undertaking the eective coding of a design pattern, so that the pattern in question will be correct by construction. Our approach allows developers to reuse correct SOA design patterns, hence we can save eort on proving pattern correctness.

In this paper, we propose a formal architecture-centric approach. The key idea is to model SOA design patterns with the semi-formal Service oriented architecture Modeling Language (SoaML) and to formally specify these design patterns with the formal language Event-B. We illustrate our approach through an example. We proceed by modeling the Asynchronous Queuing" pattern proposed by the SOA design pattern community using the SoaML language. This modeling step is proposed in order to attribute a standard notation to SOA design patterns. Then we propose a formal specication of this design pattern using the Event-B formal language. We implement these specications under the Rodin platform which we use to prove model consistency. We provide both structural and behavioral features of SOA design patterns in the modeling phase as well as in the specication phase. Structural features of a design pattern are generally specied by assertions on the existence of types of components in the pattern. The conguration of the elements is also described, in terms of the static relationships between them. Behavioral features are dened by assertions on the temporal orders of the messages exchanged between the components. The rest of this paper is organized as follows. Section 2 gives background information of some concepts used in this paper. Section 3 discusses related work. Section 4 focuses on the modeling of the Asynchronous Queuing" pattern using the SoaML language. Section 5 describes how to formally specify an SOA design pattern using the Event-B language. Section 6 concludes and gives some perspectives of our work.

Basic Concepts

In this section, we provide some background information on the patterns, the SoaML modeling language [START_REF]Object Management Group. Service oriented architecture Modeling Language (SoaML)-Specication UML Prole and metamodel for services (UPMS)[END_REF] and the Event-B formal language [START_REF] Abrial | Modeling in Event-B: System and Software Engineering[END_REF].

Pattern

The concept of patterns is not new, the rst denition was announced by Alexander in 1977 in the eld of architecture of buildings and towns. He declares that: Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem" [START_REF] Alexander | A Pattern Language: Towns, Buildings, Construction[END_REF]. In the eld of information systems, a pattern is dened as a model that provides a proven solution to a common problem individually documented in a consistent format and usually as part of a larger collection [START_REF] Thomas | SOA Design Patterns (The Prentice Hall Service-Oriented Computing Series from Thomas Erl)[END_REF].

Patterns can be classied relatively to their level of abstraction into three categories: architectural patterns (or architectural styles) that provide the skeleton or template for the overall shape and the structure of software applications at a high-level design [START_REF] Gomaa | Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures (The Addison-Wesley Object Technology Series[END_REF], design patterns that encode a proven solution to a recurring design common problem of automated systems [START_REF] El-Boussaidi | A model-driven framework for representing and applying design patterns[END_REF][START_REF] Ramirez | Developing and applying design patterns for dynamically adaptive systems[END_REF], and implementation patterns that provide a solution to a given problem in programming [START_REF] Beck | Implementation Patterns[END_REF]. It is used to generate code.

Service oriented architecture Modeling Language (SoaML)

Service-Oriented Architecture is an architectural style for building systems based on interacting services. Each service exposes processes and behaviors through contracts, which are composed of messages at discoverable addresses called endpoints [START_REF] Bruno | SOA Patterns. MEAP (Manning Early Access Program)[END_REF]. SoaML [START_REF]Object Management Group. Service oriented architecture Modeling Language (SoaML)-Specication UML Prole and metamodel for services (UPMS)[END_REF] is a specication developed by the OMG that provides a standard way to architect and model SOA solutions. It consists of a UML prole and a meta-model that extends the UML 2.0 (Unied Modeling Language).

Event-B

Event-B is an evolution of B-Method developed by Jean-Raymond Abrial [START_REF] Abrial | Modeling in Event-B: System and Software Engineering[END_REF]. It is a formal modeling method for developing systems via stepwise renement, based on rst-order logic. The method is enhanced by its supporting Rodin Platform for analyzing and reasoning rigorously about Event-B models.

The Event-B modeling notation The basic concept in the Event-B develop- ment is the model. A model is made of two types of components: contexts and machines. A context describes the static part of a model, whereas a machine describes the dynamic behavior of a model. Machines and contexts can be interrelated: a machine can be refined by another one, a context can be extended by another one and a machine can see one or several contexts.

Each context has a name and other clauses:

"Extends": The current context can extend other ones by adding their names in this clause. The resulting context consists of the context itself and all constants and axioms of all extended ones. "Sets": Declares a new data type. To specify a set S with elements e1,...,en, we declare S as a set and e1,...,en as constants then we add the axiom partition(S , e1, ..., en) "Constants": Declares the various constants introduced in the context. Names of constants must be all distinct.

"Axioms": Denotes the type of the constants and the various predicates which the constants obey. It is a statement that is assumed to be true in the rest of the model and it consists of a label and a predicate.

Like a context, a machine has an identication name and several clauses. In the following, we present in detail the clauses that we will use: "Renes": The current machine can optionally rene another one by adding its name in this clause.

"Sees": Lists the contexts referenced by the machine in order to use sets and constants dened in them.

"Variables": Lists the variables introduced in this machine. They constitute the state of the machine. Their values are determined by an initialization and can be changed by events. "Invariants": Lists the predicates that should be true for every reachable state.

"Events": Lists the events that change the state of the model and assign new values to variables. Each event is composed of one or several guards grd and one or several actions act. The guard states the necessary condition under which an event may occur, and the action describes how the state variables evolve when the event occurs. An event can be represented by the following form:

Event Event Name when grd : Condition then act : Action end A relation is used to describe ways in which elements of two distinct sets are related. If A and B are two distinct sets, then R ∈ A ↔ B denotes the set of all relations between A and B . The domain of R is the set of elements in A related to something in B : dom(R). The range of R is the set of elements of B to which some element of A is related: ran(R). We also say that A and B are the source and target sets of R, respectively.

Given two elements a and b belonging to A and B respectively, we call ordered pair a to b, the pair having the rst element a (start element) and the last element b (arrival element). We note: a → b or (a ,b).

An important special case of relations are functions. A partial functions is a relation where each element of the domain is uniquely related to one element of the range. If A and B are two distinct sets, then A → B denotes the set of all partial functions between A and B .

Related work

This section surveys related researches to patterns used in the eld of software architecture. As it is represented in Figure 1, these researches can be classied into three axes according to their abstraction level. The rst axis deals with architectural patterns, the second axis deals with implementation patterns and the third axis deals with design patterns. Compared to architectural patterns, design patterns address smaller reusable designs such as the structure of subsystems within a system [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF]. In this paper, we focus only on the third axis since it belongs to our research activities. Enterprise Application Integration [START_REF] Woolf | Enterprise Integration Patterns -Designing, Building, and Deploying Messaging Solutions[END_REF] Service Oriented Architectures [START_REF] Thomas | SOA Design Patterns (The Prentice Hall Service-Oriented Computing Series from Thomas Erl)[END_REF] Fig.

Classication of Design Patterns

Researches connected to design patterns axis, are mainly classied into three branches of work according to their architectural style (Figure 2). Blazy et al. [START_REF] Blazy | Reuse of specication patterns with the b method[END_REF] propose an approach for specifying design patterns and how to reuse them formally. They use the B method to specify structural features of design patterns but they do not consider the specication of their behavioral features.

Among researches related to design patterns for Enterprise Application Integration, we present the work of Hohpe and Woolf. They have proposed a set of design patterns which are dealing with enterprise integration using messaging [START_REF] Woolf | Enterprise Integration Patterns -Designing, Building, and Deploying Messaging Solutions[END_REF]. These design patterns are represented with a visual notation using their appropriate notation. Hohpe and Woolf argue their choice by saying that there is no a comprehensive notation that is geared toward the description of all aspects of an integration solution. The Unied Modeling Language (UML) does not contain semantics to describe messaging solutions and the UML Prole for EAI enriches the semantics of collaboration diagrams to describe message ows between components but it does not capture all the patterns described in their pattern language.

To our knowledge, there is no research work that propose the formalization of enterprise integration design patterns and as examples they refer to Hohpe and Woolf patterns and to enterprise integration patterns in general.

In the branch of SOA design patterns, we nd out the work of Erl. Erl have proposed a set of design patterns for service-oriented architecture and serviceorientation [START_REF] Thomas | SOA Design Patterns (The Prentice Hall Service-Oriented Computing Series from Thomas Erl)[END_REF]. Each pattern is modeled with an appropriate notation represented in a symbol legend. These patterns are modeled without any formal specication.

In order to understand these patterns, the rst step is to form a knowledge on the pattern-related terminology and notation. In addition to the pattern notation, Erl proposes a set of specic pattern symbols used to represent a design pattern, a compound design pattern and a group of related design patterns. Erl argues his choice by saying that there is a lack of abstract denitions, architectural models, and vocabularies for SOA but there are several eorts underway by dierent standards and research organizations.

In our research work we are interested in SOA design patterns dened by Erl [START_REF] Thomas | SOA Design Patterns (The Prentice Hall Service-Oriented Computing Series from Thomas Erl)[END_REF]. Erl presents SOA design patterns with an appropriate notation because there is no a standard modeling notation for SOA, but now OMG announces the publication of a Service oriented architecture Modeling Language (SoaML), it is a specication for the UML Prole and a Meta-model for Services (UPMS). So, in our work, we propose to model SOA design patterns with the SoaML standard language and we focus on the structural and behavioral features of SOA design patterns. After the modeling step, we propose to specify SOA design patterns formally. We use the Event-B language, which is an extension to the B method, to dene both structural and behavioral features of design patterns.

In this paper we concentrate on a specic category of patterns called Service messaging patterns", it is a collection of patterns witch are message oriented. It is focused on inter-service message exchange, and provides design solutions for a wide range of messaging concerns. From this collection, we use the Asynchronous Queuing" pattern.

In conclusion, most proposed patterns are described using a combination of textual description and a graphical appropriate notations in order to make them easy to read and understand. However, using these descriptions makes patterns ambiguous and may lack details. There have been many researches that dene pattern specications using formal techniques but researches that model design patterns with semi-formal languages are few. We nd a number of approaches that formally specify dierent sorts of fetures of patterns: structural, behavioral, or both. We provide a modeling solution for describing SOA design patterns using a visual notation based on the graphical SoaML notation. Two main reasons lead to use SoaML for modeling these patterns. First, SoaML is a standard modeling language dened by OMG to describe service oriented architectures. Second, diagrams used in the SoaML language, allow to represent structural features as well as behavioral features of SOA design patterns.

To model an SOA architecture, we can represent many levels of description.

The highest level is described as a Services Architectures where participants are working together using services. Services Architectures is modeled using UML In this paper, we model the Asynchronous Queuing pattern proposed by Erl [START_REF] Thomas | SOA Design Patterns (The Prentice Hall Service-Oriented Computing Series from Thomas Erl)[END_REF]. This pattern is described in detail within the next section.

Asynchronous Queuing

Asynchronous Queuing pattern is an SOA design pattern for inter-service message exchange [START_REF] Thomas | SOA Design Patterns (The Prentice Hall Service-Oriented Computing Series from Thomas Erl)[END_REF]. It belongs to the category "Service Messaging Patterns". It establishes an intermediate queuing mechanism that enables asynchronous message exchanges and increases the reliability of message transmissions when service availability is uncertain.

The problem addressed by Asynchronous Queuing pattern is that when services interact synchronously, it can inhibit performance and compromise reliability when one of services cannot guarantee its availability to receive the message.

Synchronous message exchanges can impose processing overhead, because the service consumer needs to wait until it receives a response from its original request before proceeding to its next action. Responses can introduce latency by temporally locking both consumer and service.

The proposed solution by this pattern is to introduce an intermediate queuing technology into the architecture (Figure 3). The queue receives request messages sent by the ServiceA and then forwards them on behalf of the ServiceB. If the target service is unavailable, the queue acts as temporary storage and retains the message. It then periodically attempts retransmission. Similarly, if there is a response, it can be issued through the same queue that will forward it back to the ServiceA when it is available. While either ServiceA or ServiceB is processing message contents, the other can deactivate itself in order to minimize memory consumption.

Structural features of the Asynchronous Queueing pattern

In the structural modeling phase, we specify components of the pattern and their dependencies or connections in the Participant diagram (Figure 4) and we specify their interfaces and exchanged messages in the ServiceInterface and MessageType diagrams respectively (Figure 5). ServiceA, ServiceB and the Queue are dened as participants because they provide and use services. As shown in Figure 4, the ServiceB provides a ServiceX service used by the ServiceA and the Queue provides a storage service. We didn't represent the storage service provided by the Queue in order to concentrate principally on the communication between ServiceA and ServiceB and to not complicate the presented diagrams.

Request message

Participants provide capabilities through service ports typed by UML interfaces that dene their provided capabilities. Both ServiceA and ServiceB have a port typed with the ServiceX". The ServiceB is the provider of the Ser-viceX and has a Service port. The ServiceA is a consumer of the ServiceX and uses a Request port. We note that the ServiceB 's port provides the ProviderServiceX" interface and requires the OrderServiceX" interface.

Since the ServiceA uses a Request the conjugate interfaces are used, so the ServiceA's port provides the OrderServiceX" interfaces and uses the ProviderServiceX". Since they are conjugate, ports on ServiceA and ServiceB can be connected to enact the service. The Request port is preceded with a tilde (∼) to show that the conjugate type is being used. In this diagram, Ser-viceChannels are explicitly represented, they enables communication between the dierent participants.

Figure 5 shows a couple of MessageType that are used to dene the information exchanged between ServiceA (consumer) and ServiceB (provider). These MessageType are RequestMessage" and ResponseMessage", they will be used as types for operation parameters of the service interfaces. The ServiceA participant expresses its request for the serviceX" service using its request port. The type of this service port is the UML interface OrderServiceX". This interface has an operation ProcessServiceXOrder" and the type of parameter of this operation is the MessageType RequestMessage".

Behavioral features of the Asynchronous Queueing pattern

During a course of exchanging messages, the rst service (ServiceA) sends a request message to the second service (ServiceB ), at that time, its resources are locked and consumes memory. This message is intercepted and stored by an intermediary queue. ServiceB receives the message forwarded by the Queue and ServiceA releases its resources and memory. While ServiceB is processing the message, ServiceA consumes no resources. After completing its processing, ServiceB issues a response message back to ServiceA (this response is also received and stored by the intermediary Queue). ServiceA receives the response and completes the processing of the response while ServiceB is deactivated.

To specify behavioral features of design patterns we use the UML2.0 sequence diagram. As depicted in Figure 6, this diagram species the valid interactions between participants. In this section, we describe semantics of design patterns with the Event-B notation. In order to prove the correctness of the pattern specication we use the Rodin Platform.

As we have mentioned in section 2.3, contexts are used to model static properties of a model, so we specify structural features of design patterns with a context (AQC ). Whereas, with machines we model the dynamic properties, so we specify behavioral features of design patterns with machines. Our model is composed of three machines named respectively AQM 1, AQM 2 and AQM 3 (AQM denotes Asynchronous Queuing Machine). In the rst machine (AQM 1), we specify the pattern at a hight level of abstraction, i.e. we suppose that the communication happens only between ServiceA and ServiceB . In the second machine (AQM 2), we add the process function to the model. Finally, in the third machine(AQM 3),

we add the Queue and all its behavior to the model. We use the renement techniques to gradually introduce details and complexity into our model. Machines and context relationships are illustrated in Figure 7.

MACHINE AQM2

MACHINE AQM3

Refines Sees

Sees

MACHINE AQM1

CONTEXT AQC

Refines Sees

Behavioral features of SOA Design Patterns

In order to specify behavioral features of the pattern, we have three steps: in the rst step we specify the pattern with a machine at a hight level of abstraction. In the second step, we add more details to the rst machine by using the renement technique. In the third and the nal step we add all necessary details to the second machine by using the renement technique too.

Specifying the pattern at a high level of abstraction As already mentioned above, in the Asynchronous Queueing pattern there are three parties participating in it namely the ServiceA, the ServiceB and the Queue. In this rst machine AQM 1, we only specify the communication between ServiceA and ServiceB , i.e. the queue is completely transparent, meaning that neither ServiceA nor ServiceB may know that a queue was involved in the data exchange. So, the behavior is described as follows:

The ServiceA sends a RequestMessage to the ServiceB and then remains released from resources and memory (becomes unavailable).

When the ServiceB becomes available, it receives the RequestMessage and sends the ResponseMessage. The dynamic system can be seen in Figure 6. Sending the request starts when there is no messages sent and the ServiceA is available, then ServiceA sends the RequestMessage and becomes unavailable. Sending the response starts after the questioning phase (when the request message is sent) and when the ServiceB is available and then ServiceB sends the ResponseMessage and becomes also unavailable. This scenario is formalized by the following two events, namely This event is with a parameter of type Participant (represented in the clause any) and it has the functionality of modifying the availability of a participant. For this event, we use the function overriding operator (¡ -), this operator replaces existing mappings with new ones in the Dispo function, here we replace the availability of a service from FALSE to TRUE.

Event Activating Participant any

INVARIANTS

Process Function : Process ∈ Partcipant → MessageType

The AQM 2 machine events are now dened below. We keep the Sending Req event as it is, we add a new event Processing Req (rening skip), we add more details to the abstract event Sending Resp and the abstract event Receiving Resp is rened by the concrete event Processing Resp. This is illustrated in Figure 8.

Processing Req (Processing Request) event is triggered when the message is sent (grd1), not yet processed (grd2) and the ServiceB is available (grd3). In the action part, we add to the process function the pair ServiceB → The AQM 3 machine events are now dened below. We keep the Sending Req and the Sending Resp events as they are. We add four new events namely Storing Req, Transmissing Req, Storing Resp and Transmissing Resp.

These events are related to the Queue behavior. We add more details to the abstract events Processing Req and Processing Resp. This is illustrated in Figure 9. If a participant (ServiceA or ServiceB ) receives a message, the storage of this message in the queue becomes unnecessary, so, the only modication in the processing event is to empty the Queue.

Sending_Req

Proof obligations

The proof obligations dene what is to be proved to show the consistency of an Event-B model. They are automatically generated by the Rodin Platform. In this section, we give an overview about proof obligations belonging to our whole specication. Each proof obligation is identied by its label. The proof statistics belonging to our specication is given in Table 2.

Well-denedness of an axiom (axiomLabel/WD ): This proof obligation rule ensures that an axiom is Well-dened. In our model we have 14 well-denedness axiom proof obligations.

Well-denedness of a guard (guardLabel/WD ): This proof obligation rule ensures that a guard is Well-dened. Some expressions, especially function applications, may not be dened everywhere. For example, Dispo(ServiceB ) is only dened if ServiceB is in the domain of Dispo, i.e. ServiceB ∈ dom(Dispo).

In our model we have 7 well-denedness guard proof obligations. Table 2. Proof statistics

These proof obligation rules ensure that the specied SOA design pattern is correct by construction. Our approach allows developers to reuse correct SOA design patterns, hence can save eort on proving pattern correctness.

Conclusions

In this paper, we presented a formal architecture-centric approach supporting the modeling and the formalization of message-oriented SOA design patterns.

The modeling phase allows us to represent SOA design patterns with a graphical standard notation using the SoaML language proposed by the OMG. The formalization phase allows us to formally characterize both structural and behavioral features of these patterns at a high level of abstraction, so that they will be correct by construction. We implemented these specications under the Rodin platform. We outlined many categories of SOA design patterns. We illustrated our approach through a pattern example (Asynchronous Queuing pattern") under the "Service messaging patterns" category. Currently, we are working on generalizing our approach in order to examine the other categories and formally specifying pattern compositions. Currently, the passage from the SoaML modeling to the formal specication is done manually; in the future, we will work on automating this phase by using transformation rules.

  Fig. 1. Classication of Patterns Design Patterns

  Among researches related to design patterns for Object Oriented Architectures, we present the work of Gamma et al.. They have proposed a set of design patterns in the eld of object-oriented software design[START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF]. These patterns are described with graphical notations by using three diagrams based principally on the OMT (Object Modeling Technique) notation. These diagrams are the class diagram, the object diagram and the interaction diagram. For each design pattern, they include at least one class diagram and the other notations are used as needed to supplement the discussion.Several researches have proposed the formalization of object-oriented design patterns. Since the most famous one are those proposed by Gamma[START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF] (hereafter referred to as GoF), most researches refer to these patterns. Several approaches have been proposed in the literature, we quote: Zhu et al.[START_REF] Zhu | Laws of pattern composition[END_REF] specify design patterns and pattern composition formally. They specify 23 GoF patterns. Zhu et al. use the rst order logic induced from the abstract syntax of UML dened in GEBNF to dene both structural and behavioral features of design patterns. Taibi et al. [17, 18] develop a language called Balanced Pattern Specication Language (BPSL) to formally specify patterns, pattern composition and instances of patterns. This language is used as a formal basis to specify structural features of design patterns in the First-Order Logic (FOL) and behavioral features in the Temporal Logic of Action (TLA). Taibi et al. use as a case study the Observer-Mediator pattern composition proposed by GoF. Dong et al. [7, 6] focus on the structural and behavioral fetures of a design pattern component. They use the First-Order Logic theories to specify the struc-tural features of patterns by means of Object-Z and Temporal Logic of Action (TLA) to specify their behavioral features. As examples, they use GoF patterns. Kim et al. [14] present an approach to describe design patterns based on role concepts. First, they develop an initial role meta-model using an existing modeling framework, Eclipse Modeling Framework (EMF), then they transform the meta-model to Object-Z using model transformation techniques in order to specify structural features. Behavioral features of patterns are also specied using Object-Z and integrated in the pattern role models. Kim et al. also use GoF patterns as examples to represent their approach.

  collaborations diagram stereotyped ServicesArchitecture . The next level is described as Participants using UML class diagram stereotyped Participant . The Service Contract is at the middle of the SoaML set of SOA architecture constructs, it describes the services mentioned above and it is modeled using UML collaborations stereotyped ServiceContract . In the next level, we nd the specication of Interfaces and Message Types using respectively UML class diagram stereotyped ServiceInterface and UML class diagram stereotyped MessageType . For both the service contract and the interface levels we can specify behavioral features of services using any UML behavior (e.g sequence or activity diagrams).

Fig. 3 .

 3 Fig. 3. Asynchronous Queuing solution

Figure 5 Fig. 4 .

 54 Figure5depicts a ServiceB participant providing a serviceX" service. The type of the service port is the UML interface ProviderServiceX" that has the operation processServiceXProvider". This operation has a message style pa-

Fig. 6 .

 6 Fig. 5. ServiceInterface and MessageType diagrams

Fig. 7 .

 7 Fig. 7. Context and machines relationship

  Partcipant grd2 : P ∈ dom(Dispo) ∧ Dispo(P) = FALSE then act1 : Dispo := Dispo ¡-{P → TRUE } end First renement: Adding the message processing The second machine AQM 2 (concrete machine) renes the cited above AQM 1 machine (abstract machine) and uses the AQC context. In this machine we introduce the notion of processing messages. So we add a new variable named Process. This variable is specied with a partial function that relates a Participant to a MessageType indicating who participant is processing what message. Initially, the Process function is initialized to the empty set.

Fig. 8 .

 8 Fig. 8. Renement of AQM 1

grd3:

  RequestMessage ∈ ran(Process) grd4 : ResponseMessage ̸ ∈ ran(Send) For the event Processing Resp, it renes the event Receiving Resp by adding the action of processing the message. act2 : Process := Process ¡-{ServiceA → ResponseMessage} Second renement: Adding the storage service In the third machine (AQM 3), we introduce the behavior of the Queue, so as to complete all the behavior of the Asynchronous Queuing pattern. We add two new variables named respectively Store and Transmit. Store is specied with a relation that relates a Participant to a MessageType and we add an invariant that restrict the domain of this relation to only the Queue indicating that the queue is storing what message. Transmit is specied with a partial function that relates a Participant to a MessageType and we add an invariant that restrict the domain of this function to only the Queue indicating that the Queue is transmitting what message. Initially the Store relation and Transmit function are both initialized to the empty set. INVARIANTS Store Relation : Store ∈ Partcipant ↔ MessageType Store Dom Rest : dom(Store) = {Queue} ∨ Store = ∅ Transmit Function : Transmit ∈ Partcipant → MessageType Transmit Dom Rest : dom(Transmit) = {Queue} ∨ Transmit = ∅

  Invariant preservation proof obligation rule (invariantLabel/INV ): This proof obligation rule ensures that each invariant in a machine is preserved whenever variable values change by each event. In our model we have 19 invariant preservation proof obligations.

Table 1 .

 1 Table 1 is a recapitulation of related works that contains a comparison between the above-mentioned approaches and our approach. Summary table of related works 4 Modeling SOA design patterns with the SoaML language

	Approach Pattern model-ing Structural for-mal specica-tion Behavioral for-mal specica-tion	Object Oriented Design Patterns Gamma et al. 1995 Zhu et al. 2010 Taibi et al. 2006 Dong et al. 2007 Kim et al. 2009 OMT GoF (OMT) GoF (OMT) GoF (OMT) GoF (OMT) GEBNF (FOL) BPSL (FOL) Object Z (FOL) Object Z (FOL) GEBNF (FOL) BPSL (TLA) TLA Object Z (FOL)	Blazy et al. 2006 GoF (OMT) B Method	EAI Design Pat-terns Hope et al. 2003 Appropriate SOA Design Patterns Erl 2009 Ours 2012 Notation Appropriate SoaML Nota-tion Event-B Event-B

  When the ServiceA becomes available, it receives the ResponseMessage and then returns deactivated. Formally, we can use two variables to represent the state of the pattern: Dispo to denote the state of the participant either available or not, and Send to indicate who sends what message. The rst invariant Dispo Function species the availability feature of participants. This feature is specied with a partial function which is a special kind of relation (each domain element has at most one range element associated with it) i.e. the function Dispo relates Participants to a Boolean value indicating that it is either available or not. We use the partial function because a participant can't be available and not available at the same time. The second invariant, i.e. Send Relation, species what is the message sent and who is the sender. INVARIANTS Dispo Function : Dispo ∈ Partcipant → BOOL Send Relation : Send ∈ Partcipant ↔ MessageType Initially, ServiceA is available and ServiceB is not available and there are no messages sent, hence Send relation is initialized to the empty set.

INITIALISATION begin act1

:

Dispo := {ServiceA → TRUE , ServiceB → FALSE } act2 : Send := ∅ end

  Sending Req (Sending Request) and Sending Resp (Sending Response).After sending the response message and when the ServieA is available, receiving the response message becomes possible. After receiving the response, ServiceA becomes not available again. So, we assign the value FALSE to the ServiceA disponibility. Formally, this action is specied with the event Receiving Resp (Receiving Response).Each time when a service is unavailable and an event can't be triggered only if this service becomes available, we use a special event named Activating Participant.

	Event Receiving Resp when grd1 : ResponseMessage ∈ ran(Send) grd2 : ServiceA ∈ dom(Dispo) ∧ Dispo(ServiceA) = TRUE then act1 : Dispo(ServiceA) := FALSE end
	Event Sending Req when grd1 : Send = ∅ grd2 : ServiceA ∈ dom(Dispo) ∧ Dispo(ServiceA) = TRUE then act1 : Send := Send ∪ {ServiceA → RequestMessage} act2 : Dispo(ServiceA) := FALSE end
	Event Sending Resp when grd1 : RequestMessage ∈ ran(Send) grd2 : ServiceB ∈ dom(Dispo) ∧ Dispo(ServiceB) = TRUE then act1 : Send := Send ∪ {ServiceB → ResponseMessage} act2 : Dispo(ServiceB ) := FALSE end

  Due to space restrictions, we didn't represent the four new events in this paper. We present only Storing Req and Transmissing Req events, the other two events, Storing Resp and Transmissing Resp, are similar to them. The event Storing Req is triggered when the RequestMessage is sent and not yet processed and the ServiceB is available. When the message is stored, the Transmissing Req event can be triggered. FALSE grd4 : Stores = ∅ then act1 : Stores := Stores ∪ {Queue → RequestMessage} end Transmit := Transmit ¡-{Queue → RequestMessage} end

	Processing_Req	Processing_Resp
		refines		refines
	Processing_Req	Sending_Resp Processing_Resp
	Storing_Req		Storing_Resp
	Transmissing_Req	Transmissing_Resp
	refines	refines	refines	refines
	skip	skip	skip	skip
	Fig. 9. Renement of AQM 2
	Event Storing Req when grd1 : RequestMessage ∈ ran(Send)
	Event Transmissing Req when grd1 : RequestMessage ∈ ran(Stores) then act1 :

grd2 : RequestMessage ̸ ∈ ran(Process) grd3 : ServiceB ∈ dom(Dispo) ∧ Dispo(ServiceB ) =


Eugen Feller
email: eugen.feller@inria.fr

Christine Morin
email: christine.morin@inria.fr

Autonomous and Energy-Aware Management of Large-Scale Cloud Infrastructures

Keywords: Cloud Computing, Scalability, Self-Organization, Self-Healing, Consolidation, Ant Colony Optimization (ACO)

With the advent of cloud computing and the need for increasing amount of computing power, cloud infrastructure providers are now facilitating the deployment of large-scale data centers. In order to efficiently manage such environments three important properties have to be fulfilled by their resource management frameworks: (1) scalability; (2) autonomy (i.e. self-organization and healing); (3) energy-awareness. However, existing open-source cloud management stacks (e.g. Eucalyptus, Nimbus, OpenNebula, OpenStack) have a high degree of centralization and limited power management support.

In this context, this PhD thesis focuses on more scalable, autonomic, and energy-aware resource management frameworks for large-scale cloud infrastructures. Particularly, a novel virtual machine (VM) management system based on a self-organizing hierarchical architecture called Snooze is proposed. In order to conserve energy, Snooze automatically transitions idle servers into a low-power mode (e.g. suspend). To favor idle times the system integrates a nature-inspired VM consolidation algorithm based on the Ant Colony Optimization (ACO).

I. INTRODUCTION

Cloud computing has recently evolved as a new computing paradigm which promises virtually unlimited resources. Customers rent resources based on the pay-as-you-go model and thus are charged only for what they use. However, customers growing demands for computing power are now facilitating the cloud service providers (e.g. Rackspace) to deploy increasing amounts of large-scale data centers. Such environments do not only impose scalability and autonomy challenges on their management frameworks but also raise questions regarding their energy-efficiency [START_REF] Morin | Make it green: Cloud computing and its contribution to climate change[END_REF]. For instance, as of today Rackspace is hosting approximately 78,717 servers [START_REF]Hosting reports third quarter[END_REF].

Several open-source cloud projects have been started to provide alternative solutions to public Infrastructure-as-a-Service (IaaS) cloud providers. Examples of such cloud management frameworks include Eucalyptus [START_REF] Nurmi | The Eucalyptus open-source cloud-computing system[END_REF], Nimbus [START_REF] Keahey | Science Clouds: Early Experiences in Cloud Computing for Scientific Applications[END_REF], OpenNebula [START_REF] Milojicic | OpenNebula: A cloud management tool[END_REF], and OpenStack [START_REF]OpenStack: Open source cloud computing software[END_REF]. However, two main drawbacks exist which prevent these frameworks to efficiently manage current and future large-scale infrastructures: (1) high degree of centralization, and (2) limited support for advanced VM scheduling algorithms. While the former one leads to limited scalability and Single Point Of Failure (SPOF), the latter results in high energy costs due to resource underutilization.

In order to bridge this gap this PhD thesis proposes Snooze [START_REF] Feller | Snooze: A Scalable and Autonomic Virtual Machine Management Framework for Private Clouds[END_REF], a novel scalable, autonomic, and energy-aware VM management framework for private clouds. Contrary to existing works Snooze is based on a self-organizing hierarchical architecture and performs distributed VM management. Particularly, VM management is achieved by multiple managers, with each manager being in charge of a subset of nodes. In addition, fault tolerance is provided at all levels of the hierarchy. Finally, VM monitoring and live migration is integrated into the framework thus facilitating the development of advanced VM scheduling algorithms. Last but not least once idle, servers are automatically transitioned into the system administrator specified power-state (e.g. suspend) to save energy and are woken up when necessary upon new VM submission.

To favor idle times, VM consolidation can be used in order to concentrate VMs on as fewer nodes as possible. However, many of the existing consolidation approaches (e.g. [START_REF] Beloglazov | Adaptive threshold-based approach for energy-efficient consolidation of virtual machines in cloud data centers[END_REF]) adopt simple greedy algorithms such as variants of the First-Fit Decreasing (FFD) heuristic, which tend to waste a lot of resources [START_REF] Setzer | Decision support for virtual machine reassignments in enterprise data centers[END_REF] by presorting the VMs according to a single dimension (e.g. CPU). Moreover, they are known to be hard to distribute and thus have limited scalability. In this context this PhD thesis investigates distributed nature-inspired VM consolidation approaches to enhance scalability and proposes a novel VM consolidation algorithm [START_REF] Feller | Energy-aware ant colony based workload placement in clouds[END_REF] based on the Ant Colony Optimization (ACO) [START_REF] Dorigo | Ant algorithms for discrete optimization[END_REF].

The remainder of this article is organized as follows. Section II introduces the Snooze framework. Section III presents the ACO-based consolidation algorithm. Related work is discussed in Section IV. Section V closes this article with conclusions and future work.

II. SNOOZE: A SCALABLE AND AUTONOMIC VIRTUAL MACHINE MANAGEMENT FRAMEWORK

A. System Architecture Snooze is a VM management framework for large-scale clusters. Its architecture is shown in Figure 1. It is partitioned into three layers: physical, hierarchical, and client. At physical layer, machines are organized in a cluster, in which each node is controlled by a so-called Local Controller (LC).

A hierarchical layer allows to scale the system, and is composed of fault-tolerant components: Group Managers (GMs) and a Group Leader (GL). Each GM manages a subset of LCs and is in charge of the following tasks: (1) VM monitoring data reception from LCs, (2) Resource (i.e. CPU, memory and network utilization) demand estimation and VM scheduling, (3) energy management, and (4) sending resource management commands (e.g. start VM, suspend host) to the LCs.

LCs enforce VM and host management commands coming from the GM. Moreover, they detect local overload/underload anomaly situations and report them to the assigned GM.

There exists one GL which oversees the GMs, keeps aggregated GM resource summary information, assigns LCs to GMs and dispatches VM submission requests to the GMs. Note, that despite the lightweight VM dispatching decisions, scalability of the GL can be further improved with replication and a load balancing layer.

To support failure detection and self-organization, multicastbased heartbeat protocols are implemented at all levels of the hierarchy. Moreover, for performance and scalability reasons all system components have dedicated roles (e.g. GL and GMs do not host VMs).

A client layer provides the user interface which is implemented by a predefined number of replicated Entry Points (EPs) and queried by the clients to discover the current GL.

In order to provide simple yet flexible interfaces, system components are implemented as Java RESTful web services. Currently, a command line interface (CLI) is implemented on top of those services. It supports the VM management as well as live visualizing and exporting of the hierarchy organization.

B. Resource Monitoring and Demand Estimation

Monitoring is mandatory to take proper scheduling decisions and is performed at all layers of the system. At physical layer VMs are monitored and resource utilization information is periodically transferred to the GM by each LC. It is used by the GM in the process of VM resource demand estimation and scheduling.

At the hierarchical layer, each GM periodically sends aggregated resource monitoring information to the GL. This information includes the used and total capacity of the GM with the former being computed based on the estimated VM monitoring information of the LCs.

C. VM Scheduling

Scheduling decisions are taken at two-levels: GL and GM. At the GL level, VM to GM dispatching decisions are taken based on the GM resource summary information. For example, VMs could be dispatched to round robin fashion or load balanced across the GMs. Note that summary information is not sufficient to take exact dispatching decisions. For instance, when a client submits a VM requesting 2GB of memory and a GM reports 4GB available it does not necessary mean that the VM can be finally placed on this GM as its available memory could be distributed among multiple LCs (e.g. [START_REF] Keahey | Science Clouds: Early Experiences in Cloud Computing for Scientific Applications[END_REF] LCs with each 1GB of RAM). Consequently, a list of candidate GMs is provided by the dispatching policies. Based on this list, a linear search is performed by issuing VM placement requests to the GMs.

At the GM level, the actual VM scheduling decisions are taken. Therefore, four types of scheduling policies exist: placement, overload relocation, underload relocation, and finally reconfiguration. Policies of the former type (e.g. round robin or first-fit) are triggered event-based to place incoming VMs on LCs. Similarly, relocation policies are called when overload (resp. underload) events arrive from LCs and aims at moving VMs away from heavily (resp. lightly loaded) nodes. For example, in case of overload situation VMs must be relocated to a more lightly loaded node in order to mitigate performance degradation. Contrary, in case of underload, for energy saving reasons it is beneficial to move away VMs to moderately loaded LCs in order to create enough idle-time to transition the underutilized LCs into a lower power state (e.g. suspend).

Complementary to the event-based placement and relocation policies, reconfiguration policies can be specified which will be called periodically according to the system administrator specified interval to further optimize the VM placement of moderately loaded nodes. For example, a VM consolidation policy can be enabled to weekly optimize the VM placement by packing VMs on as few nodes as possible.

Note that depending on the implemented scheduling policy, scheduling decisions can be either based on resources within the scope of a single GM (i.e. centralized) or cover multiple GMs (i.e. distributed). It order to take full benefits of the system distributed policies are preferred (see Section III).

D. Self-Organization of the Hierarchy

The Snooze hierarchy self-organization works as follows. When a GM first attempts to join the system, a leader election algorithm is triggered in order to detect the current GL. Currently, our leader election scheme is built on top of the Apache ZooKeeper [START_REF] Hunt | ZooKeeper: wait-free coordination for internet-scale systems[END_REF] highly available and reliable coordination system. If a leader exists, the GM joins it and starts sending GM heartbeats. Otherwise, it becomes the new GL and starts sending GL heartbeats.

On the other hand, when a LC starts it has to join the hierarchy. Therefore, information about the current GL as well as the GM to be joined is required. In order to get GL information it listens for GL heartbeats. When a heartbeat arrives, it contacts the GL to get a GM assigned. Therefore, different LC to GM assignment policies can be enabled at the GL. For example, LCs could be assigned to GMs in round robin fashion or based on the current GM load situation (e.g. to least loaded GMs). Finally, the LC joins the assigned GM, and starts listening to GM heartbeats as well as sending own ones to its assigned GM.

E. Fault Tolerance

When a GL fails, its heartbeats are lost and the leader election procedure is restarted by one of the GMs. When an existing GM becomes the new leader it switches to GL mode and starts sending GL heartbeats. Other GMs receive the heartbeats and rejoin the new GL. LCs which were previously assigned to the failed GM fail to receive its GM heartbeats and rejoin the system.

When a GM fails, its heartbeats are lost and the managed LCs rejoin the hierarchy. Moreover, GM failures are detected by the GL based on missing heartbeats, and its contact information is gracefully removed in order to prevent new VMs from being scheduled on it.

When a LC fails, its heartbeats are lost and the GM in charge invalidates its contact information. Note, that in the event of a LC failure, VMs are also terminated. Hypervisors snapshot features can be used by LCs in order to periodically save VM states on stable storage on behalf of the GM. This will allow the GM to reschedule the failed VMs on its active LCs. Note, that coordinating groups of communicating VMs belonging to the same application is out of the scope of this work.

F. Evaluation

Snooze was evaluated on a 144 nodes cluster of the Grid'5000 experimentation testbed in France. Up to 500 VMs were submitted. The results [START_REF] Feller | Snooze: A Scalable and Autonomic Virtual Machine Management Framework for Private Clouds[END_REF] have shows that the fault tolerance features of the framework do not impact application performance. Moreover, negligible cost is involved in performing distributed VM management and the system remains highly scalable with increasing amounts of VMs and hosts.

III. ENERGY-AWARE VM MANAGEMENT

One important goal of Snooze is to provide energy-savings in IaaS clouds. Therefore, each GM integrates mechanisms to detect idle LCs and automatically transition them in a lowpower state (e.g. suspend) after a system administrator predefined idle-time threshold has been reached. Moreover, LCs are woken up by the GM in case either not enough capacity is available to handle incoming VM placement decisions or overload situations on the LCs occur.

To favor idle times, underload situations are detected by each LC and reported to the GM which then triggers the underload relocation algorithm. In addition, consolidation is performed periodically on the GMs in order to further optimize the placement of VMs on moderately loaded LCs.

A. ACO-based VM Consolidation

This PhD thesis proposes a novel nature-inspired VM consolidation algorithm [START_REF] Feller | Energy-aware ant colony based workload placement in clouds[END_REF]. The proposed algorithm is based on the ACO principles in which multiple agents (i.e. artificial ants) compute solutions probabilistically and simultaneously within multiple cycles. Thereby, they communicate indirectly by depositing a chemical substance called pheromone on each VM-LC pair within a pheromone matrix.

In each cycle the ants receive VMs, and start constructing local solutions (i.e. VM to LC assignments) by the use of a probabilistic decision rule which describes the desirability for an ant to choose a particular VM as the next one to pack in its current LC. This rule is based on the current pheromone concentration information on the VM-LC pair in the pheromone matrix and a heuristic information which guides the ants towards choosing VMs leading to better overall LC utilization. Hence, the higher the amount of pheromone and heuristic information is associated with an VM-LC pair, the higher the probability that it will be chosen.

At the end of each cycle, local solutions are compared and the one requiring the least number of LCs is saved as the new globally optimal solution. Afterwards, the pheromone matrix is updated to simulate pheromone evaporation and reinforce VM-LC pairs which belonged to the so-far best solution.

The stochastic nature of the algorithm allows it to explore a large number of potential solutions. Moreover, the algorithm is well suited for parallelization.

B. Evaluation

A centralized version of the algorithm was evaluated by simulation and compared with the well known FFD heuristic. Moreover, the CPLEX solver was used to compute the optimal solution.

Our results [START_REF] Feller | Energy-aware ant colony based workload placement in clouds[END_REF] have shown that compared to FFD, the ACO-based approach utilizes lower amounts of hosts and thus yields to superior average host utilization and energy gains. Thereby, on average 4.7% of hosts and 4.1% of energy were conserved (including energy spent into the computation). Moreover, the proposed algorithm achieves nearly optimal solutions (i.e. 1.1% deviation).

IV. RELATED WORK Several VM management systems such as Nimbus [START_REF] Keahey | Science Clouds: Early Experiences in Cloud Computing for Scientific Applications[END_REF], OpenNebula [START_REF] Milojicic | OpenNebula: A cloud management tool[END_REF], OpenStack [START_REF]OpenStack: Open source cloud computing software[END_REF], and Eucalyptus [START_REF] Nurmi | The Eucalyptus open-source cloud-computing system[END_REF] have been developed during the last years with the former three being centralized and non fault-tolerant. Moreover, to the best of our knowledge none of the mentioned systems offers dynamic VM relocation and reconfiguration support.

Eucalyptus is the open-source system closest to ours in terms of architecture. However, it does not include any selfhealing features and strictly distinguishes between cloud and cluster controllers (i.e. static hierarchy) while Snooze follows a more self-organizing approach in which each group manager (GM) is promoted to a group leader (GL) dynamically during the leader election procedure upon GL failure detection. In addition, cluster controllers in Eucalyptus are limited to simple static VM placement policies (i.e. greedy, round robin) and do not support VM live migration while Snooze supports advanced scheduling algorithms (i.e. relocation and reconfiguration) and ships with integrated live migration support.

Recently in [START_REF] Cornabas | A distributed and collaborative dynamic load balancer for virtual machine[END_REF] a more distributed peer-to-peer (P2P) based VM scheduling approach is introduced. However, this work is still in very early stages as it is limited to load balancing and no evaluation regarding its scalability and fault tolerance aspects is presented. Another VM management framework based on a P2P network of nodes is presented in [START_REF] Quesnel | Cooperative dynamic scheduling of virtual machines in distributed systems[END_REF]. The nodes are organized in a ring and scheduling is performed iteratively upon underload and overload events triggered by the nodes. However, neither the overhead of maintaining the ring structure nor the scalability and fault tolerance aspects are discussed. In both works only preliminary simulation-based results targeting the scheduling time are presented.

In contrast, nodes in Snooze are dynamically organized in a self-healing hierarchical architecture. This allows it to scale with an increasing number of nodes as well as to provide the required fault tolerance properties without the need to rely on P2P technology. In fact, our experimental results [START_REF] Feller | Snooze: A Scalable and Autonomic Virtual Machine Management Framework for Private Clouds[END_REF] show that our architecture is sufficient in order to provide scalability and fault tolerance properties for thousands of nodes.

Besides the existing VM management frameworks, more generic frameworks targeting scalability and fault tolerance issues in distributed systems have been proposed in the Particularly, the hierarchical layer of Snooze is inspired from the idea introduced in the Hasthi [START_REF] Perera | Enforcing user-defined management logic in large scale systems[END_REF] framework which takes a hierarchical self-stabilizing approach for managing largescale distributed systems. Contrary to Hasthi whose design is presented to be system agnostic and utilizes a distributed hash table (DHT) based P2P network, Snooze follows a simpler design and does not require the use of P2P technology. Moreover, it targets virtualized platforms and thus its design and implementation is driven by the platform specific objectives and issues. Finally, Snooze has a working implementation which was evaluated in a real environment.

V. CONCLUSIONS AND FUTURE WORK

This PhD research has introduced a novel scalable, autonomic, and energy-aware VM management framework called Snooze. Unlike the existing cloud management frameworks, Snooze utilizes a self-organizing hierarchical architecture and distributes the VM management tasks across multiple group managers (GMs), with each manager having only a subset of nodes (i.e. local controllers (LCs)). Moreover, fault tolerance is provided at all levels of the hierarchy. Consequently, the system is able to self-heal and continue its operation despite system component failures. Finally, VM monitoring and live migration are integrated into the framework thus allowing Snooze to detect and react to overload and underload situations as well as facilitating the development of VM reconfiguration algorithms (e.g. dynamic consolidation). Last but not least, when energy savings are enabled, idle servers are automatically transitioned into a lower power state (e.g. suspend) and woken up on demand.

In the future, we plan to make the system even more autonomic by removing the distinction between GMs and LCs. Consequently, the decisions when a node should play the role of GM or LC in the hierarchy will be taken by the framework instead of the system administrator upon configuration.

Another important contribution of this PhD thesis is a novel nature-inspired VM consolidation algorithm based on the Ant Colony Optimization (ACO). The proposed algorithm was implemented and experimentally validated in a centralized simulation environment. The first results have demonstrated that the ACO-based approach provides superior energy gains than traditional algorithms based on the evaluated First-Fit Decreasing (FFD) heuristic and achieves nearly optimal results.

In the future we plan to integrate the proposed algorithm in Snooze. Moreover, a distributed version of the algorithm will be developed and evaluated along with the energy-saving features of Snooze under realistic workloads. Ultimately, Snooze will be open-sourced under the GPL v2 license in Spring 2012.

VI. ACKNOWLEDGMENT

Fig. 1 .

 1 Fig. 1. System Architecture

This research is funded by the French Agence Nationale de la Recherche (ANR) project EcoGrappe under the contract number ANR-08-SEGI-000.