Evaluation des plateformes d’auto-adaptation

Les adaptations des applications basées composants se réfèrent à la capacité d'un système à s'adapter aux besoins changeants des utilisateurs et au contexte en exploitant les connaissances sur sa configuration et les caractéristiques de la QdS de ses composants constitutifs. L'adaptation basée planification [ROU08, GEI08, BRA07, FLO06, LUN07] est l’une des approches d’adaptation des applications basées composants. Dans MUSIC [ROM09], cette connaissance est fournie sous la forme d'un modèle dirigé par la QdS qui décrit la composition abstraite, les dimensions pertinentes de la QdS et comment elles sont affectées lorsqu’il existe des variantes de configuration des composants. Ce modèle est exploité par le middleware d'adaptation pour sélectionner, connecter et déployer une configuration de composants fournissant la meilleure utilité. L’utilité est mesurée par le degré d'accomplissement des préférences utilisateur tout en optimisant l'utilisation des ressources du dispositif [MAS02, GEI08].

Adaptive Service Grids (ASG) [KUR08] et VieDAME [MOS08] sont des initiatives permettant les compositions dynamiques et les attachements de services pour l'adaptation. En particulier, ASG propose un cycle de vie adapté à la livraison de services d’adaptation. Il est composé de trois sous-cycles: la planification, l’attachement de la spécification sémantique au service concret et l'incorporation. Le point d'entrée du cycle de livraison est une demande de services sémantiques qui consiste en une description de ce qui sera réalisé et non du service concret qui doit être exécuté. VieDAME propose un système de contrôle qui observe l'efficacité des processus BPEL (Business Process Execution Language) et effectue automatiquement le remplacement de service en cas de dégradation des performances. Comparé à notre approche, ASG et VieDAME sont basés seulement sur la planification à la demande de compositions de services qui concerne les propriétés définies dans la demande de service sémantique. Ainsi, les deux approches ne garantissent pas une configuration cohérente des composants et des services alors que notre plateforme l’assure pour des applications ubiquitaires basées composants tout en séparant les préoccupations de l’application de celles de l’adaptation assurée par les connecteurs d’adaptation.

Menasce et Dubey [MEN07] proposent une approche de QdS en SOA. Les clients demandent des services au broker de QdS qui sélectionne un fournisseur de services qui maximise la fonction d'utilité du client en rendant compte des contraintes de coût. L'approche suppose que les fournisseurs de services

Page 148

s'inscrivent auprès du broker en fournissant des demandes pour chacune des ressources utilisées par les services fournis ainsi que les fonctions de coût pour chaque service. Le broker de QdS emploie des modèles analytiques pour prévoir les valeurs de QdS des divers services qui pourraient être choisis dans des conditions variables de travail. Cette approche est intéressante du point de vue client et fournisseur. Tandis que le client est déchargé d'accomplir la découverte et la négociation de service, le fournisseur détermine le support de la gestion de QdS. Cette approche exige que le dispositif client permette l’accès au broker, ce qui pourrait ne pas être possible dans des environnements ubiquitaire. Notre approche diffère en ce que l'on considère les propriétés proposées comme solutions pour déterminer la meilleure configuration de l'application et permettre aux connecteurs de s'adapter aux besoins des composants.

CARISMA est un middleware pair-à-pair mobile exploitant le principe de réflexion pour supporter la construction des applications adaptables sensibles au contexte [CAP03]. Les services et les politiques d'adaptation sont installés et désinstallés à la volée. CARISMA peut déclencher automatiquement l'adaptation des applications déployées lors de la détection des changements de contexte. CARISMA utilise des fonctions de service pour choisir les profils d'application qui sont utilisés afin de déterminer l'action appropriée à un événement particulier de contexte. S'il existe des profils d'application en conflit, il emploie une procédure d’enchère pour les résoudre. Contrairement à notre approche, CARISMA ne traite pas la découverte de services à distance qui peuvent déclencher des reconfigurations d’application et ne permet pas la recherche des nouvelles configurations possibles.

