3.3 Mod´ elisation de syst` emes « self-healing »
3.3.6 Une infrastructure d’ex´ ecution pour les syst` emes « self-healing »
Wile et Egyed (2004);Wile (2002) proposent une infrastructure pour surveiller, in-
terpr´eter, analyser et reconfigurer les syst`emes en ex´ecution (figure 3.11). Une couche d’´el´ements appel´es Probes, qui rapportent donn´ees pertinentes, sont install´es avant de d´emarrer le syst`eme. D’autres ´el´ements appel´es Gauges traduisent et interpr`etent ces donn´ees, par rapport au mod`ele architectural du syst`eme, afin de rep´erer certains ´ev´enements cibles. Les donn´ees issues des Gauges sont transmissent `a travers le bus de Gauges o`u d’autres Gauges peuvent r´eagir ou prendre d´ecisions de contrˆole. Ensuite, les ´el´ements Effectors sont appel´es afin d’effectuer des changements sur le syst`eme.
Archite ctural Mod els Running System Controllers Gauges Probes Effectors Gauge Bus Probe Bus Collection Interpretation Decision & Display Adaptation & Configuration
Fig. 3.11 – Architecture de l’infrastructure pour l’ex´ecution de syst`emes « self-healing »,
Wile et Egyed (2004).
3.3.7
Une plate-forme pour le « self-healing » dans les services
Web
Gurguis et Zeid (2005) consid`erent une impl´ementation bas´ee sur une strat´egie de
« self-healing » appel´ee MAPEKephart et Chess(2003) propos´ee par IBM. La strat´egie MAPE est d´efinie par une boucle de contrˆole compos´ee de 4 phases int´egr´ees :
1. Dans la premi`ere phase, le composant Monitor collecte des donn´ees des ´el´ements contrˆol´es.
2. Dans la deuxi`eme ´etape, le composant Analyzer ´evalue les ´ev´enements rapport´es afin d’identifier la situation courante de l’´el´ement contrˆol´e. Ensuite, dans le cas de dysfonctionnement il propose des actions de r´eparation.
3. Dans la troisi`eme ´etape, le composant Planner sp´ecifie les actions ad´equates `a prendre pour sortir d’un ´etat de dysfonctionnement.
4. Et dans la derni`ere phase, le composant Executive ex´ecute les actions de r´eparation sur les ´el´ements contrˆol´es.
La proposition d’impl´ementation de la strat´egie MAPE est illustr´ee par la figure3.12. Pendant l’ex´ecution d’un service Web, des ´ev´enement correspondant au fonctionnement du service Web sont stock´es et class´es dans de registres CBE (Common Base Event). Un composant de diagnostic Diagnosis Engine analyse les donn´ees issues des services Web afin de reconnaˆıtre patterns pr´esents dans les registres et avec ceci identifier possibles fautes. Pour en faire, ce composant s’appui sur une base de donn´ees de symptˆomes et actions de r´eparation Symptoms Database. Une fois la faute et les actions de r´eparation rep´er´ees, un composant Rule Engine d´etermine la faisabilit´e d’application des actions de r´eparation en accord avec les politiques du syst`eme. Ceci est fait en se basant sur une base de donn´ees de politiques (Database Policies).
CBE Logs Functional WS X
Monitoring WS Diagnosis Engine Symptoms Database
Executing WS Rule Engine Policy Database
Functional WS X Approved
Solutions Suggested Solutions
1 2 3 4 5 6 7 8 Apply Action
Fig. 3.12 – Impl´ementation de la strat´egie MAPE pour le « self-healing » de services
Web, Gurguis et Zeid (2005).
3.4
Conclusion
Nous avons pr´esent´e dans ce chapitre diff´erentes approches pour l’adaptabilit´e des architectures. Nous reprendrons certaines id´ees de ces travaux pour nous inspirer et nous positionner dans le d´eveloppement de nos contributions, pr´esent´ees dans les prochains chapitres. En particuli`ere, nous adoptons les ´el´ements d’adaptabilit´e des architectures
pour sa description et sa reconfiguration. De mˆeme, les ´el´ements de « self-healing » sont pris en compte, afin de proposer des m´ecanismes de gestion de la QdS pour les appli- cations `a base de services Web.
Contributions
Cadre logiciel pour l’adaptation des
architectures
4.1
Introduction
Dans ce chapitre nous proposons une approche guid´ee par le mod`ele pour le d´eploie- ment et la reconfiguration des architectures `a base de services Web. Cette approche consid`ere un partitionnement explicite des aspects fonctionnels et non fonctionnels afin de mod´eliser une application d´efinie par des services Web coop´eratifs. Dans cette pers- pective, notre premi`ere d´emarche consiste `a repr´esenter les aspects fonctionnels des architectures. On cherche, en premi`ere instance, `a d´efinir une sp´ecification structurelle consid´erant la d´ecomposition fonctionnelle d’une application de services Web. Comme deuxi`eme instance, on consid`ere la gestion des actions de r´eparation, au niveau archi- tectural, au travers de la d´efinition et de l’application de r`egles de transformation.
Cette proposition vise d’une part les aspects statiques tels que la sp´ecification des architectures, et d’autre part, des aspects dynamiques par la d´efinition de r`egles de transformation et leur application `a la construction des actions de reconfiguration au niveau architectural. La figure4.1illustre les ´el´ements composant notre strat´egie. La vue conceptuelle consid`ere les aspects li´es au mod`ele, alors que la vue r´ealisation consid`ere les aspects techniques qu’impl´ementent chacune des parties des aspects conceptuels. Les sections d´evelopp´ees dans ce chapitre traitent chacun des aspects consid´er´es par les deux vues.