Objectif et proposition : l’auto-adaptation structurelle dynamique

4.2.1 Objectif général et analyse des besoins

Nous définissons l’auto-adaptation structurelle d’un composant logiciel comme étant la capacité du composant à modifier automatiquement sa structure en fonction de son contexte d’exécution courant. Ainsi, un composant disposant d’une telle capacité doit être capable d’acquérir des informations sur son contexte afin de générer une structure adaptée à la situation. Un composant structurellement auto- adaptatif doit donc être capable de réaliser lui même ces opérations. Pour cela, nous devons proposer

un modèle de composants structurellement auto-adaptatifs intégrant ces trois phases. De plus, afin

de prendre en compte les composants existants, nous devrons proposer un processus de ré-ingénierie

permettant d’obtenir un composant conforme à ce modèle à partir d’un composant existant.

1. Acquisition du contexte

Tout d’abord, un composant auto-adaptatif doit disposer de mécanismes lui permettant d’acquérir des informations sur son contexte d’exécution qui peuvent avoir des impacts sur la structure du composant à adapter. De ce fait, il est indispensable de définir précisément un modèle de contexte

pertinent (i.e. contexte ayant une influence sur la structure d’un composant) afin de faciliter la

prise de décisions au niveau du déclenchement et de la spécification de l’adaptation. Le modèle de contexte pertinent que nous proposons est détaillé dans la section 4.3.1 ;

2. Prise de décisions

Un composant auto-adaptatif doit disposer de mécanismes lui permettant de traiter les informa- tions contextuelles acquises afin de prendre les décisions nécessaires à son adaptation. La prise de décisions fait référence à deux activités entrant dans le cadre de l’auto-adaptation :

(a) le déclenchement de l’adaptation

La première des activités de prise de décisions dans le cadre de notre approche d’auto- adaptation est relative au déclenchement de l’adaptation structurelle du composant. Cette activité doit être réalisée en fonction du contexte d’exécution du composant : si le composant détecte un changement significatif dans son contexte, celui-ci doit déclencher une adaptation structurelle. Ainsi, il est nécessaire de concevoir une stratégie de déclenchement de l’adap-

tation permettant de définir les variations de contexte au delà desquelles une adaptation doit

être réalisée ;

(b) la spécification du résultat de l’adaptation

Une fois l’adaptation déclenchée, le composant doit déterminer lui même une structure adap- tée à son nouveau contexte d’exécution. Pour cela, il est nécessaire de proposer une stratégie

de génération automatique de la spécification d’une structure pour le composant, qui

soit adaptée à la nouvelle situation. 3. Réalisation de l’adaptation structurelle

Enfin, la dernière phase de l’auto-adaptation consiste à modifier de manière dynamique la structure du composant afin de la rendre conforme à la spécification générée lors de la phase précédente et à se redéployer si nécessaire. Ainsi, le composant doit être structurellement et dynamiquement adaptable.

Figure 4.1 – Processus d’auto-adaptation structurelle dynamique

4.2.2 Objectif et analyse des besoins relatifs aux environnements ubiquitaires

Dans le cadre de notre application aux environnements ubiquitaires, notre objectif est de proposer une stratégie d’auto-adaptation permettant à un composant de prendre en compte certaines propriétés de l’ubiquité telles que l’hétérogénéité des moyens d’exécution et de communication, les variations des res- sources disponibles ainsi que l’ouverture du système, tout en maintenant une certaine qualité de service pour l’utilisateur de l’application.

En fait, l’auto-adaptation structurelle d’un composant logiciel dans un tel environnement a pour objectif de réaliser l’adéquation entre son architecture logicielle (i.e. sous-composants, connecteurs et

configuration) et l’architecture matérielle disponible (i.e. composants matériels1, connecteurs matériels

et configuration) tout en tenant compte de l’utilisateur et des éventuelles déconnexions de sa machine et des autres sites de déploiement de l’application. Cette adéquation doit être réalisée en garantissant la continuité de service mais également en assurant la meilleure qualité de service possible.

