Spécialisation de comportement d’exécution incluant des stratégies d’adaptation spécifiquesd’adaptation spécifiques

La spécialisation du système d’adaptation peut également permettre aux applications de spécifier leurs propres stratégies d’adaptation. Ces stratégies peuvent être incluses dans les couches basses du système, comme dans la couche transport pour Mobiware, ou plutôt dans les couches applicatives comme dans le système Odyssey.

2.3.2.1 Mobiware

Mobiware [Campbell 1997,Angin et al. 1998,Campbell et al. 1999] est un intergiciel qui permet la conception de services de type multimédia et Internet avec une gestion et un contrôle de la qualité de service des flots entre ces services. Il fournit principalement (i) un ensemble d’interface et d’objets CORBA qui représentent et fournissent une abstraction du réseau de communication et (ii) un ensemble de contrôleurs qui interagissent avec le médium de commu-nication et les services distribués pour maintenir et adapter la QdS spécifiée par les applications. Les applications utilisent une spécification de la QdS définie au niveau de la couche trans-port et s’appuyant sur un modèle d’interface spécifique (Adaptive-QoS API and service model) introduit dans [Bianchi et al. 1998]. Ces interfaces permettent à l’application de définir : Une fonction de satisfaction selon la bande passante (bandwidth utility function) : cette

fonction permet à l’application de définir une courbe exprimant son degré de satisfaction en fonction de la bande passante observable. Différents exemples de courbes sont présentés dans la figure2.14. Cette fonction est prise en compte dans les optimisations des algorithmes d’allocation de bande passante [Bianchi et al. 1998].

0 0.2 0.4 0.6 0.8 1 BL BL+E1 BL+E1+E2 Degré de satisfaction Bande passante Adaptation linéaire Adaptation forte Adaptation faible Adaptation discrète

FIG. 2.14 – Fonction de satisfaction selon la bande passante dans Mobiware

Une politique d’adaptation (adaptation policy) : la politique d’adaptation permet de captu-rer le dynamisme d’adaptation spécifique à chaque application. Cette politique permet à l’application de contrôler le changement du degré de satisfaction (c.a.d. les déplace-ments le long de la courbe de satisfaction) selon les variations de la disponibilité de la bande passante. En effet, certaines applications, comme des applications vidéo multi-résolutions, peuvent vouloir limiter la fréquence des adaptations et ainsi choisir une po-litique d’adaptation conservatrice. Au contraire, d’autres applications, comme des ap-plications temps-réel, peuvent vouloir saisir toutes les opportunités d’adaptation et ainsi choisir une politique d’adaptation instantanée. Cette définition de la politique d’adapta-tion s’effectue par la créad’adapta-tion d’un adaptad’adapta-tion handler qui implante la politique propre

à l’application, ou par l’utilisation d’une des quatre politiques prédéfinies (fast, smooth,

handoff, never).

Des préférences sur les sessions (session preferences) : les préférences sur les sessions permettent à l’utilisateur de classer les sessions (c.a.d. les flots audio, vidéo, etc.) entrant et sortant du terminal portable. Si la bande passante est insuffisante, cette classification est utilisée pour dégrader les flots de moindre priorité. La méthode appliquée est une dé-gradation par filtres actifs (Active Filters) [Balachandran et al. 1997]. La transformation des données sera détaillée dans le paragraphe3.1.1.

Cette qualité de service est ensuite assurée par deux sortes d’objets déployés sur l’ensemble des terminaux portables et des points d’accès : les Active transport objects, qui se chargent des adaptations sur les données (dégradations selon les priorités, etc), et les Adaptation proxies, qui se chargent des adaptations du réseau (passages d’une interface réseau à une autre, etc). Ces deux types d’objets possèdent des contrôleurs qui, selon la bande passante observée, se chargent d’effectuer les adaptations nécessaires pour satisfaire la QdS spécifiée.

2.3.2.2 Odyssey

Odyssey [Satyanarayanan et al. 1994, Noble et al. 1997, Noble 2000] est une plateforme d’accès à des données depuis un terminal mobile. L’adaptation y est définie comme une né-gociation de la qualité des données en fonction des ressources disponibles. Les mécanismes proposés par cette plateforme cherchent à respecter deux propriétés : la fidélité et l’agilité.

La fidélité est le degré de correspondance entre une donnée originale et une copie de cette donnée. Elle peut avoir plusieurs dimensions qui dépendent uniquement du type de la donnée considérée. Une vidéo a, par exemple, deux dimensions : le nombre d’images par seconde et la qualité de l’image. La fidélité s’associe donc naturellement au type de la donné et les adaptations peuvent s’effectuer selon les dimensions de la fidélité. L’agilité est la capacité du système à détecter les changements de l’environnement et à les notifier aux applications, ainsi que la capacité des applications à prendre en compte ces changements pour les répercuter sur le système.

