L’adaptation peut être prise en charge par l’application elle-même qui est alors qualifiée d’auto-adaptable. Elle peut être aussi réalisée au niveau de l’infrastructure logicielle sous-jacente comme le système d’exploitation, la pile des protocoles réseaux ou l’intergiciel [CHE 05]. De plus, l’intervention de l’administrateur ou de l’utilisateur de l’application dans l’adaptation est envisageable, voire souhaitable.
Mais, rien n’empêche que tous ces acteurs participent ensemble à la réalisation de l’adaptation. En fait, ces différentes possibilités correspondent à l’évolution historique de la façon dont l’adaptation a été implantée. Cette évolution est passée par trois étapes principales [CHE 05]:
3.3.1 Adaptation à la charge des applications
Initialement, l’adaptation était entièrement laissée à la charge des applications. C’était notamment le cas des premiers programmes destinés aux environnements mobiles. Ces programmes devaient gérer eux-mêmes les changements de contexte dus à la mobilité comme la variation de la bande passante et du taux d’erreurs de transmission du réseau sans-fil, les déconnexions imprévues, etc. [CHE 05].
De façon générale, développer une application adaptable revenait à écrire en plus du code métier, le code qui observe l’environnement (p. ex. surveillance des paramètres du réseau), le code qui prend la décision d’adaptation (p. ex. augmenter ou diminuer la quantité d’information transmise à travers le réseau) et le code qui concrétise ces décisions (p. ex. filtrer, compresser ou mettre en attente les informations transitant par le réseau, etc.) [CHE 05].
Ainsi, l’écriture et la maintenance d’une application adaptable étaient des tâches difficiles et complexes pour les développeurs. Ceux-ci devaient posséder des compétences multiples et variées, allant de leur domaine d’expertise spécifique à la maîtrise des technologies utilisées dans les infrastructures sur lesquelles leurs applications sont déployées.
3.3.2 Adaptation transparente aux applications
Pour palier l’inconvénient précédent, les travaux de recherche se sont orientés vers l’intégration de l’adaptation dans l’infrastructure logicielle afin de la rendre transparente aux applications [SAT 96]. Cette approche est attrayante car elle permet d’exploiter les applications existantes sans modification. Elle est même désirable dans le cas où les conditions de l’adaptation seraient connues à priori [DOW 01].
Cependant, l’adaptation transparente est fondamentalement limitée car, compte tenu de la diversité des applications, aucun système (aussi intelligent soit-il) ne peut prévoir toutes les conditions et les
stratégies d’adaptation possibles. Pire encore, cette approche peut être inadéquate ou peut avoir des contre-performances dans certaines situations importantes [PIT 98].
3.3.3 Applications conscientes de l’adaptation
Les deux approches précédentes (l’adaptation entièrement à la charge des applications et l’adaptation complètement transparente) constituent deux extrêmes présentant chacun des inconvénients importants. Pour éviter ces inconvénients, la majorité des chercheurs admet que la meilleure approche est de rendre les applications conscientes de l’adaptation. Pour cela, il faut mettre en oeuvre [CHE 05]:
Une observation des ressources de la plate-forme d’exécution (p. ex. cycles CPU, mémoire, réseau, etc.) et une remontée des informations concernant les variations de ces ressources jusqu’aux applications.
Une collaboration entre les applications et les couches système pour prendre des décisions d’adaptation cohérentes et globalement optimales.
Cette approche s’explique par le fait que dans certaines situations, les applications sont mieux placées que l’infrastructure sous-jacente pour prendre les décisions d’adaptation. A titre d’exemple [CHE 05], deux techniques possibles pour s’adapter à la chute de la bande passante du réseau sont la compression des données transmises ou l’effacement d’une partie de ces données.
Dans ce cas, le système ne sait pas qu’elle technique est la plus appropriée, ni quelle partie de données il faut effacer s’il choisit la deuxième technique. En fait, seule l’application qui traite ces données est en mesure de faire le bon choix. La deuxième raison qui justifie cette approche est due à la concurrence entre plusieurs applications non conscientes les unes des autres.
Dans ce cas, le système peut jouer le rôle d’arbitre pour éviter des décisions d’adaptation individuelles qui sont contradictoires (conflictuelles) ou inéquitables. Ainsi, le traitement de l’adaptabilité nécessite à la fois des supports système appropriés [FRI 96] et une participation importante de la part des applications (voir même de l’utilisateur, en dernier ressort).
En d’autres termes, l’adaptation aux variations de l’environnement doit être multi-niveaux [CHE 05]. Le tableau 1.1 donne quelques exemples de techniques d’adaptation avec leurs emplacements par rapport aux différents niveaux logiciels.
Tableau 3.2 Exemples d’adaptations dans différents niveaux logiciels.
Page suivante : 3.4 Sujets de l'adaptation (Quoi ?)
Retour au menu : UTILISATION DES SCRIPTS POUR LE DEVELOPPEMENT DES COMPOSANTS COM ADAPTABLES