L OGIQUE D ADAPTATION

La logique d adaptation d une application définit i les informations à superviser afin de

détecter des situations d adaptation et ii les opérations dadaptationà effectuer face aux situations

détectées La logique d adaptation définit ainsi quand adapter et comment adapter. Elle peut être exprimée à travers différents types de politiques [64] :

 des politiques d action qui dictent les actions à effecteur face à une situation prédéterminée afin d assurer le comportement souhaité d une application Typiquement les politiques d action sont exprimées sous forme de règles ECA Evénement Condition Action permettant ainsi de spécifier un ensemble d actions à effectuer quand un

événement a lieu et que certaines conditions sont remplies. La simplicité et la rapidité

d expression de ces politiques les rend très populaires surtout pour des applications dont les situations sont peu nombreuses et connues à l avance En effet ce type de

politiques est utilisé depuis longtemps dans les systèmes adaptatifs.

 des politiques de but qui définissent un ensemble de situations ou des propriétés

désirables d une application : les buts. Les actions à effectuer pour satisfaire ces buts sont déterminées par le système. Ces politiques offrent ainsi une alternative lorsque les

politiques d action sont inadaptées à cause du grand nombre de situations possibles Les politiques de but sont bien adaptées aux systèmes qui raisonnent sur l architecture du

système.

 des politiques de fonctions d utilité qui permettent de caractériser le degré de

satisfaction d une situation par rapport au but global de l application Une situation n est

plus considérée comme valide ou invalide : elle reçoit une valeur indiquant le degré de satisfaction, calculée en fonction dun ensemble de paramètres qui caractérisent la situation. En utilisant ce type de politiques, un système peut chercher à optimiser sa configuration : deux situations peuvent être comparées. Ces politiques, tout comme les politiques de buts, permettent de gérer des cas non prévus par le concepteur du système. Cependant, leur difficulté est d inférer les actions à effectuer pour atteindre une situation dont le degré de satisfaction serait meilleur.

3.3.1 R

La reconfiguration dynamique est le processus de modification de l architecture d une application durant son exécution La reconfiguration dynamique d une application est possible grâce à la représentation de son architecture d exécution, i.e., à son modèle descriptif.

Une reconfiguration dynamique peut être faite par des scripts de reconfiguration. Les

modifications peuvent être effectuées par un gestionnaire d adaptation voir la Figure 20) qui doit

manipuler la structure de l application tout en minimisant la durée de linterruption, et en assurant

l intégrité de l application i e un état cohérent avant et après la reconfiguration

Figure 20 Reconfiguration dynamique d une application

Les opérations de base sur les composants (types et instances) qui permettent de réaliser la reconfiguration dynamique des applications sont :

 l ajout d un composant

 le retrait dun composant

 la création dune liaison entre composants

 la destruction d une liaison entre composants

 la mise à jour d un composant

3.D

D autres opérations sont nécessaires afin de garantir l intégrité des applications lors de la

reconfiguration des applications [27] :

 la passivation d un composant

 l activation d un composant

Une des approches les plus utilisées pour assurer l intégrité des applications est la quiescence, proposé par Kramer et Magee [65]. Ils proposent différents états (status) pour les composants d une

application. Un composant dans un état actif peut initier, accepter et traiter des transactions. Un composant dans un état passif continue à traiter les transactions en cours et peut initier des

transactions requises par d autres transactions en cours afin de permettre sa complétion. Cependant,

la passivation d un composant bloque toutes les nouvelles transactions entrantes du composant afin de permettre sa manipulation Un composant peut être manipulé une fois qu il est dans un état quiescent : il est passif et il ne traite plus des transactions. Un composant dans un état quiescent est dans un état cohérent car il ne contient pas de résultats de transactions incomplètes. Une fois une reconfiguration terminée, les composants passivés peuvent être réactivés.

Toutefois, la quiescence demande un contrôle total de l application afin de détecter les

transactions entrantes des composants. De plus, les transactions imbriquées sont très coûteuses en

termes de temps d interruption de l application : un grand nombre de composants doivent être

passivés D autres approches comme la tranquillité (tranquility) [66], ont été proposés pour assurer

l intégrité d une application toute en réduisant le temps d interruption lors de son adaptation.

Une opération de reconfiguration peut être décrite comme une séquence ou une combinaison de

patrons chacun définissant un ensemble d opérations de reconfiguration. Parmi ces patrons nous pouvons mentionner le remplacement, l interposition et la migration dynamiques.