Différents composants sont mis en place au sein de la plateforme pour respecter ces pro-priétés (voir figure2.15). Les composants Wardens implantent les méthodes d’accès aux objets d’un type défini. Ils permettent également à l’application de définir les mécanismes de fidélité associés à ce type : niveaux de fidélité et politiques d’adaptation de la donnée pour chaque ni-veau de fidélité (interfaces détaillées dans [Noble et al. 1995]). Les composants Wardens sont subordonnés au composant Viceroy dont la tâche la plus importante est d’effectuer la gestion des ressources du système. Le Viceroy reçoit toutes les requêtes d’accès aux données (inter-ceptées par l’Interceptor) et, selon le niveau de fidélité des Wardens et la disponibilité des ressources, il peut notifier l’application que la QdS n’est plus satisfaite. Cette notification est réalisée par le composant Upcall. Ce composant est spécifié par l’application qui y définit : les seuils de tolérance, qui permettent de filtrer les notifications non pertinentes, et le nom de la politique d’adaptation de la fidélité, qui sera appelée dans le cas de notifications pertinentes. Dans ce dernier cas, la politique d’adaptation de la fidélité peut alors décider de modifier la fidélité en agissant sur les composants Wardens.

Application

Viceroy ^{Web Warden}

Video Warden Odyssey Upcalls Interceptor Kernel Fidelity adaptation

policy ^{Web adaptation policy}

Video adaptation policy

FIG. 2.15 – Architecture du système Odyssey

On peut remarquer que toutes les politiques d’adaptation ne correspondent pas à une spé-cialisation du système. La politique d’adaptation de la fidélité se trouve, en effet, dans l’appli-cation. Dans ce cas, la frontière qui sépare l’application du système d’adaptation est toutefois difficile à délimiter comme le montre l’exemple d’adaptation de Netscape [Noble et al. 1997,

Noble et Satyanarayanan 1999]. Dans cet exemple, un élément d’interposition entre Netscape

et Odyssey implante la politique d’adaptation de la fidélité. Cet élément pourrait très bien être inclus dans le système d’adaptation.

2.3.3 Résumé

Ces approches permettent aux applications d’avoir conscience et de pouvoir réagir à la mobilité. Elles ne permettent toutefois pas de couvrir tous les objectifs fixés.

La généricité est assurée par la spécification d’une qualité de service. Cette spécification rend le système d’adaptation indépendant des applications qui peuvent l’utiliser4. Elle intègre différents paramètres caractérisant l’environnement mobile (interface de communication,

han-doff, bande passante, etc) (approches à stratégie contextuelle (sc)) et peut être spécifiée par

l’application au sein de stratégies d’adaptation (approches à comportement spécialisable (CS)). Pour pouvoir assurer cette QdS spécifiée par l’application, les approches présentées possèdent toutes un système de détection et de notification (scd) permettant à l’application de réajus-ter dynamiquement la QdS selon les besoins. Cette spécialisation dynamique du comporte-ment (CSD) ne concerne que la qualité de service, la spécialisation de stratégies d’adaptation est statique (CSS).

Ces approches ayant une certaine généricité et modularité, elles peuvent assez aisément évoluer. Néanmoins, les adaptations sont prévues statiquement dans le système et ne peuvent facilement évoluer dynamiquement. Par exemple, dans Odyssey, l’ajout d’un nouveau type de données (avec ses niveaux de fidélité et sa politique d’adaptation) nécessite une refonte im-portante du système. Comme pour les approches transparentes, la prise en compte de critères

4Dans le cas de spécialisation de stratégies, cette généricité ne peut plus être totale puisqu’une partie du système d’adaptation dépend de l’application. La généricité peut toutefois s’appliquer à des classes d’applications ou de données, comme dans Odyssey.

relatifs aux ressources du terminal portable ou aux ressources de l’environnement n’est pas abordée. Par contre, certaines de ces approches laissent à l’application le soin de définir la stabilité des adaptations face aux changements. Les techniques utilisées (fonctions, seuils) en-diguent l’effet « boomerang » mais uniquement pour les adaptations au sein de l’application. La stabilité n’est pas gérée de manière globale et, donc, une adaptation au sein d’une application peut très bien être considérée comme stable par cette application mais induire des perturbations sur des applications concurrentes ou sur le système.