Les deux modèles conceptuels SeCSE (http://www.secse-project.eu/) et PLASTIC (http://www.ist- plastic.org/) se focalisent sur les systèmes orientés services. Le modèle PLASTIC est une extension du modèle SeCSE qui introduit de nouveaux concepts, comme le contexte, la localisation et le niveau de crédibilité du service. Notre approche et le modèle PLASTIC partagent l’approche de type SOA et le développement de logiciels basés composants. Toutefois, le modèle conceptuel de notre approche est centré composant tandis que celui de PLASTIC est centré service.

Le modèle MUSIC décrit la composition abstraite comme un ensemble de rôles en collaboration avec des ports qui représentent des fonctionnalités fournies ou requises par les composants collaborateurs. Les propriétés et les fonctions prédictives associées aux ports définissent comment les propriétés de QdS et les besoins en ressources des composants sont influencés par les propriétés de QdS des composants dont ils dépendent. Ce middleware d’adaptation propose un typage de service afin de pouvoir changer de service en cas d’absence ou de changement de contexte. Notre plateforme propose un typage des données afin de pouvoir détecter et régler le problème d’hétérogénéité entre composants manipulant différents types de média. Le typage de services est utilisé dans notre approche pour classer les services d’adaptation selon l’adaptation fournie ce qui nous donne la possibilité de choisir les meilleurs services en termes de qualité et de changer le service d’adaptation en cas de disparition ou de baisse de qualité.

Page 149

Synthèse

Dans le contexte d’adaptation de contenus lié à la très grande hétérogénéité des moyens de communication, des connexions et des préférences des utilisateurs ; de nombreux travaux ont été effectués pour fournir des outils d’adaptation de contenus multimédias. Les techniques actuellement disponibles reposent principalement sur la transformation, le transcodage, le transmodage et l’adaptation structurelle. Assurer la tâche d’adaptation de contenu dans une architecture globale nécessite la connaissance de l'environnement, des composants et des flux échangés entre ces composants.

Mis à part NAC et DCAF, aucune des architectures présentées ne manipule des documents multimédia composés qui nécessitent un effort supplémentaire d’analyse des descriptions du document composé et sa reconstruction en tenant compte de la synchronisation temporelle et/ou de l’organisation spatiale des médias élémentaires composant ces documents.

Les architectures ISIS et NAC ne se prêtent pas à l’extensibilité car les modules réalisant les différentes fonctionnalités sont choisis statiquement et aucun choix dynamique des modules n’est permis.

D’autres architectures telles que MAPS ne passent pas à l’échelle car la plateforme ne le permet pas. APPAT et PAAM sont les seules architectures à introduire la notion de description des ressources d’adaptation en vue d’une recherche par critère dans un annuaire ou une base de données distribuées. Cette fonctionnalité permet le choix des adaptateurs adéquats.

Le tableau ci-dessous présente une étude comparative entre les quatre approches d’adaptation précédentes.

Approche Décision d’adaptation Avantages Inconvénients

Centrée serveur

Au niveau serveur + Contrôle efficace des

adaptations et de la gestion de contenu.

+Mise en œuvre de mécanismes d’adaptation dynamique et statique.

-Le fournisseur intègre des mécanismes d’adaptation. -Charge de calcul sur le serveur. -Portée limitée de l’adaptation

Centrée client

Au niveau client par deux méthodes : sélection de contenus ou

transformation ad hoc.

+Pour les problématiques simples. -Mal adaptée aux situations où les contraintes réseau sont prégnantes. -N’est pas pratique.

Centrée proxy

Sur un nœud intermédiaire : proxy

+Mise en cache des résultats. +La charge de calcul est sur le proxy.

+Dispose d’une vue globale sur l’environnement.

-Passe mal à l’échelle. -Problème de sécurité -Outils d’adaptation amenés à évoluer.

Hybride

Au niveau du Serveur, Client et Proxy.

+ Plusieurs postes participent aux tâches d’adaptation

+ Partage de calcul et de charge

-beaucoup de travail de gestion et de contrôle

-Gestion très difficile des adaptations et des services -Problème de sécurité

Page 150

Notre objectif est de répondre à deux questions : Qui va exécuter les adaptations ? (on parle là de l’entité logique) Et où va-t-on va l’exécuter ? (on parle là de l’endroit physique).

Les utilisateurs possèdent de plus en plus des terminaux à capacités limités telles que les assistants personnels (par exemple les blackberry). De ce fait, une adaptation côté client ne sera pas toujours possible.

L’adaptation côté serveur, ou à la source du document multimédia, nécessite l’implémentation de modules supplémentaires qui n'est pas toujours possible (capacité des serveurs limitée parfois) et qui peut créer une charge supplémentaire indésirable sans rapport avec la production de contenus multimédia. L’adaptation côté serveur n’est ainsi, à son tour, pas toujours évidente.

Nous nous inspirons des architectures centrées Proxy pour pouvoir définir des entités indépendantes des composants des applications, ces entités logicielles, appelées connecteurs d’adaptation, prennent en charge l’adaptation des flux multimédia et assurent l’interopérabilité entre les composants d’une application. Les architectures hybrides permettent d’avoir plus de flexibilité et de liberté pour l’exécution des adaptations ce qui donne la possibilité d’exécuter les connecteurs d’adaptation au niveau du serveur, au niveau du client ou au niveau intermédiaire suivant les capacités de ces derniers.

Dans ce chapitre, nous avons fait un tour d’horizon de différentes architectures d’adaptation utilisant diférentes techniques et politiques d’adaptation. Nous avons constaté que la présence de certaines tâche est nécessaire pour mettre en œuvre une politique d’adaptation telles que : la gestion du contexte, la gestion des adaptations, le suivi du contexte, la prise de décision et la planification des adaptations. Ainsi, nous avons pu constater la dificulté de choix des lieux d’éxecution des adaptateurs.

La majorité des solutions proposées dans le domaine de l’auto-adaptation des applications basées composants repose sur des modèles spécifiques pour les composants utilisés (EJB, CCM, .net, etc.) ce qui limite leur utilisation. Ainsi, les possibilités d’adaptation dans ce domaine restent restreintes du fait qu’elles se limitent à des remplacements ou au réassemblage de composants.

Notre proposition, s’intéresse aux limitations des projets précédemment décrits en proposant, en particulier, une plateforme qui contient tous les gestionnaires permettant de mener des adaptations sur le contenu multimédia echangé entre des composant d’une application. Elle propose un mécanisme d’adaptation indépendant des composants fonctionnels des applications. Il s’agit des connecteurs d’adaptation qui s’éxecutent au niveau du serveur, client ou intermédiaire selon leurs capacités. Cette plate-forme propose des mécanismes pour intégrer de nouveaux connecteurs d’adaptation, permettant ainsi la construction dynamique de connecteurs d’adaptation optimaux pour des données multimédia et la gestion des contextes changeants des utilisateurs, des terminaux et des médias.

1. Introduction