Architecture de composants structurellement auto-adaptatifs

Pour réaliser l’auto-adaptation de sa structure, un composant doit être capable de prendre en compte son contexte d’exécution courant afin de générer une spécification de structure adaptée à la situation puis il doit pouvoir reconfigurer sa structure actuelle afin de se conformer à la spécification obtenue. Ainsi, un tel composant doit être structurellement et dynamiquement adaptable. De plus, il doit disposer de mécanismes pour l’automatisation des étapes de prises de décisions.

4.4.2.1 Les composants

Les composants de notre modèle de composants structurellement et dynamiquement auto-adaptatifs sont de deux types : des composants métiers (i.e. composants fournissant les services fonctionnels de l’application le contenant) issus de la fragmentation du composant initial et des composants non- fonctionnels (i.e. composants fournissant des services transversaux à toute application) tels que les com- posants de gestion de contexte ou d’adaptation.

Les composants métiers font référence aux composants primitifs de notre modèle de composants structurellement et dynamiquement adaptables. L’auto-adaptation structurelle d’un composant logiciel va donc consister à générer automatiquement des nouveaux composants par encapsulation de ses sous- composants existants et à redéployer les composants générés en fonction de son contexte d’utilisation. De ce fait, plus le composant aura une architecture fragmentée, plus les possibilités de reconfiguration seront grandes. Ainsi, par défaut, nous nous basons sur le modèle canonique prévoyant la réification des interfaces en composants métiers.

Par ailleurs, un composant structurellement auto-adaptable doit être doté de fonctionnalités lui per- mettant de réaliser automatiquement l’adaptation. Pour cela, nous avons introduit trois nouveaux sous- composants dans son architecture initiale (voir Figure 4.12) :

• un composant de gestion de contexte (GC)

D’une part, un composant auto-adaptatif doit être capable d’acquérir des informations sur sa struc- ture et son comportement. Les informations sur la structure du composant peuvent être obtenues

par l’intermédiaire d’interfaces spécifiques (non-fonctionnelles) permettant de réaliser de l’intros- pection sur le composant. Concernant les informations comportementales, elles peuvent être obte- nues par l’intermédiaire de connecteurs (CC) entre les composants métier (CM), chargés de col- lecter des informations sur les messages échangés entre composants tels que le nombre d’appels d’un service, etc.

Par ailleurs, il doit être capable de décrire les conditions d’utilisation de ses services. Ainsi, il doit être doté d’une interface appelée service de description (SD) connectée au gestionnaire de contexte, et permettant de décrire les services fournis par le composant. Chaque description doit contenir deux types d’informations : d’une part, la liste des ressources requises par le service pour fonctionner (i.e. contexte de déploiement) et d’autre part, les données relatives au profil de son utilisateur potentiel ainsi que les conditions d’utilisation (i.e. contexte d’exploitation). Les infor- mations sur le contexte de déploiement doivent être fournies par les concepteurs de services alors que celles liées au contexte d’exploitation sont spécifiques à l’application et donc doivent être ren- seignées par l’administrateur ou le concepteur de l’application. Ces informations sont représentées sous la forme de données (voir Figure 4.9).

1 <? xml v e r s i o n = " 1 . 0 " e n c o d i n g = " i s o−8859−1 " s t a n d a l o n e = " no " ? >

2 < !DOCTYPE c o m p o n e n t S t r u c t u r e SYSTEM " / S c o r p i o D a t a / x m l d t d s / c o n t e x t . d t d " > 3

4 < c o n t e x t name= " C o n t e x t 1 " > 5 < r e s o u r c e >

6 < s y s t e m >MAC OS< / s y s t e m > < cpu >450 < / cpu > 7 < / r e s o u r c e > 8 < u s e r > 9 <work> E n g i n e e r < / work> < l e v e l >2< / l e v e l > 10 < / u s e r > 11 < c o n d i t i o n > 12 < p o s i t i o n > 13 < l o n g i t u d e > 0 . 0 5 3 7 7 1 5 2 < / l o n g i t u d e > < l a t i t u d e > 0 . 8 7 9 4 0 8 7 5 2 < / l a t i t u d e > 14 < a l t i t u d e >200 < / a l t i t u d e > < a r e a > 100 < / a r e a > 15 < / p o s i t i o n > 16 < / c o n d i t i o n > 17 < / c o n t e x t >

Figure 4.9 – Exemple de description de services

D’autre part, le composant doit être capable d’acquérir des informations sur son contexte externe (i.e. contexte de déploiement et contexte d’exploitation). L’acquisition de ce type d’information est réalisée par l’intermédiaire de capteurs pouvant être matériels (GPS, etc.) ou logiciels (indicateur du niveau de batterie, etc.).

Les données ainsi recueillies doivent être interprétées, agrégées puis transmises au composant dé- cisionnel ;

• un composant décisionnel (CD)

Ce composant fournit des mécanismes de décisions permettant au composant adapté de déterminer une spécification de sa structure (voir Figure 4.10) qui soit adaptée au contexte courant. La spé- cification est en fait une description de la structure interne du composant résultat de l’adaptation en termes de sous-composants à générer : pour chaque sous-composant, doivent être spécifiés les primitifs qu’ils contiennent ainsi que leur site de déploiement.

1 <? xml v e r s i o n = " 1 . 0 " e n c o d i n g = " i s o−8859−1 " ?>

2 < !−− An XML DTD f o r S c o r p i o : a d a p t a t i o n S c r i p t . d t d −−>

3 < !−− Component a d a p t a t i o n s c r i p t −−>

4

5 < !ELEMENT c o m p o n e n t S t r u c t u r e ( com ponent∗ ) >

