Construction d'applications réparties - Programme de recherche

Mots clés : programmation constructive, composant, intégration d'applications, reconfiguration dynamique, applications adaptables, code mobile, agents mobiles .

Résumé :

L'objectif d'adaptabilité des applications conduit à développer le thème de la construction d'applications réparties selon deux axes principaux.
  1. Programmation par composants. Étude des méthodes et outils permettant de décrire, de construire, et de faire évoluer des applications réparties constituées d'un ensemble de composants configurables interconnectés, avec un accent particulier sur la réutilisation, l'adaptation et la reconfiguration.
  2. Environnements pour applications adaptables. Étude des méthodes et outils permettant de construire des applications réparties pouvant s'adapter dynamiquement à des conditions variables d'exécution. Les techniques utilisées sont notamment la mobilité du code et des données, ainsi que l'extension dynamique de logiciel.


Une application informatique est dite répartie lorsqu'elle met en jeu des parties qui s'exécutent sur plusieurs machines reliées par un système de communication. Les premières applications réparties ont été développées en utilisant directement les mécanismes de bas niveau (messages) fournis par le système de communication. A partir de ce stade initial, les efforts ont principalement visé à :

  1. dissimuler autant que possible la répartition, pour se ramener aux schémas connus de programmation centralisée;
  2. fournir des mécanismes d'un plus haut niveau d'abstraction que les messages, pour la communication et pour le partage d'information;
  3. faciliter la maintenance des applications, et en particulier leur évolution pour s'adapter aux nouveaux besoins et aux nouveaux environnements;
  4. faciliter la réutilisation des applications et parties d'applications existantes.
Les objectifs 3) et 4) sont des exigences de génie logiciel qui ne sont pas propres à la programmation répartie, mais qui sont plus difficiles à satisfaire dans ce contexte qu'en milieu centralisé.

La poursuite des objectifs 1) et 2) a fait l'objet de nombreux travaux depuis les années 80. Elle a conduit à l'émergence de plusieurs modèles d'organisation des applications (client-serveur, communication par événements, partage d'objets) et des mécanismes nécessaires à leur mise en oeuvre (appel de procédure à distance, bus logiciel, mémoire virtuelle répartie). Dans les années 1987-95, nous avons nous-mêmes contribué à ces recherches, à travers le projet Guide (dont est issu le projet Sirac). Les contributions de Guide ont porté sur le langage [3] et le support d'exécution ([1], [6]); on en trouvera une synthèse rétrospective dans [2]. Les résultats des recherches sont aujourd'hui intégrés dans un ensemble de produits largement utilisés (Corba, DCOM, Java), s'appuyant sur des normes officielles ou des standards de fait.

Concernant les objectifs c) et d), la diffusion industrielle des techniques à base d'objets dans les années 1990 a contribué à améliorer la qualité globale du logiciel et particulièrement la réutilisation de programmes et la maintenabilité des applications. Néanmoins, ces techniques seules ne répondent pas entièrement aux objectifs visés, car elles laissent de côté plusieurs aspects: la description globale d'une architecture logicielle, la composition d'une application par assemblage de pièces élémentaires, l'évolution dynamique d'une application.

