Reconfiguration dynamique du composant structurellement adaptable

Le composant à adapter pour satisfaire les attentes liées à son utilisation, se trouve dans un format ca- nonique au moment de son exécution. La génération de la nouvelle structure est ainsi obtenue à partir de ce format. Il s’agit de construire, à la volée, de nouveaux composants à partir des composants interfaces existants. Chaque nouveau composant deviendra ainsi un composant composite dont les sous-composants des composants primitifs. Chaque nouveau composant composite doit donc encapsuler toutes les inter- faces fournies et requises par ses sous-composants. Ces derniers ne seront plus visibles et ils seront accessibles uniquement par les interfaces du composite les contenant. Ainsi, chaque composite fournit l’ensemble des services offerts par ses sous-composants. De plus, il définit comme interfaces requises,

celles requises par ses sous-composants, exceptées celles fournies par d’autres de ses sous-composants. Les nouveaux composants générés seront, par la suite, manipulés comme des unités de déploiement à part entière. Ainsi, il est nécessaire de définir une opération d’encapsulation de composants primitifs pour réaliser la reconfiguration.

Cependant, l’encapsulation n’est pas toujours suffisante pour obtenir la structure souhaitée. En effet, si une phase de reconfiguration a déjà été opérée sur le composant à adapter, certains composants primitifs peuvent être encapsulés dans un composite. Or, si la nouvelle spécification requiert l’encapsulation de plusieurs composants déjà encapsulés dans des composites différents, il est nécessaire de casser ces composites afin de procéder à leur encapsulation dans un composite répondant à la spécification. De ce fait, il est indispensable de définir une opération d’éclatement des composites issu des opérations d’encapsulation menées dans le cadre de la reconfiguration du composant.

La reconfiguration, à la volée, du composant sous format canonique nécessite donc la définition de deux nouvelles opérations de reconfiguration. Ces opérations sont les suivantes :

1. l’encapsulation de composants primitifs

Cette opération consiste à encapsuler plusieurs « composants primitifs » dans un même composant appelé « composant généré » fournissant les services de l’ensemble des composants qu’il contient. Le nouveau composant ainsi créé a le même comportement que l’assemblage des « composants primitifs » qu’il contient ; de ce fait, l’intégrité du composant adapté est préservée. Cette opération de reconfiguration est réalisée de la manière suivante (voir Figure 4.16) :

(a) extraction des composants à encapsuler

Tout d’abord, (1) l’assemblage de « composants primitifs » qui va être encapsulé dans un composant composite généré à la volée doit être extrait du composite initial. Pour cela, les liaisons entre les interfaces (fournies/fournies, fournies/requises et requises/requises) doivent être détruites, exceptées celles associant deux interfaces de « composants primitifs » conte- nus dans l’assemblage isolé ;

(b) encapsulation dans un composite

Puis, (2) le composite encapsulant les « composants primitifs » est créé. Les interfaces four- nies sont celles fournies par les composants qu’il encapsule alors que les interfaces requises sont celles requises par les composants qu’il encapsule, exceptées celles qu’il fournit ; (c) reconfiguration des connexions internes

Ensuite, (3) l’assemblage à encapsuler est connecté au composite généré : les interfaces four- nies par le composite sont connectées aux interfaces fournies par les « composants primitifs » au travers de liaisons d’exportation. Les interfaces requises des « composants primitifs » et des sous-composites sont également connectées. Si une interface requise par un « composant primitif » est fournie par un autre « composant primitif » de l’assemblage à encapsuler alors la connexion est directe. Dans le cas contraire, il faut créer une liaison d’exportation entre cette interface requise et l’interface requise du composite généré correspondante ;

(d) reconfiguration des connexions externes

Enfin, le composite généré est connecté au composant adapté (connexion à la membrane du composite et aux autres sous-composants) : les interfaces fournies du composant composite

généré sont connectées à celles du composant adapté au travers de liaisons d’exportation ainsi qu’aux interfaces requises d’autres sous-composants (du composite adapté) qui étaient connectées directement aux interfaces fournies des « composants primitifs » encapsulés. Les interfaces fournies du composant composite généré sont quant à elles connectées aux inter- faces fournies correspondantes ou bien avec une interface requise du composant composite. Dans le premier cas, l’interface est fournie par un autre sous-composite. Il faut donc établir une connexion directe entre ces deux interfaces. Dans le second cas, le service est fourni par un autre composant de l’application. Un lien d’exportation doit donc être mis en place entre l’interface requise du sous-composite et celle du composite correspondante.