6 < !ELEMENT com ponent ( com ponent∗ , u−component ∗ ) >

7 < !ELEMENT u−component > 8 < !−− 9 c o m p o n e n t : n o u v e a u c o m p o s a n t à g é n é r e r p a r f r a g m e n t a t i o n 10 u−co m p o n en t : co m p o s a n t p r i m i t i f d o n t l e nom a é t é d é f i n i l o r s 11 de l a g é n é r a t i o n du c o m p o s a n t au f o r m a t c a n o n i q u e 12 −−! > 13 < ! ATTLIST c o m p o n e n t S t r u c t u r e 14 name CDATA #REQUIRED 15 >

16 < ! ATTLIST com ponent 17 name CDATA #REQUIRED 18 h o s t CDATA #IMPLIED 19 >

20 < ! ATTLIST u−component

21 name CDATA #REQUIRED 22 >

Figure 4.10 – Spécification de l’adaptation de composant logiciel

Exemple de l’agenda-partagé

Pour illustrer cette étape, considérons l’exemple du composant Agenda-partagé. Nous supposons que ce composant a été déployé sur un seul site. Imaginons que l’administrateur du composant sou- haite, pour des raisons de répartition des charges, distribuer ce composant de la manière suivante : (1) les services Agenda et MiseAjourAgenda seront fournis par un composant appelé Gestionnaire-

DAgenda et déployé sur site1, (2) les services Réunion et MiseAjourReunion seront fournis par un

composant appelé GestionnaireDeReunion et déployé sur site2 et enfin (3) les services Absence,

MiseAjourAbsence, Droit et MiseAjourDroit seront déployés sur un composant appelé Gestionnai- reDAbsence et déployé sur site3. De ce fait, les composants primitifs Agenda et MiseAjourAgenda

doivent être encapsulés dans un composant appelé GestionnaireDAgenda et déployé sur site1, etc. La spécification de l’adaptation permettant d’obtenir cette nouvelle architecture du composant

Agenda-partagé est donné dans la figure 4.11.

Pour plus de détails sur la génération automatique de cette spécification, nous invitons le lecteur à consulter la section 4.5.2 ;

• un composant d’adaptation (CA)

Une fois que la spécification du résultat de l’adaptation a été générée, le composant doit automa- tiquement reconfigurer sa structure et redéployer certains de ses sous-composants si nécessaire. Ces opérations sont réalisées respectivement par le composant de reconfiguration et le composant de redéploiement. Par ailleurs, le composant de redéploiement exige que chaque « composant in- terface » soit doté d’une interface de gestion d’état permettant de sauvegarder et de charger l’état

d’un composant2. Nous considérons l’état d’un composant logiciel comme l’ensemble des états

des ressources logicielles qu’il utilise.

2

1 <? xml v e r s i o n = " 1 . 0 " e n c o d i n g = " i s o−8859−1 " s t a n d a l o n e = " no " ? >

2 < !DOCTYPE c o m p o n e n t S t r u c t u r e SYSTEM " / S c o r p i o D a t a / x m l d t d s / a d a p t a t i o n S c r i p t . d t d " > 3

4 < c o m p o n e n t S t r u c t u r e name= " Agenda−p a r t a g e " >

5 < com ponent name= " G e s t i o n n a i r e D A g e n d a " h o s t = " s i t e 1 " > 6 <u−component name= " Agenda " / >

7 <u−component name= " MiseAjourAg en da " / >

8 < / com ponent >

9 < com ponent name= " G e s t i o n n a i r e D e R e u n i o n " h o s t = " s i t e 2 " > 10 <u−component name= " R eu n io n " / >

11 <u−component name= " M is eA jo u r R eu n i o n " / >

12 < / com ponent >

13 < com ponent name= " G e s t i o n n a i r e D A b s e n c e " h o s t = " s i t e 3 " > 14 <u−component name= " Absence " / >

15 <u−component name= " M is eA jo u r A b s en ce " / >

16 < / com ponent >

17 < / c o m p o n e n t S t r u c t u r e >

Figure 4.11 – Script d’adaptation du composant Agenda-partagé

Figure 4.12 – Architecture d’un composant auto-adaptatif

4.4.2.2 Les connecteurs

Les connecteurs mis en jeu dans le cadre de notre modèle de composants dynamiquement et structu- rellement adaptables sont les connecteurs définis dans notre modèle statique (voir Section 3.3) auxquels nous avons introduit deux nouveaux types de connecteurs permettant de réaliser l’auto-adaptation dyna- mique :

• les connecteurs d’acquisition contextuelle

Ces connecteurs sont utilisés pour acquérir des informations sur le comportement du composant. Ces données vont être stockées sous la forme d’un historique des communications échangées entre les composants. Les informations recueillies sont par exemple le nombre de fois qu’un service est appelé par un autre service, la taille des paramètres échangés, etc. Elles vont être transmises au gestionnaire de contexte qui va les interpréter afin de générer une spécification de la structure du composant prenant en compte son comportement ;

• les connecteurs de redéploiement

Ces nouveaux connecteurs, appelés connecteurs de redéploiement sont intégrés aux connecteurs horizontaux ainsi qu’aux connecteurs verticaux. Ils ont pour rôle de gérer le redéploiement de composants logiciels destinés à être exécutés sur des sites distants de l’infrastructure distribuée. Ainsi, ces connecteurs sont chargés (1) d’intercepter les messages entrant dans le composant que

l’on veut redéployer sur un site distant, durant la durée d’indisponibilité de ce composant, (2) de réaliser le transfert d’état entre les deux instances du composant en question et enfin (3) d’agir sur les connecteurs de communications afin qu’ils transforment les appels locaux au composant transféré en appels distants vers le nouveau composant déployé.