Dans le remplacement dynamique, le but est de remplacer un composant par un autre composant compatible, sans arrêter l exécution de l application et en minimisant le temps d interruption du fonctionnement de l application Considérons l exemple présenté dans la Figure 21, où le composant C

doit être remplacé par le composant C.

Pour réaliser le remplacement dynamique d un composant l interposition peut être utilisée Elle

consiste à insérer un intercepteur devant un composant pendant l exécution d une application. Tous les appels à ce composant seront donc capturés par l intercepteur qui est lui-même lié au composant. Dans le cas du remplacement dynamique, un tel intercepteur est appelé médiateur. Une fois le

médiateur disponible le remplacement d un composant est effectué en deux phases (illustrées dans la Figure 21) :

 la phase de blocage : les nouveaux appels au composant C sont bloqués par le médiateur, les appels en cours sont autorisés à se terminer. Lorsque le composant C est dans un état quiescent, la phase de transfert est démarrée.

 la phase de transfert le médiateur réalise le transfert d état (si nécessaire) entre C et C. Ensuite, les liaisons vers C sont mises à jour (rebinding) afin de pointer sur C. Enfin, les appels bloqués sont repris en utilisant le composant C.

La migration dynamique d un composant C d un site S à un site S, utilise le patron de remplacement dynamique : C est remplacé pour une copie de lui-même placée sur le site S. La copie du composant est faite quand le composant C est dans un état quiescent.

La reconfiguration dynamique est donc primordiale pour l adaptation dynamique d une

application. Un dysfonctionnement du processus de reconfiguration peut avoir des effets indésirables

sur l application De ce fait assurer l intégrité de l application lors des reconfigurations dynamiques est

un défi majeur.

3.3.2 E

La logique d adaptation quand et comment adapter d une application peut être implantée selon

différentes approches :

La logique d adaptation est mélangée avec la logique métier de l application L adaptation

(gestion du dynamisme, détection de situations, exécution de reconfigurations) est directement gérée

dans le code de l application Malgré la contradiction avec le principe de séparation des

préoccupations cette approche est la plus simple et l une des plus utilisées aujourd hui car l adaptation est définie et implémentée en même temps que le code fonctionnel L avantage de cette approche est que le code d adaptation est complétement spécifique et intégré à l application permettant une gestion

très spécialisée du dynamisme sans avoir besoin d une infrastructure spécifique Cependant la modification du comportement de l adaptation requiert la modification des éléments de l application

complexifiant ainsi sa maintenance. En outre, toutes les sources de dynamisme ne peuvent être gérées de cette façon. Ainsi, cette approche peut être utilisée pour des applications avec des besoins de performance importants et de dynamisme limité.

La logique d adaptation est fusionnée avec la logique métier de l application. Le code

d adaptation est séparé du code de l application respectant ainsi le principe de séparation de

préoccupations. Une approche couramment utilisée est la programmation par aspects (AOP34), qui

permet de séparer le code des aspects du code métier d une application L intégration des aspects est

réalisée à la compilation de l application Cette approche permet d avoir une meilleure maintenabilité de l application Cependant le code d adaptation reste spécifique aux composants de l application

La logique d adaptation est définie dans le conteneur de l application. Cette approche est utilisée dans les systèmes basés sur des modèles à composants. Cette approche respecte aussi le principe de séparation des préoccupations, et par conséquent l application n est pas impactée par les

modifications du code d adaptation Cependant le code d adaptation est généralement dépendant du

composant pour lequel il a été conçu le code d adaptation doit connaître le fonctionnement interne du composant pour savoir comment l adapter De ce fait le code d adaptation est spécifique au composant et généralement il n est pas réutilisable De plus la maintenance des deux parties n est pas aussi indépendante qu il y parait : un changement dans le code de l application peut impacter le code

d adaptation Bien que cette approche comporte de nombreux avantages elle reste aujourd hui peu utilisée car elle est généralement difficile à mettre en œuvre

La logique d adaptation est définie séparément de l application. Cette approche suit aussi le principe de séparation de préoccupations. Elle découple totalement la logique d adaptation de l application Cette approche se base sur les interfaces d administration des composants de l application préalablement définies, permettant ainsi de s abstraire de limplémentation des

composants de l application L avantage de cette approche est que le code d adaptation de l application est indépendant de toute contrainte liée à l application technologie, topologie, architecture), cependant elle requiert que les interfaces nécessaires à l adaptation soient définies au préalable

En outre la logique d adaptation peut être implantée de façon centralisée ou distribuée