Dans ce chapitre, nous avons d´ecrit la conception et l’impl´ementation de FScript, un langage d´edi´e `a la sp´ecification et l’ex´ecution des reconfigurations architecturales dynamiques et consistantes d’applications Fractal. Les propri´et´es combin´ees du langage et de son impl´ementation offrent un certain nombre de garanties importantes concernant la consistance des reconfigurations appliqu´ees, qui permettent d’utiliser FScript pour modifier des applications sans craindre de les rendre inutilisables.
FPath, un sous-ensemble de FScript purement sans effet de bords a ´et´e d´ecrit s´epar´ement, car aussi bien au niveau de sa conception que de son impl´ementation, il a ´et´e cr´e´e pour pouvoir ˆetre utilis´e seul. Ce sous-langage permet, entre autres, de naviguer dans des architectures Fractal et de s´electionner des composants, interfaces ou attributs qui v´erifient certaines propri´et´es.
L’impl´ementation actuelle de FScript souffre de certaines limitations. Cependant, elle a ´et´e con¸cue sp´ecifiquement pour pouvoir ´evoluer sans modifier la s´emantique du langage lui-mˆeme.
7
En pratique, ´etat donn´ee notre impl´ementation actuelle, seules les contraintes m´etiers d´efinies grˆace `a l’interface contraints-controllerpeuvent ˆetre viol´ees au cours d’une reconfiguration.
Une des am´eliorations possibles serait l’ajout d’analyses, soit statiques sur le code d’une reconfigura- tion, soit semi-statiques au d´ebut d’une transaction de reconfiguration (au moment ou le ou les composants impliqu´es sont connus). De telles analyses permettraient de d´etecter `a l’avance certaines erreurs que l’im- pl´ementation actuelle ne d´etecte qu’apr`es coup. La mod´elisation sous-jacente `a FPath, qui repr´esente un ensemble de composants sous la forme d’un graphe, pourra sans doute servir de base `a la formalisation de FScript n´ecessaire `a la cr´eation de telles analyses.
Une autre limitation de l’impl´ementation actuelle est l’impossibilit´e d’ex´ecuter plusieurs reconfigura- tions en parall`ele. Or, dans de nombreux cas pratiques de telles reconfigurations ne se chevauchent pas, c’est-`a-dire que les ensembles de composants impliqu´es sont disjoints. Malheureusement, il est difficile, voire peut-ˆetre impossible, de pr´evoir `a l’avance si deux reconfigurations risquent de se chevaucher. Le verrou global utilis´e actuellement est un m´ecanisme `a grain beaucoup trop gros, et des m´ecanismes de verrou plus fin8 devraient permettre l’ex´ecution de reconfigurations parall`eles tout en conservant toutes
les propri´et´es de consistance, et en particulier l’isolation.
8
Chapitre 7
Politiques d’adaptation SAFRAN
Sommaire
7.1 Introduction . . . 129 7.2 Sp´ecification et d´etection d’´ev´enements . . . 131 7.2.1 Introduction . . . 131 7.2.2 Ev´enements primitifs . . . 133´ 7.2.3 Descripteurs d’´ev´enements composites . . . 137 7.2.4 Capture des occurrences . . . 138 7.3 Structure des politiques d’adaptation . . . 138 7.3.1 Introduction . . . 138 7.3.2 D´efinition de r`egles r´eactives . . . 139 7.3.3 D´efinition de politiques d’adaptation . . . 140 7.4 Mod`ele d’ex´ecution des politiques d’adaptation . . . 141 7.4.1 Introduction . . . 141 7.4.2 Cycle de vie des politiques . . . 141 7.4.3 Comportement individuel des politiques . . . 142 7.4.4 Interactions entre politiques d’un mˆeme composant . . . 144 7.4.5 Interactions entre composants adaptatifs . . . 146 7.5 Conclusion . . . 146
C
e chapitreCe langage constitue le cœur du syst`eme safran : il int`egre en un tout coh´erent l’ensemble desd´ecrit un langage d´edi´e pour la sp´ecification de politiques d’adaptation dynamique. contributions d´ecrites dans les chapitres pr´ec´edents afin de permettre la sp´ecification et l’int´egration dynamique de l’aspect d’adaptation dans les applications `a base de composants Fractal.7.1
Introduction
L’objectif principal de nos travaux est de rendre plus simple la cr´eation d’applications adaptatives. Pour cela, notre approche repose sur les choix suivants :
1. consid´erer l’adaptation dynamique comme un aspect, les politiques d’adaptation ´etant modularis´ees en dehors du code m´etier de l’application afin de pouvoir y ˆetre int´egr´ees dynamiquement ; 2. utiliser la programmation par composants, et plus sp´ecifiquement le mod`ele Fractal, pour la cons-
truction d’applications adaptables sur lesquelles les politiques d’adaptation peuvent se greffer ; 3. utiliser un langage d´edi´e pour la sp´ecification des politiques d’adaptation ;
Nous avons d´ej`a d´ecrit l’architecture g´en´erale du syst`eme safran qui impl´emente cette approche dans le chapitre 4. Cette architecture a ´et´e con¸cue de fa¸con modulaire, chacun de ses ´el´ements pouvant ˆetre r´eutilis´e dans d’autres applications. La figure 7.1 repr´esente les diff´erents ´el´ements qui constituent safran.
Fig.7.1 – Les diff´erents ´el´ements constituant le syst`eme safran.
Le mod`ele Fractal et les deux extensions que nous y avons ajout´ees ont ´et´e pr´esent´ees en d´etail dans les sections 4.2, 4.3.1 et 4.3.2. Le syst`eme d’observation et de d´etection des changements du contexte d’ex´ecution WildCAT a ´et´e d´ecrit dans le chapitre 5, et le langage d´edi´e FScript permettant de program- mer des reconfigurations dynamiques consistantes d’applications Fractal est quant `a lui pr´esent´e dans le chapitre 6. Enfin, nous avons aussi d´ecrit l’interface abstraite adaptation-controller (Section 4.4.1) con¸cue pour permettre d’attacher dynamiquement des politiques d’adaptation `a des composants Fractal afin de les rendre adaptatifs :
interface AdaptationController {
void attachFcPolicy(any policy) throws InvalidPolicyException; void detachFcPolicy(any policy) throws NoSuchPolicyException; any[] getFcPolicies();
}
Cette d´efinition abstraite n’indique pas le type concret des politiques utilis´ees, ni la fa¸con de les d´efinir, et encore moins leur mode d’ex´ecution.
Ce chapitre conclut donc notre pr´esentation de safran en d´ecrivant l’impl´ementation concr`ete de cette extension adaptation-controller, sous la forme d’un langage d´edi´e permettant de d´efinir des politiques d’adaptation. Le rˆole de ces politiques est d’impl´ementer les strat´egies d’adaptation `a appliquer aux composants d’une application afin de les rendre adaptatifs. Une fois d´efinies grˆace au langage safran1
d´ecrit dans ce chapitre, ces politiques pourront alors ˆetre utilis´ees avec le contrˆoleur Fractal ci-dessus, dont l’impl´ementation se chargera de leur ex´ecution.
´
Etant donn´ee la nature r´eactive du processus d’adaptation (cf. Section 4.4.2), nous avons choisi de structurer les politiques d’adaptation safran sous la forme de r`egles r´eactives inspir´ees du paradigme eca issu du domaine des bases de donn´ees actives [Dittrich et al., 1995; Collet, 1996]. Une politique d’adaptation safran est donc constitu´ee d’un ensemble de r`egles r´eactives, chacune constitu´ee de trois ´el´ements :
1. la sp´ecification du type d’´ev´enement (´eventuellement composite) qui active la r`egle lorsqu’il se produit ;
2. une condition (expression bool´eenne) servant de garde ;
1
3. une action de reconfiguration, ´eventuellement compos´ee d’une s´equence de plusieurs actions primi- tives parmi celles disponibles.
Les diff´erentes contributions pr´esent´ees dans les chapitres pr´ec´edents sont destin´ees `a impl´ementer les diff´erents ´el´ements des r`egles r´eactives :
– Le syst`eme WildCAT (Chapitre 5) est utilis´e pour d´etecter les ´ev´enements exog`enes (venant de l’ext´erieur de l’application) qui repr´esentent les ´evolutions du contexte d’ex´ecution.
– Le langage FPath (Section 6.3) est utilis´e pour exprimer les conditions qui servent de garde aux r`egles r´eactives.
– Enfin, la langage FScript (Section 6.4) est utilis´e pour exprimer les actions de reconfiguration et pour les ex´ecuter de fa¸con sˆure.
Ainsi, toutes les contributions d´ecrites jusqu’`a pr´esent trouvent leur place dans safran, chacune servant `
a impl´ementer une partie du langage d´edi´e aux politiques d’adaptation.
Dans ce chapitre, nous pr´esentons donc ce langage dans sa globalit´e, en nous concentrant sur les aspects qui n’ont pas encore ´et´e d´ecrits. Dans un premier temps, nous d´ecrivons comment sp´ecifier la partie E d’une r`egle r´eactive, qui indique le ou les ´ev´enements qui doivent la d´eclencher (Section 7.2). Les deux autres parties des r`egles ont d´ej`a ´et´e d´ecrites individuellement : FPath pour la condition C et FScript pour l’action A. Le reste du chapitre pr´esente donc les politiques d’adaptation dans leur globalit´e, en commen¸cant par les aspects syntaxiques et structuraux (Section 7.3) avant de pr´esenter leur mod`ele d’ex´ecution (Section 7.4).