La figure 4.15 montre un exemple de reconfiguration de la structure d’un composantC par encap-

sulation de ses sous-composants. Les « composants primitifs »C1etC2fournissant respectivement

les servicesS1etS2sont encapsulés dans un composantC5qui pourra alors être redéployé sur un

autre site. De la même manière, les composantsC3 etC4fournissant respectivement les services

S3etS4sont encapsulés dans un composantC6.

Figure 4.15 – Opération d’encapsulation de « composants primitifs » 2. l’éclatement d’un composant composite généré par encapsulation

Cette opération consiste à éclater un composant composite généré lors de l’encapsulation de « composants primitifs ». Dans ce cas, le composite est remplacé par l’assemblage de « composants primitifs » qu’il contient. Cet assemblage fournit les mêmes services que le composite car le com- posite ne fournit pas de services qui lui sont propres ; de ce fait, l’intégrité du composant adapté est préservée. Cette opération de reconfiguration est réalisée de la manière suivante (voir Figure 4.16) :

(a) destruction des connexions

Tout d’abord, (1) le composant composite à éclater est déconnecté du composite le contenant (i.e. destruction des liaisons d’exportation relatives aux interfaces fournies et requises entre les deux composants) ainsi que des autres sous-composants qui lui sont liés (au travers une interface requise) ;

(b) destruction de la membrane

Ensuite, (2) la membrane du composant à éclater est détruite et l’assemblage de composants la contenant est extraite ;

(c) reconfiguration des connexions

Puis, (3) les composants issus de l’éclatement du composant sont assemblés avec les autres sous-composants ainsi qu’avec le composite le contenant : d’une part, les interfaces four- nies par les sous-composants sont connectées avec les interfaces fournies du composite cor- respondantes (au travers de liaisons d’exportation) ; concernant les interfaces requises de l’assemblage de composants extraits, si une interface requise est fournie par un autre sous- composant alors les deux interfaces seront liées. Dans le cas contraire, l’interface requise de l’assemblage sera liée à l’interface requise du composite au travers une liaison d’exportation. Une fois que toutes les interfaces qui ont été déconnectées sont à nouveau liées à d’autres interfaces, l’opération d’éclatement se termine.

La figure 4.16 montre un exemple de reconfiguration de la structure d’un composantC par éclate-

ment de sous-composites générés par encapsulation de « composants primitifs ». Dans cet exemple,

les composantsC5etC6sont éclatés de manière à obtenir la structure initiale du composant.

Figure 4.16 – Opération d’éclatement de « composants générés »

Ces deux opérations sont utilisées pour reconfigurer la structure d’un composant conforme au modèle canonique que nous avons défini précédemment, en fonction du la spécification de l’adaptation fournie par l’administrateur de l’application. Pour cela, plusieurs stratégies peuvent être envisagées :

• stratégie de reconfiguration par la destruction

La première stratégie consiste à détruire tous les composites qui ont été générés. Puis, à recons- truire par encapsulation la nouvelle structure spécifiée. Cette stratégie n’est pas optimale en terme d’opérations de reconfiguration à appliquer sur le composant à adapter.

• stratégie de reconfiguration par la comparaison

La deuxième stratégie consiste à comparer la structure actuelle du composant à celle souhaitée au travers de la spécification fournie et à déterminer le delta entre ces deux structures. L’algo- rithme de reconfiguration consiste alors à détruire un minimum de composites qui ont été créés lors d’adaptations précédentes en fonction de la nouvelle spécification (voir Figure 4.17). Les composants obtenus vont alors servir de briques de base à la création de la nouvelle structure. Ensuite, des opérations d’encapsulation sont réalisées afin de rendre la structure du composant adapté, conforme à la nouvelle spécification. Cette stratégie permet de cibler les opérations de reconfiguration à réaliser.

S = C1..n//sous-composants du composite avant son adaptation

S′

= C′

1..m//sous-composants à générer par reconfiguration

i = 1 j = 1

Tant que|S′

| 6= ⊘ Faire

Si structureExterne(Ci)= structureExterne(Cj′) alors

S′ = S′ −nC′ j o i = i + 1 j = 0 Sinon

Si structureExterne(Ci)T structureExterne(Cj′)6= ⊘ alors

éclater(Ci) éclater(Cj) j = 0 Sinon j = j + 1 retournerS

Figure 4.17 – Algorithme de génération des briques de base servant à la reconfiguration