Distribution de la gestion de l'adaptation dynamique

Pour distribuer la gestion de l'adaptation, notre approche permet de dénir une ar-chitecture d'un système d'adaptation composé d'un nombre arbitraire de composants de type  ContextManager  (multiplicité 1..*) et d'un nombre arbitraire de composants de type  AdaptationManager  (multiplicité 1..*). Le contrôle de l'adaptabilité d'une ap-plication distribuée résulte des activités des diérents gestionnaires qu'inclut le système d'adaptation (voir gure 4.9).

Modèle architectural pour la gestion distribuée de l'adaptation dynamique 61

MonitorItf

SubscribeItf NotifyItf ^SubscribeItf_{1 *}

1..* SubscribeItf 1..* <<type>> NotifyItf 1..* ^1..* 1..* _1..* MonitorItf <<type>>

ContextManager _{AdaptationManager}^<<type>>

ObserveItf MonitorItf 1..* ModifyItf ObserveItf 1..* ModifyItf 1 * ObserveItf 0..* ModifyItf 1..* 1.. 1 * <<type>> Component 1..* Component 

Figure 4.9  Modèle architectural pour une gestion distribuée d'adaptation

Gestionnaires de contexte et d'adaptation. La portée des activités de chaque ges-tionnaire du contexte est limitée à un environnement spécique (WLAN, un groupe de n÷uds voisins dans un réseau ad hoc...) ou à un ensemble particulier d'aspects contex-tuels (par exemple un gestionnaire de contexte pour chaque couche : application, réseau et système d'exploitation). En eet, plusieurs gestionnaires de contexte peuvent être utilisés surtout lorsque l'environnement d'exécution est fortement hétérogène et qu'un grand vo-lume d'informations contextuelles doit être géré. La gestion de contexte devient plus ecace puisque chacun d'eux est dédié à des aspects contextuels particuliers. En outre, l'échange d'informations de contexte (collecte des mesures et notication des changements) peut être limité à des sous-domaines réseau pour réduire le trac réseau et la latence.

Enn, un gestionnaire de contexte pouvant utiliser un nombre arbitraire de capteurs physiques ou logiques, une interface client de type  ObserveItf  a une multiplicité 1..*. Notre approche limite aussi la portée des activités de chaque gestionnaire d'adapta-tion à un sous-ensemble de composants de l'applicad'adapta-tion distribuée. Un sous-ensemble est constitué de composants qui collaborent pour assurer un ou plusieurs services spéciques et/ou sont placés proches géographiquement. La politique d'adaptation d'une application distribuée est décomposée en sous-politiques, chacune tient compte d'une partie limitée d'informations de contexte et elle est spécialisée pour adapter un sous-ensemble des com-posants de l'application. Par conséquent, chaque gestionnaire a un champ d'action limité et le comportement d'adaptation résulte des diérentes actions locales des diérents ges-tionnaires d'adaptation.

Chaque gestionnaire d'adaptation s'abonne à des événements auprès d'un ou plusieurs gestionnaires de contexte selon les composants qu'il adapte et les champs d'action de ces gestionnaires. Chaque gestionnaire de contexte notie les gestionnaires d'adaptation abon-nés des événements qui les concernent et répondent aux requêtes de consultation de contexte provenant des diérents gestionnaires d'adaptation. Pour cela, les interfaces client et ser-veur de type  MonitorItf ,  SubscribeItf  et  NotifyItf  ont une multiplicité 1..*.

62 Modèle d'architecture pour l'adaptation distribuée et coordonnée

Enn, un gestionnaire d'adaptation recongurant un nombre arbitraire de composants de l'application, l'interface client de type  ModifyItf  a une multiplicité 1..*.

<<component>> <<component>> 2 <<component>> gc1: Context Manager gc2: Context Manager <<component>> ga2: Adaptation Manager <<component>> ga3: Adaptation Manager <<component>> ga1 Adaptation

Manager Manager Manager

Manager <<component>> c1: Component <<component>> c2: Component <<component>> c3: Component <<component>>component c4: Component <<component>> c5: Component

node1 node2 node3

Figure 4.10  Exemple de distribution de la gestion d'adaptation dynamique La gure 4.10 montre un exemple d'une application et un ensemble d'instances de gestionnaires de contexte et d'adaptation qui lui sont associées an de la rendre auto-adaptable. L'application est composée de 5 composants répartis sur trois n÷uds, trois parmi eux sont observables et adaptables. Le système d'adaptation se constitue de 2 composants de type  ContextManager  et de 3 composants de type  AdaptationManager . Le gestionnaire de contexte gc1 et le gestionnaire d'adaptation ga1 sont associés seulement au composant adaptable c1 car il est placé loin géographiquement des autres composants de l'application. Les composants adaptables c2 et c3 sont placés sur deux machines distinctes et proches. Les aspects contextuels auxquels on s'intéresse pour ces deux composants sont similaires. Ainsi, on instancie un seul gestionnaire de contexte gc2 pour les gérer. On applique des politiques d'adaptation diérentes aux deux composants. Donc chacun est géré par un gestionnaire d'adaptation distinct (ga2 et ga3 ) hébergé sur la même machine que le composant qu'il adapte.

Coordination. Le modèle présenté permet de distribuer la gestion de l'adaptation dy-namique. Cependant certains composants de l'application peuvent être dépendants. Ainsi, certains scénarios d'adaptation nécessitent la coordination des activités des gestionnaires d'adaptation pour prendre des décisions de façon collective et pour recongurer des com-posants applicatifs de manière coordonnée. La coordination s'apparente aux interactions

Modèle architectural pour la gestion distribuée de l'adaptation dynamique 63

entre un groupe de gestionnaires d'adaptation pour coordonner leurs activités de prises de décisions et de contrôle des recongurations des diérents composants. Pour cela, les ges-tionnaires d'adaptation doivent intégrer des composants appropriés pour la coordination. Notre proposition pour gérer l'aspect coordination sera présentée dans le paragraphe 4.5.6.