C'est pour intégrer ces aspects qu'a été introduite la notion de composant logiciel [Szy98]. Les composants [19] possèdent des propriétés analogues à celles des objets (encapsulation de code et de données, séparation entre interface et réalisation, polymorphisme, mécanismes d'héritage), mais présentent en outre des caractéristiques facilitant la composition, la réutilisation et l'évolution:

  • outils pour la composition: description des interfaces requises, notion de connecteur (objet de communication entre composants), outils de description globale d'architecture, etc.
  • outils pour l'évolution dynamique: interfaces spécialisées pour la modification, la gestion du cycle de vie; possibilités de liaison dynamique de code, etc.
  • outils pour l'expression du comportement des composants et notamment de leurs propriétés non-fonctionnelles, telles que la qualité de service, la disponibilité, la sécurité.
  • mécanismes d'autodescription, permettant de découvrir, en cours d'exécution, des propriétés du composant (spécification d'interface), en vue par exemple de la construction dynamique d'appels.
Les environnements à base de composants comportent en outre des ``structures d'accueil'', qui facilitent la tâche du constructeur d'application en fournissant, pour un ensemble de composants, des services communs tels que la persistance ou les transactions. Les Enterprise Java Beans (EJB) sont un exemple d'un tel environnement.

La caractérisation ci-dessus n'est qu'indicative. En effet, la notion de composant n'est pas stabilisée et fait encore l'objet de discussions, notamment au sein des instances de normalisation telles que l' Object Management Group (OMG).

Nous avons choisi de privilégier deux domaines de recherche autour des composants logiciels : 1) l'élaboration de modèles de composants, la définition des architectures logicielles, les langages pour la composition d'applications et l'expression des propriétés ; 2) les mécanismes de base et le support système pour l'adaptabilité (mobilité, duplication, reconfiguration).

Nous développons ci-après ces deux domaines, avec un accent particulier sur les aspects touchant la répartition.

  1. Architectures logicielles : modèles et langages.

  2. La description globale d'une application fait intervenir trois types d'entités[SDK+95]: les composants proprement dits; les connecteurs, qui représentent les interactions entre les composants; et enfin les configurations, qui définissent la structure globale d'une application au moyen de composants et de connecteurs. Ce schéma de description peut être utilisé récursivement (une configuration pouvant être utilisée comme composant dans une description à plus gros grain).

    Les langages de description d'architecture ( Architecture Description Languages, ou ADL) sont des notations permettant de décrire formellement des applications structurées selon le schéma ci-dessus. Il en existe une grande variété selon le mode de définition des composants et connecteurs, et selon la sémantique attachée à la description. Les ADL les plus simples ont une sémantique très pauvre, la seule information étant la signature des interfaces. Des langages plus élaborés permettent une spécification du comportement. Les travaux récents visent à spécifier les propriétés dites ``non-fonctionnelles'' (performances, sécurité, disponibilité) au moyen d'interfaces supplémentaires associées aux composants. C'est par exemple la démarche de l' Aspect Oriented Programming[KLM+97] ou des langages de spécification de la qualité de service[FK99]. Néanmoins, ces propriétés restent attachées aux composants et sont encore peu intégrées dans les ADL.

    Outre leur intérêt pour l'aide au développement et à la maintenance des applications, les ADL peuvent servir, selon leur nature, pour la vérification formelle de propriétés, ou pour l'aide à la génération de programmes permettant d'administrer les applications, tels que des scripts d'installation ou de reconfiguration. Les travaux de Sirac sur l'environnement Olan [4] ont suivi cette dernière voie.
     

  3. Mécanismes pour l'adaptabilité.

  4. L'objectif est ici de permettre à une application répartie, supposée organisée comme un assemblage de composants, d'adapter son comportement à des modifications de son environnement ou de ses conditions d'utilisation. La réactivité étant une qualité requise dans beaucoup d'applications, il est souhaitable que cette adaptation puisse être réalisée dynamiquement.

    L'adaptation utilise différents mécanismes: évolution, remplacement ou suppression de composants existants, introduction de nouveaux composants, migration de composants d'un site à un autre, duplication de composants, modification des connexions entre composants.

    Une voie d'approche pour l'évolution dynamique des composants consiste à leur associer un ``méta-protocole'' comportant des primitives pour l'observation et la modification, en cours d'exécution, de certaines caractéristiques spécifiées. L'introduction de mécanismes de réflexivité[KJB91] dans les langages de programmation permet aussi d'atteindre cet objectif. L'adaptabilité peut également s'appliquer aux composants de l'infrastructure ( middleware); le système doit alors lui-même être extensible. Toutes ces formes d'adaptabilité sont considérées dans le projet Sirac.

    La modification des composants n'est pas toujours possible, notamment lorsque l'on ne dispose pas des sources ou des droits d'accès nécessaires. Une approche consiste alors à interposer dans le schéma global de l'application des entités réactives chargées d'intercepter des événements significatifs et d'y réagir de manière appropriée. Cette méthode permet de localiser les fonctions d'adaptation dans ces entités intermédiaires, ``agents'' ou représentants ( proxies), et elle a été notamment utilisée pour garantir la qualité de service dans des applications mobiles[GWBC99]. Nous l'avons appliquée avec succès dans un travail mené en collaboration avec Bull dans le cadre du GIE Dyade (voir 7.1).

    La migration de composants d'une application ou d'entités intermédiaires fournit un moyen d'améliorer les performances d'une application répartie, par exemple en rapprochant un programme des données qu'il doit traiter, ou en réagissant à des variations de performances d'un réseau. La réalisation pratique de cette mobilité pose néanmoins des problèmes délicats, que nous avons abordés dans nos travaux récents:

    • Gestion du contexte. Déplacer un composant en cours d'exécution nécessite de capturer son état instantané et de reconstituer cet état sur le site de destination.
    • Protection. L'intégration, sur un site, de code d'origine externe, nécessite de trouver un compromis entre une isolation sévère du code importé, qui réduit son utilité, et une large ouverture, qui risque de compromettre la sécurité.

    •  
    Enfin, la reconfiguration d'une application (modification dynamique d'une configuration) peut être facilitée par l'existence d'une description globale sous la forme d'un ADL. C'est également la démarche suivie dans Sirac; une application pratique est mentionnée en 7.2.

