Action de Recherche Coopérative INRIA - 1999-2000
Samoa : Structure d'accueil pour applications mobiles et configurables

 

Participants

  • Projet Sirac, INRIA Rhône-Alpes, INPG, UJF (coordinateur)
  • Projet Solidor, IRISA/INRIA
  • LIFL (Laboratoire d'Informatique Fondamentale de Lille)
  • Société Gemplus (Laboratoire de recherche)

Motivations et objectifs

Les notions de mobilité et d'adaptation sont amenées à jouer un rôle central dans la conception de nombreuses applications nouvelles de l'informatique.
  • D'une part, les objets physiques portant une partie d'une application tendent à devenir mobiles. Deux exemples représentatifs sont :
    • les cartes à puce utilisées dans diverses applications (santé, transports, commerce, etc.),
    • les stations dites nomades (pouvant se déplacer géographiquement et changer de point de connexion aux réseaux).
  • D'autre part, les applications sont amenées à être modifiées dynamiquement pour répondre à une évolution des besoins (modifications des fonctions) ou pour s'adapter à un environnement lui-même variable ; le système sous-jacent peut aussi être amené à reconfigurer les éléments d'une application pour réagir à un changement de l'environnement d'exécution, comme la défaillance d'un site ou la congestion du réseau.
Mobilité et adaptation interagissent de manière étroite :
  • Les adaptations ou reconfigurations d'une application peuvent faire appel à la mobilité des éléments qui la composent (migration ou téléchargement de code) ;
  • La mobilité nécessite souvent d'adapter le logiciel porté par les éléments mobiles à des contextes variables d'exécution.
     
    L'action proposée vise à fournir des outils et services pour la construction d'applications portées par des objets physiques mobiles. Son objectif est triple :
    • explorer les apports des techniques et outils de programmation par composants pour structurer les applications concernées par la mobilité,
    • identifier des services système génériques pour contrôler la gestion de la mobilité, et plus particulièrement pour reconfigurer l'application en vue de l'adapter à son environnement d'exécution.
    • exploiter les résultats de ce travail sur des applications innovantes.
Deux domaines d'application sont visés :
  • la réalisation d'une structure d'accueil pour des applications utilisant la carte à puce (voir Annexe, exemple 1) ;
  • la gestion d'un environnement universel (indépendant de la localisation) pour des utilisateurs nomades (voir Annexe, exemple 2).
Les équipes proposantes ont des compétences complémentaires dans les domaines couverts par l'action. Sirac et Solidor travaillent sur les "architectures logicielles" : Sirac a une expérience sur les services systèmes et la reconfiguration d'applications, Solidor sur l'adaptation nécessaire au maintien de la qualité de service. Le LIFL a une expérience sur les infrastructures de système pour objets répartis, en particulier dans le monde Corba. Gemplus a une grande expérience dans les techniques liées aux cartes à puce et dans leurs applications. Ces partenaires ont l'habitude de travailler ensemble : Sirac et Solidor coopèrent dans un projet esprit LTR sur les composants ; le LIFL et Gemplus mènent des travaux en commun autour du logiciel et des applications de la carte à puce ; Sirac, le LIFL et Gemplus coopèrent pour la mise en place en 1998 et 1999 d'une École d'Été sur la construction d'applications réparties.

Contenu scientifique

Caractérisation des applications mobiles

Le travail proposé vise les applications portées par des objets physiques mobiles (que nous appelons simplement "applications mobiles" dans la suite). Une application mobile est constituée des éléments suivants :
  • Un contexte de travail. Informations définissant le contexte de l'application courante ou de l'utilisateur courant (par exemple, pour une station nomade, l'environnement logiciel, les bibliothèques, les fichiers ouverts, etc.). le contexte de travail est représenté par des composants logiciels, directement liés à l'objet physique mobile, et qui donc bougent avec lui.
  • Des fonctions téléchargeables. Entités logicielles contenant du code fonctionnel réalisant des traitements particuliers sur le site de résidence de l'application mobile (par exemple, pour offrir une interface d'interaction particulière avec l'utilisateur). Ces entités sont stockées dans des dépôts de composants accessibles sur le réseau, qui sont téléchargés à la demande.
  • Des services distants. Entités logicielles fournissant des informations et des traitements utilisables depuis la structure d'accueil (système de fichiers, base de données, moteur de recherche, etc.). Ces services sont localisés en général sur d'autres sites que la structure d'accueil et peuvent aussi être vu comme des composants fixes.
Ces différents composants sont assemblés et configurés pour former une application en utilisant des outils de développement appropriés. En cours d'exécution, la mobilité de l'application requiert des opérations de reconfiguration pour reconstituer son environnement global d'exécution et l'adapter à la nouvelle configuration physique. Ces opérations peuvent être définies par le concepteur de l'application, sous une forme algorithmique ou déclarative (paramètres de configuration, contraintes de qualité de service, etc.), ou bien être décidées par le système en fonction de politiques de gestion de ressources qui lui sont propres. Dans l'un ou l'autre cas, les opérations de reconfiguration sont réalisées à l'aide de services ad hoc fournis par l'environnement d'accueil.
 

Voie d'approche

Dans la description d'une application, la notion de composant désigne une unité logicielle de construction. Le projet devra permettre :
  • de donner à la notion de composant un contenu précis et concret, permettant notamment de séparer a) la programmation des différentes parties de l'application ; b) l'expression des propriétés non-fonctionnelles qui leur sont associées. On devra en particulier proposer un formalisme pour la description des composants (interfaces, etc.) et de leurs relations avec d'autres composants. On réutilisera ici l'expérience acquise par les partenaires sur les langages de définition d'architecture (ADL).
  • de définir un schéma générique pour l'organisation de la structure d'accueil :  accès aux ressources locales de la machine, support d'exécution des composants, liaison et communication entre composants, liaison et communication avec les services distants, fourniture de services assurant les propriétés non fonctionnelles, gestion de la persistance et de l'adaptation de l'application.
  • de définir les services systèmes pour contrôler la migration/mobilité d'une application et pour mettre en oeuvre les opérations de reconfiguration qui sont engendrées par la mobilité.
Pour répondre aux problèmes d'adaptation posés par les applications mobiles, on propose de procéder comme suit :
  • Associer des propriétés non-fonctionnelles aux composants (propriétés spécifiées dans un formalisme approprié). Les propriétés dites 'non-fonctionnelles' comprennent notamment celles relatives à la sécurité, à la tolérance aux pannes, aux transactions, à la persistance, aux caractéristiques de performances. L'expression de ces propriétés utilise des annotations apportées à un langage de description d'architecture (ADL). La définition de cet ADL étendu fait partie des tâches de l'action.
  • Utiliser ces propriétés pour une adaptation mutuelle de l'environnement d'exécution ( 'middleware') et des applications. La construction d'un middleware pour une application donnée est jusqu'ici réalisée statiquement. Or, dans le cas d'applications s'appuyant sur des composants mobiles, les composants du middleware doivent, comme ceux de l'application, pouvoir être adaptés en fonction de l'environnement d'exécution. On peut donc envisager d'étudier une solution à la reconfiguration dynamique du middleware du point de vue des propriétés non-fonctionnelles fournies. Ce travail requiert notamment d'examiner les critères de correction de la reconfiguration dynamique d'un middleware, puis de concevoir et mettre en oeuvre les services de reconfiguration associés. Les plate-formes considérées incluent les environnements d'accueil pour la carte à puce, les environnements CORBA, les environnements à base de composants Java (e.g. Enterprise Java Beans).

Actions proposées

Les actions proposées seront organisées sous deux formes, qui correspondent à deux étapes du projet.
  • Un travail en commun entre les partenaires, en vue de définir un ensemble de concepts et d'outils applicables au problème considéré.
    • définition d'un langage commun de description d'architecture,
    • expression de propriétés non-fonctionnelles,
    • génération de code pour l'adaptation dynamique,
    • spécification de la structure d'accueil pour composants mobiles et configurables : définition d'un schéma commun d'architecture et identification des services systèmes qui s'intègrent dans cette structure d'accueil.
  • Des expérimentations spécifiques menées par chacun des partenaires sur des applications particulières. Ces expérimentations utilisent les outils élaborés en commun.

Travail commun

Le travail en commun portera sur les points suivants.
  • Langage de description d'applications mobiles à base de composants

    • L'objectif est de définir un langage de description d' architecture prenant en compte les aspects dynamiques (ce que ne font pas les ADL actuels). Le langage ainsi défini ("Mobile Application Description Language  - MADL") doit permettre de décrire une application mobile. Il devra donc permettre de définir précisement les composants (mobiles et reconfigurables) de l'application.
     
  • Définitions de propriétés

    • Les propriétés dites non-fonctionnelles comprennent essentiellement :
  • configuration physique : placement et/ou regroupement de composants sur un site donné.
  • sécurité : contrôle d'accès (protection) au composant, communication chiffrée entre certains composants, etc.
  • tolérance aux pannes : réplication d'un composant et politique de mise en cohérence des copies multiples.
  • transactions : on peut voir cette propriété comme un cas particulier de la propriété de tolérance aux pannes. Elle est mentionnée ici par analogie avec des systèmes à composant existants qui permettent l'expression d'un comportement transactionnel dans un composant (par exemple les EJB).
  • persistance : sauvegarde de l'état d'un composant en des points de contrôle spécifiés par l'utilisateur ou décidés par le système.
  • performance : cette propriété fait référence à des aspects quantitatifs de qualité de service, tels que la garantie d'un temps d'exécution d'un composant (ou d'un groupe de composant), d'une bande passante dans la communication entre composants, ou de la synchronisation entre flots de communication entre composants (pour des flots multimédia par exemple).
    • Représentation de la structure d'une application mobile

      • Une fois la description de l'application effectuée et ses propriétés définies, une description intermédiaire (pivot) de l'application doit être engendrée. Ce pivot contient l'ensemble des informations permettant de reconstituer et de reconfigurer localement l'application. Ces informations décrivent les caractéristiques statiques de l'application décrites, mais aussi les caractéristiques dynamiques de l'application telles que des paramètres de configuration et des informations liées au passé et à l'utilisateur (contexte dans lequel l'application doit reprendre par rapport à sa précédente exécution avec le même utilisateur, préférences, abonnements, paiements, droits de l'utilisateur, etc.).
    • Architecture de l'environnement d'exécution pour applications mobiles

      • L'exécution de l'application prend place dans une structure d'accueil sous le contrôle de la description pivot de l'application. Les informations pivot sont utilisées pour piloter la structure d'accueil via l'accès à des services de contrôle. Ce pilotage permet de mettre en place et de reconfigurer l'application sur la structure d'accueil. L'installation de l'application met en oeuvre les opérations suivantes :
    • Découverte des composants téléchargeables et des services distants de l'application. Cette opération peut s'effectuer en utilisant des services d'intermédiation permettant de retrouver et de localiser les composants et les services à partir d'information de désignation symbolique. Ici, des mécanismes de cache peuvent aussi être impliqués.
    • Téléchargement et installation des composants téléchargeables sur la structure d'accueil.
    • Etablissement de liaisons des composants vers des services distants et réciproquement.
    • Reconfiguration de l'application en fonction de caractéristiques dynamiques : contexte, données liées à l'utilisateur, capacités matérielles et systèmes de la structure d'accueil.
      • La structure d'accueil peut s'exécuter sur une machine mobile (ordinateur portable, PDA, GSM, etc). Cela implique que la structure d'accueil observe le comportement de l'application mobile et reconfigure dynamiquement les liaisons entre composants afin d'assurer la continuité de l'application et la qualité de service désirée.

    Expérimentations spécifiques

    les résultats de l'étude précédente sont utilisés pour mettre en oeuvre des expérimentations complémentaires portant sur les domaines applicatifs suivants.
    • Carte à puce
        • 1) Description de l'application.
            L'expérience sera menée autour d'une application de la carte à puce, décrite en Annexe (exemple 1).
        2) Méthodes mises en oeuvre.
            Autour de la carte à puce, nous travaillerons dans un premier temps sur un "framework" générique permettant à une carte d'envoyer des ordres vers son site d'accueil (aujourd'hui les cartes sont toujours esclaves dans un mode client-serveur). On travaillera ensuite sur la traduction de la description intermédiaire (pivot) de l'application sous la forme d'un programme stocké dans la carte. Ce programme carte pilotera / contrôlera les services offerts par la structure d'accueil via le framework générique.
        L'étape suivante consistera à définir les caractéristiques / fonctionnalités des services d'intermédiation utilisés par la structure d'accueil. Pour la recherche de services fixes, nous évaluerons la pertinence (ou non) d'utiliser le service "Trader" standardisé par l'OMG/ISO. En ce qui concerne le téléchargement de composants, il n'existe pas pour l'instant de solution adéquate : il faudra donc définir notre propre service.
         
    • Environnement "universel" pour stations nomades
        • 1) Description de l'application.
            L'expérience sera menée autour d'une application d'environnement universel pour stations nomades, décrite en Annexe (exemple 2).
        2) Méthodes mises en oeuvre.
            On s'attachera à définir les services d'intermédiation utilisés par la structure d'accueil pour permettre à une station nomade de reconstituer son environnement de travail. Nous comptons explorer deux voies : l'adjonction d'agents fixes ou mobiles en vue d'étendre ou de spécialiser les fonctions d'applications ou de serveurs existants ; les modèles d'exécution multipartie généralisant l'appel de procédure à distance à un ensemble d'entités coopérantes (retour à un autre que l'appelant, appel multiples, réplications des données et des traitements, etc.).
            Ces services seront prototypés dans un environnement Java.

    Michel RIVEILL

    Laboratoire I3S
    Polytech - Nice - Sophia
    930 Route des Colles
    BP 145
    F-06903 Sophia Antipolis CEDEX

    Email : riveill at unice.fr

    Généralité

    Ressources en lignes

    Une partie de mon agenda

    Des liens

    Rechercher sur ce site avec Google: 

    dernière mise à jour
    le 24 août 2006

     

     

    Réservation d'Hôtel à Prix Réduits - HotelClub