Concernant le premier objectif, un composant doit pouvoir détecter si les ressources matérielles four- nies par son site de déploiement sont suffisantes pour garantir sa continuité de service. C’est pourquoi il doit comparer, durant son exécution, les ressources matérielles qu’il requiert pour fonctionner avec celles disponibles sur son site de déploiement. Si ces ressources matérielles se révèlent insuffisantes, il doit s’adapter automatiquement de manière à assurer sa continuité de service. L’adaptation réside alors dans sa fragmentation en sous-composants fournissant chacun un sous-ensemble de services fournis par le composant adapté. Ces sous-composants seront alors redéployés sur les différents nœuds de l’infrastruc- ture distribuée disponible, en fonction du contexte ; le choix des sites de déploiement étant primordial pour garantir la continuité de service.

La qualité de service peut, quant à elle, être garantie en assurant une meilleure répartition des charges liées à l’utilisation de ses services. De la même manière que précédemment, un composant peut être fragmenté en sous-composants distribués sur l’infrastructure disponible. Le choix de la répartition des services fournis par chaque sous-composant ainsi que leur site de déploiement est crucial pour assurer une répartition des charges optimale. Ainsi, la nouvelle structure du composant doit être déterminée en fonction de son contexte courant.

1

Figure 4.2 – Adaptation structurelle dynamique en fonction du contexte

Par exemple, la figure 4.2 montre un composant C1 qui est déployé sur une machine à ressources

limitées (site1). Imaginons que pendant l’exécution du composant C1, la répartition des charges exis-

tante soit remise en question du fait de l’évolution de l’infrastructure de déploiement (ici, la capacité mémoire disponible sur Site1 devient insuffisante pour garantir la continuité des services du composant

C1 sur ce site). Dans ce cas,C1 doit réagir en s’adaptant à ces nouvelles conditions d’utilisation. Une

solution consiste à fragmenterC1 en quatre nouveaux composants appelésC2,C3,C4,C5. Ensuite, ces

derniers sont redéployés sur des nœuds de l’infrastructure déterminés en fonction du contexte :C2 est

déployé sur site1 car, d’une part, les ressources disponibles sur site1 sont suffisantes pour le déployer et, d’autre part, les services qu’il propose font partie des services les plus utilisés par l’utilisateur de

ce site. Il est donc préférable de déployer le composant C2 sur site1 car en cas de déconnexion de ce

site à l’infrastructure, les services qu’il fournit resteront disponibles à l’utilisateur ; les composantsC4et

C5 sont déployés sur Site2 qui est une unité fixe de l’infrastructure (donc le risque de déconnexions de

Site2 à l’infrastructure distribuée est minimum) dotée de caractéristiques largement supérieures à celles

proposées par site1 (par exemple, meilleure capacité de stockage, plus grande vitesse de processeur, etc.)

et dont les ressources sont suffisantes pour déployer ces deux composants ; et enfin, le composant C5

est déployé sur Site3 car d’une part, ce dernier dispose des ressources nécessaires à son déploiement et à son exécution et d’autre part, sur ce site, est déjà déployé un ensemble de composants contenus dans l’application et utilisant fortement les services fournis par le composantC5. Ainsi, le déploiement deC5

sur Site3 permettra de diminuer la fréquence de communications distantes entre Site1 et Site3 et donc, améliorer les performances de l’application.

Ainsi, l’adaptation structurelle du composantC1aura permis de conserver la continuité de service de

l’application mais aussi d’améliorer sa qualité de service. En effet, les composantsC4etC5sont déployés

sur une machine dotée de meilleures caractéristiques techniques donc le temps d’exécution des services fournis par ces deux composants sera diminué (ce qui peut compenser les pertes liées à la communication

distante entre les deux machines : Site1 et Site2). De plus, le composantC5 est déployé Site3 ; ce qui

permet de réduire la fréquence des connexions distantes entre les composants de l’application.