Construction d'applications réparties - Résultats récents

Résumé :

L'objectif est de fournir des outils et services pour le développement et l'exécution d'applications réparties adaptables. Nous avons développé et validé expérimentalement plusieurs méthodes pour faciliter l'adaptabilité des applications selon trois directions : a) Extensibilité (possibilité d'inclure dynamiquement de nouvelles fonctions dans un composant). b) Mobilité du code et des données. c) Reconfiguration (méthodes permettant d'apporter des modifications de composition ou de structure à une application construite par assemblage de composants).

Dans le cadre d'actions contractuelles avec des partenaires extérieurs, nous avons commencé à expérimenter les méthodes et outils ci-dessus sur diverses plates-formes expérimentales, existantes ou en cours de mise en place : environnements étendus pour Enterprise Java Beans, bus logiciel à agents, environnement pour applications à base de cartes à puce.


 

Dans de nombreux domaines d'application de l'informatique répartie, on constate une évolution de plus en plus rapide des besoins et des conditions d'utilisation. Le développement d'applications réparties adaptables vise à y répondre. L'adaptation peut prendre différentes formes (changement de structure, de contenu, de localisation des programmes ou des données, etc.). Des exigences de réactivité imposent souvent une adaptation dynamique.

L'objectif de nos travaux dans ce domaine est de développer des méthodes et outils pour faciliter l'adaptation des applications réparties conçues à base de composants. Les domaines d'applications visés sont prioritairement (mais non exclusivement) ceux des applications dites mobiles, dans lesquelles les utilisateurs et/ou des composants matériels ou logiciels de l'application peuvent se déplacer.

1.  Méthodes et outils pour l'extensibilité

Participants : Eric Bruneton, Fabienne Boyer, Daniel Hagimont, Vania Marangozova, Michel Riveill.

Cette recherche vise à étudier les mécanismes de base pour produire des applications configurables et extensibles. Nous avons développé un environnement expérimental pour la construction de telles applications, sous la forme d'une extension de l'environnement Java appelée JavaPods, qui comporte les éléments suivants :

  • Un schéma de programmation permettant de construire des applications comme composition d'entités appelées pods. Un pod est un regroupement d'objets Java, localisé sur un site, auquel est associée une interface fournie (utilisable depuis l'extérieur), une interface requise (services nécessaires au bon fonctionnement du pod), et un ensemble de propriétés, dites non-fonctionnelles car elles n'apparaissent pas directement dans les interfaces (elles sont réalisées par des méta-objets associés aux pods). Des exemples de propriétés sont la persistance, la mobilité (capacité de migrer d'un site à un autre), le mode d'exécution (autonome ou non), la sécurité, etc.
  • Un noyau (réparti) fournissant un support à l'exécution et réalisant les propriétés associées aux pods. Ce noyau est adaptable, c'est-à-dire qu'il est possible de modifier son comportement, par exemple en changeant la valeur de certains attributs, et extensible, c'est-à-dire qu'il est possible de lui ajouter dynamiquement de nouvelles fonctions. Ces fonctions deviennent par là même accessibles aux pods qui utilisent le noyau. La communication entre pods est réalisée au moyen d'objets de liaison (connecteurs), qui encapsulent les protocoles de communication. Ces objets sont eux-mêmes adaptables et extensibles; on peut ainsi spécifier et modifier les propriétés de la communication (synchrone ou asynchrone, point à point ou diffusion, etc.).
  • Une extension du langage Java ( ejava) servant à programmer les services extensibles du noyau; cette extension n'est pas destinée à programmer les applications, qui sont écrites en Java avec les conventions propres aux pods.
Une expérience préliminaire d'utilisation des JavaPods (serveur vidéo) a montré que les outils fournis facilitent effectivement l'adaptation des applications. Le travail en cours porte sur la consolidation des concepts, l'amélioration des mécanismes de base et la poursuite de l'évaluation. Nous comptons par ailleurs réutiliser dans d'autres contextes les méthodes ici développées.

2.  Méthodes et outils pour la mobilité et la duplication

Participants : Sara Bouchenak, Daniel Hagimont, Fabienne Boyer, Leila Ismail, Vania Marangozova, Michel Riveill.

La mobilité des données, associée à des techniques de gestion de caches répartis, permet à la fois de diminuer la latence d'accès aux informations et de modifier dynamiquement l'environnement d'exécution d'une application pour répondre à des besoins changeants. La mobilité du code permet de déplacer dynamiquement l'exécution d'un processus client vers un serveur de données pour remédier à la variabilité des performances d'un réseau.

Nous travaillons dans trois directions.

  • Mobilité de processus dans la machine Java. La réalisation de la mobilité des processus nécessite de pouvoir déplacer le contexte complet d'un processus en cours d'exécution (contenu de la pile), ce que ne permet pas la machine Java. En conséquence, les systèmes actuels à agents mobiles construits sur Java ne fournissent qu'un mécanisme de migration faible ne déplaçant qu'un ensemble d'objets et le code associé, sans le contexte d'exécution des processus. Nous avons étendu la machine virtuelle Java pour fournir un mécanisme de migration forte. Le travail en cours porte sur l'amélioration des performances de la migration et sur l'étude d'autres techniques ne modifiant pas la machine virtuelle Java.
  • Duplication de données. Nous avons développé en 1998 un environnement d'exécution fournissant aux programmeurs d'applications l'abstraction d'une mémoire d'objets Java répartis, grâce à une extension du mécanisme d'appel Remote Method Invocation réalisant une mise en cache des données, avec gestion de leur cohérence. Nous étudions actuellement l'utilisation de cette technique (combinée avec la mobilité de code) dans différents contextes: extensions des Enterprise Java Beans, environnement pour une application de télé-enseignement.
  • Évaluation de techniques de mobilité de code. Dans le domaine du code mobile, peu de travaux ont été réalisés pour évaluer les gains de performances apportés par la migration. Pour apporter des éléments d'évaluation, nous avons réalisé sur la machine virtuelle Java une plate-forme d'agents mobiles, qui implante les fonctions de déplacement des agents permettant de réaliser des applications élémentaires. Notre expérience montre que, dans certaines conditions (interactions fréquentes, débit modéré), l'usage d'agents mobiles apporte un gain significatif par rapport au schéma client-serveur classique. Ce travail doit se conclure en 2000 avec la thèse de L. Ismail.

3.  Méthodes et outils pour la reconfiguration

Participants : Luc Bellissard, Noël De Palma, David Féliot, Michel Riveill.

Nous travaillons dans trois directions:

  • Modèles de composants reconfigurables. Nous avons proposé des modèles de programmation de composants permettant leur reconfiguration. Chaque composant est capable d'arrêter son exécution de manière ``propre'' afin d'être remplacé, déplacé, dupliqué, sans que le fonctionnement et la sémantique de l'application soient affectés. Trois modèles de composants ont été expérimentés: sur une plate-forme Corba, sur une plate-forme Java/RMI et sur le bus à agents AAA. Le travail en cours porte sur le lien entre la programmation des composants et les contraintes imposées pour faire de la reconfiguration dynamique avec notamment le modèle ARI (reliable Asynchronous Remote Invocation en Java).
  • Algorithmes de reconfiguration dynamique. Nous avons proposé un algorithme de reconfiguration dynamique pour des applications réparties à base d'agents. Cet algorithme s'appuie sur la connaissance de l'architecture de l'application, qui permet de minimiser la perturbation du fonctionnement de l'exécution lors d'une opération de reconfiguration. Un algorithme analogue a été appliqué à une plate-forme de type Corba. Il reste à développer et à évaluer un algorithme de reconfiguration générique (indépendant d'un modèle de programmation ou d'exécution particulier).
  • Outils et services de reconfiguration dynamique. Le développement d'outils est un élément essentiel de notre travail. Ce sont eux en effet qui permettent d'utiliser efficacement et correctement les mécanismes de reconfiguration dynamique, en garantissant la validité d'une opération de reconfiguration et en préservant le fonctionnement global de l'application répartie.

  •  
Le travail en cours vise à permettre au concepteur ou à l'administrateur d'une application de faire évoluer celle-ci en agissant sur l'architecture au travers d'une interface graphique très simple. L'outil développé permet également de coupler événements de surveillance de l'exécution et opérations de reconfiguration. Ce couplage est défini de manière déclarative (extension des langages de définition d'architecture pour décrire la dynamique d'une application) ou de manière programmatique (extension des modèles de composants afin de permettre la programmation de réactions selon le comportement dynamique de l'application).


 

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