Précédent : Présentation générale et
objectifs Remonter : Projet SIRAC, Systèmes Informatiques Répartis
Suivant : Grands domaines d'application
Mots-clés : programmation
constructive, composants, objets, agents, intégration
d'applications, configuration, appel de procédure à distance,
code mobile
Résumé : Le thème de la construction d'applications réparties est développé selon deux axes principaux.
- 1.
- Programmation constructive. Étude des méthodes et outils permettant de décrire, de construire, et de faire évoluer des applications réparties organisées comme un ensemble de composants interconnectés. Un accent particulier est mis sur la réutilisation et l'adaptation des applications existantes.
- 2.
- Code mobile. Étude des méthodes et outils permettant d'exploiter les techniques de mobilité du code pour développer des applications réparties sur l'Internet. Le travail porte sur le support d'exécution et sur la protection.
Les classes d'applications visées sont celles présentant des besoins importants de coordination d'activités et de partage d'information.
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 fournis par le système
de communication, c'est-à-dire essentiellement les messages. À
partir de ce stade initial, les efforts ont principalement visé
à
Les objectifs c) et d) 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é.
Une étape importante pour les objectifs a) et b) a été
l'introduction de l'appel de procédure à distance [BN84]. Ce mécanisme permet de
réaliser des applications selon le schéma client-serveur, qui
reste le plus utilisé pour la structuration des applications
réparties. L'étape ultérieure, à partir du milieu des années
1980, a été l'introduction des modèles à objets pour la
programmation répartie. Les efforts ont porté d'une part sur le
mode d'expression (langages et outils divers pour la
programmation à base d'objets répartis), d'autre part sur les
mécanismes de base (au niveau du système d'exploitation et des
communications) permettant de mettre en oeuvre des objets
répartis. Le projet Guide (dont est issu le projet Sirac) a
apporté sa contribution à ces efforts : langage [2], support d'exécution
([1], [4]). Une rétrospective de ces
contributions est donnée dans [10]. Des approches
similaires ont été suivies par la communauté scientifique, parmi
lesquelles on peut citer le projet Spring [MGH94]. Ces
recherches ont conduit au développement de la norme
d'interconnexion Corba dans un premier temps, et à l'émergence du
langage Java dans un deuxième temps. Dans ces approches,
qualifiées d'intégrées, le système est vu comme le support
d'exécution du langage de programmation répartie. L'expérience
d'utilisation de ces systèmes a montré que les objectifs a) et b)
étaient remplis de façon très satisfaisante pour des applications
nouvelles développées en utilisant le modèle d'objets défini par
le langage adopté. En revanche, leur utilisation à grande échelle
se heurte à quelques obstacles de fond tels que : l'adoption
d'un langage nouveau, l'intégration de modules logiciels
existants, la nécessité d'installer le support d'exécution sur
toutes les machines du système réparti, et l'administration des
applications. Ce dernier aspect met en évidence une limitation
inhérente aux approches fondées sur les objets et le chargement
dynamique de code. En effet, la notion même d'application est
difficile à définir précisément car cela requiert d'identifier
les objets qui composent une application. La procédure
d'installation (on parle aussi de déploiement) de ces objets sur
les sites qui composent le système réparti est également un
problème difficile.
Ces observations ont conduit la communauté scientifique à
aborder la construction des applications réparties d'un point de
vue plus macroscopique (programming in the large). Une
application est vue comme un assemblage de composants (modules
logiciels écrits dans un langage quelconque), dont certains
peuvent être des applications existantes. Un formalisme,
indépendant des langages de programmation, permet de décrire les
modules qui composent une application et les liens entre ces
modules. On dénote ces formalismes sous le terme générique de
langage de configuration ou encore de langage de
description d'architecture. Les travaux précurseurs de cette
approche sont issus des projets Conic [KMS89] et Polylith [Pur94]. Les recherches
s'orientent aujourd'hui dans deux directions : a) des
travaux à caractère fondamental portant sur les modèles de
description d'application, avec le souci de fournir un support
pour le contrôle de la correction sémantique des applications
(modèle d'exécution, compatibilité des types dans les
interactions entre modules, etc.); b) des travaux à caractère
plus appliqué portant sur les outils de génération de code et
d'administration des applications.
La contribution du projet Sirac s'inscrit dans ce dernier
courant et concerne, de façon plus générale, des outils de
configuration d'applications. Le terme
configuration est pris ici dans une double
acception : au sens du génie logiciel, il s'agit de définir
les modules logiciels qui composent une application et de fournir
en résultat le code exécutable de cette application; au sens
``administratif'' du terme, il s'agit de faciliter l'installation
des modules sur les sites d'exécution et de contrôler l'évolution
ultérieure de la configuration de l'application. Ces outils sont
intégrés au sein d'un environnement de développement, Olan
[3], dont il existe
aujourd'hui une version expérimentale pour des plates-formes Unix
(cf ).
Une application répartie est un assemblage de composants; le
modèle décrit ces composants et les liens existant entre eux. La
description d'un composant distingue son interface et son
implémentation. L'interface décrit les services fournis
par le composant et les conditions requises par son utilisation,
et comporte un ensemble d'attributs utilisés pour le contrôle et
l'administration du composant. Les composants peuvent être
primitifs, encapsulant un module logiciel (par exemple une
application existante ou une bibliothèque) écrit dans un langage
de programmation quelconque, ou complexes, c'est-à-dire
construits comme une hiérarchie de composants interconnectés. La
description des liens entre composants repose sur le concept de
connecteur, trait d'union entre la description d'un
service requis par un composant et celle d'un service fourni par
un autre composant. Le protocole de communication, la
correspondance des types des paramètres, et les conditions
d'exécution (synchronisation, droits d'accès, etc.) sont des
éléments attachés à la description d'un connecteur.
En ce qui concerne les perspectives de recherche dans le domaine de la construction d'applications réparties, nous avons privilégié deux directions, que nous résumons brièvement.
Une méthode pour réaliser l'évolution incrémentale
consiste à interposer dans le schéma global de l'application
(supposée décrite par un modèle à composants) des entités
réactives (``agents'') chargées d'intercepter des événements
significatifs (par exemple en analysant le contenu d'un
message ou les paramètres d'un appel de fonction) et d'y
réagir de manière appropriée. Une expérience préliminaire (cf
) menée dans
l'environnement Olan a permis de montrer la viabilité de
cette démarche.
Le langage Java possède les propriétés intéressantes des
langages de programmation d'applications réparties cités
précédemment (séparation type-classe, sous-typage, expression
de la synchronisation, liaison dynamique, etc.). Un certain
nombre des inconvénients associés à ces langages ont disparu
du fait de l'existence d'une machine virtuelle ``normalisée''
[LY96]. C'est
pourquoi l'idée d'un système d'exploitation adapté à la
gestion d'objets Java a refait surface sous la forme du
système JavaOS [Rit97], disponible sur
machine nue, et conçu comme un noyau de système pour
l'exécution de la machine virtuelle Java. L'expérience
récente du projet Guide, dont on rappelle qu'il était fondé
sur des principes de structuration et une architecture très
proches de Java, nous conduit naturellement à explorer les
principes de réalisation d'un système de gestion d'objets
Java répartis et partagés (cf ). Le bénéfice attendu de
ce travail est la possibilité de réaliser, à l'aide du
langage Java, des applications mettant en jeu des objets
partagés et répartis sans souci de la localisation des objets
(transparence de la distribution).
Un fil directeur commun aux deux directions ci-dessus pourrait
être la notion d'agent, définie comme entité autonome
pouvant réagir à des événements et pouvant éventuellement se
déplacer. La mise en oeuvre d'applications à base d'agents
suscite un grand intérêt [ic997], et soulève des problèmes
d'environnement de programmation, de support d'exécution, et de
sécurité.
Mots-clés : gestion de mémoire, grappes, clusters,
protection, capacités, gestion de caches, mémoire virtuelle
répartie
Résumé : Les recherches visent à exploiter le potentiel des grappes de machines (clusters) pour la construction de serveurs d'informations. Trois aspects sont particulièrement explorés.
- 1.
- Gestion des ressources. Étude des politiques de gestion de ressources (notamment de gestion de mémoire) permettant de fournir une interface simple aux applications tout en garantissant des performances acceptables.
- 2.
- Communication à hautes performances. Construction de services système permettant d'exploiter le potentiel des réseaux d'interconnexion à haut débit et faible latence, pour la coordination d'activités et le partage d'information.
- 3.
- Protection. Étude des politiques et mécanismes de protection permettant de gérer des données partagées entre des applications, avec des contraintes de méfiance mutuelle.
Un nombre croissant d'applications font appel à des serveurs devant manipuler des volumes d'information très importants pour fournir des services à un grand nombre de clients. Des exemples en sont les bases et entrepôts de données, les serveurs pour le Web (serveurs primaires et serveurs de caches), les serveurs répartis de fichiers.
Pour répondre à ces besoins, on voit se développer des architectures en grappes (clusters) regroupant un ensemble de serveurs homogènes reliés par un réseau à hautes performances. Les avantages attendus sont les suivants.
Le développement du logiciel de base pour l'exploitation des machines en grappes demeure une tâche difficile. Les recherches actuelles visent à exploiter au mieux les possibilités de la technologie, et notamment les deux avancées suivantes.
Les principales directions de recherches actuellement poursuivies sont indiquées ci-après.
Les caches logiciels constituent le moyen privilégié de réduction de la latence pour l'accès à l'information dans un système réparti. Un cache est une zone de mémoire dans laquelle sont conservées les informations ayant fait l'objet d'accès récents. Comme les applications présentent en général la propriété de localité de référence, les informations en cache ont une probabilité élevée d'être réutilisées.
Dans un système de gestion de mémoire pour grappe de machines, chaque machine gère son propre cache, et il se pose alors deux problèmes.
Les problèmes de cohérence de cache ont été beaucoup étudiés dans les travaux sur les multiprocesseurs et sur la mémoire virtuelle répartie. Il est très coûteux de maintenir une cohérence stricte, mais, en fait, de nombreuses applications peuvent se contenter d'une cohérence relâchée, dont il existe plusieurs définitions. Les meilleurs résultats sont obtenus quand on peut relier la définition de la cohérence à celle de la synchronisation pour l'accès aux variables partagées, et, plus généralement, quand on peut prendre en compte les besoins spécifiques d'une application.
En ce qui concerne la gestion de l'information dans les
caches, une voie explorée est celle des caches coopératifs
[DWAP94]. L'idée
consiste à utiliser les informations présentes dans les caches
des machines distantes, sachant qu'il peut être plus rapide de
charger une information depuis le cache d'une autre machine que
depuis le disque local. En poursuivant sur cette voie, on arrive
à la notion d'un service de gestion de mémoire gérant globalement
l'ensemble des caches comme une ressource unique. Un exemple de
tel service est GMS [FMP95].
Une autre voie pour l'amélioration de l'efficacité des caches
est celle du préchargement. Néanmoins, cette technique doit être
utilisée à bon escient, car les erreurs de préchargement sont
très coûteuses. Une idée prometteuse est celle du préchargement
sur information [PGG95] :
les applications fournissent des informations sur leurs accès aux
données (données utilisées, corrélations entre données, durées de
vie probable, etc); ces applications sont exploitées pour le
préchargement et la conservation en cache des informations.
La contribution du projet Sirac à ces travaux est le mécanisme de
cohérence ``sur mesure'' [11] introduit dans la gestion des
caches du service de mémoire répartie Arias (voir ). Plutôt que d'imposer une
politique prédéfinie pour la gestion de la cohérence des caches,
il est proposé un ensemble de primitives à partir desquelles on
peut construire un protocole spécifique adapté aux besoins d'une
application. Initialement introduits pour la gestion de la
cohérence, les protocoles spécifiques sont également utiisés pour
la gestion des données permanentes. Leur champ d'application
pourrait être étendu au préchargement des données et à la gestion
coopérative des caches.
La gestion de données partagées entre plusieurs applications, sur une ou plusieurs machines, pose le problème de leur protection. Ce problème est d'autant plus difficile à résoudre que le degré de couplage entre applications est fort, ce qui est le cas dans les systèmes répartis actuels. Deux exemples de couplage fort sont l'implantation de données dans une mémoire virtuelle partagée répartie, et l'utilisation de programmes exécutables mobiles chargés depuis une machine distante et accédant à des données locales. Dans ces deux cas, le système de protection doit permettre la coopération, tout en répondant à des exigences de méfiance mutuelle (situation où deux entités coopèrent, chacune protégeant ses données contre les erreurs ou malveillances de l'autre).
Des mécanismes à base de capacités logicielles ont été proposés depuis longtemps pour assurer la protection avec méfiance mutuelle. La transmission de capacités entre domaines de protection permet de modifier dynamiquement les droits d'accès. Les capacités ont récemment été réintroduites dans les systèmes répartis (voir par exemple [CLFL94]). L'inconvénient des mécanismes courants est qu'ils obligent les programmes d'applications à manipuler directement les capacités, ce qui rend ces programmes difficilement modifiables et réutilisables.
La contribution de Sirac à ce problème est la proposition
d'utiliser des capacités logicielles ``cachées'' [5], c'est-à-dire non visibles
dans les programmes des applications. L'association des capacités
aux programmes se fait par des annotations ajoutées à un langage
de définition d'interfaces. Ce mécanisme a pu être validé par des
expériences menées dans trois environnements répartis différents
(voir ,
).
Les avantages attendus des grappes de machines nécessitent un mécanisme d'interconnexion à hautes performances. Un débit élevé est nécessaire quand un volume important d'information doit être transféré; une latence faible est nécessaire pour des échanges fréquents de faible volume comme les messages de commande utilisées pour la gestion interne du système.
Plusieurs technologies de réseaux d'interconnexion sont récemment apparues et sont expérimentées. Citons ATM, Myrinet, MemoryChannel. Elles utilisent des techniques de commutation, ce qui assure une bonne capacité de croissance. Le problème principal est la conception et la réalisation d'un service de communication logiciel qui permette, au niveau des applications, d'exploiter aux mieux les performances brutes autorisées par le matériel.
La technologie SCI (Scalable Coherent Interface) repose sur un couplage direct de mémoire à mémoire entre deux machines. Ce dispositif permet à un processeur de lire et d'écrire physiquement dans la mémoire d'un autre processeur sans l'interrompre. Par rapport à d'autres systèmes d'interconnexion, SCI fournit des performances brutes élevées, tant en débit qu'en latence.
Le projet Sirac a récemment lancé une action de recherche
visant à explorer le potentiel de SCI pour la réalisation de
grappes de serveurs à hautes performances. Le problème posé est
celui de la réalisation de services de base pouvant être intégrés
à un système d'exploitation, pour réaliser le partage de mémoire
et la synchronisation d'activités. Il est prévu d'utiliser des
techniques inspirées de celles de GMS (cité plus haut) pour la
gestion globale de la mémoire de la grappe. Les classes
d'applications visées sont celles qui nécessitent l'accès
efficace à de grandes quantités d'information (serveurs Web,
systèmes de fichiers). Le plan de travail proposé est indiqué en
.
Mots-clés : réseaux sans fil, stations mobiles, IP mobile,
qualité de service
Résumé : L'objectif de cet axe de recherche est de développer des protocoles et des services systèmes pour exploiter au mieux les capacités des réseaux sans fil dans le but de fournir l'accès à l'Internet depuis des postes mobiles.
Le développement rapide de la téléphonie mobile présage une
nouvelle ère : comme beaucoup l'annoncent déjà, le 21ème
siècle sera celui des services mobiles. Il sera bientôt
possible, à partir d'une machine portable équipée d'une antenne,
de se connecter à l'Internet pour y réserver un billet d'avion,
pour lire son courrier électronique, ou pour chercher une
information sur le Web, tout en se déplacant à travers le monde.
Très probablement, ces connexions n'utiliseront pas un unique
réseau homogène, mais plutôt une combinaison de réseaux de
différents types (GSM, CDPD LAN sans fil, Metricom, réseaux
satellitaires, etc.) constituant globalement un ``réseau mobile
virtuel''. Du fait que les différents réseaux physiques sont
fondés sur des technologies variées, les caractéristiques (bande
passante, délai de transmission, gigue, taux de perte, etc.) de
ce réseau virtuel sont très variables. Cette hétérogénéité pose
de nouveaux types de problèmes du point de vue des services de
communication et des applications.
Dans un contexte de réseaux sans fil, le projet Sirac
s'intéresse plus particulièrement à la gestion de la
mobilité avec, pour objectif général, l'obtention de la
meilleure qualité de service (QoS) possible pour l'utilisateur
par l'optimisation des ressources du réseau virtuel en termes de
coût et d'efficacité. Sous le terme de station mobile, on
désigne une station qui change de point de connexion. Le
changement de point de connexion peut prendre plusieurs
formes : changement des paramètres réseau, tels que
l'adresse ou les tables de routage, changement de la nature de la
liaison (GSM, WLAN, satellitaire, fixe, etc.). Ces évolutions
doivent se faire avec l'objectif de fournir à l'utilisateur un
service aussi continu que possible.
Il y a plusieurs manières d'aborder ce problème selon qu'on
privilégie la transparence vis-à-vis des changements de réseau ou
l'efficacité globale. Par ailleurs, le support de la mobilité
peut être mis en oeuvre à divers niveaux des systèmes de
communication : couche réseau (IP), couche transport (TCP,
et application. Ces approches ne sont pas exclusives les unes des
autres et peuvent être combinées au sein d'une solution globale
du problème de la gestion flexible de la mobilité.
Afin d'aborder ces problèmes dans un ordre croissant de
complexité, le projet Sirac étudie dans un premier temps des
solutions applicables au niveau IP. Le protocole Mobile IP,
défini par l'IETF (Internet Engineering Task Force),
permet à un utilisateur de rester accessible et connecté à
l'Internet quelle que soit sa localisation physique. La solution
adoptée dans Mobile IP consiste à définir un lien de
poursuite sur le site d'origine, chargé de rediriger les
paquets reçus vers le point d'attachement courant de la station
mobile. Cette solution simple ne fournit pas la flexibilité
requise pour assurer une utilisation optimale des services et
ressources disponibles sur une large variété de réseaux sans fil.
Deux propriétés nous paraissent importantes pour atteindre
l'objectif de flexibilité : d'une part la possibilité de
s'adapter aux caractéristiques du réseau utilisé, et d'autre part
la capacité d'utiliser plusieurs interfaces de réseau
simultanément. Dans sa définition actuelle, Mobile IP ne permet
l'utilisation que d'un seul réseau à un instant donné. Cette
limitation est trop restrictive dans un environnement où la
diversité des services ne fait que croître. Nous pensons qu'un
utilisateur mobile devrait pouvoir utiliser différents services
et réseaux pour chacun des flots de ses applications, le choix
d'un système de communication pouvant être dicté par des
considérations de performance ou de coût.
La gestion des stations mobiles dans l'Internet est une problématique relativement récente. Des solutions assez différentes sont explorées par diverses équipes de recherche, principalement aux USA. Le projet Barwan de l'université de Berkeley fonde son approche [SK97]sur le déploiement de stations de base pour le contrôle de la mobilité. C'est une solution que nous avons rejetée car elle n'est pas compatible avec les infrastructures disponibles actuellement en Europe. Le projet MosquitoNet [CB96] de l'université Stanford a développé un système qui permet à une station mobile de choisir l'interface réseau d'émission en un point donné. Ce système constitue le point de départ de notre étude qui vise à l'étendre en donnant la possibilité de gérer simultanément plusieurs interfaces réseau pour différents flots de données. La réalisation de cet objectif requiert, d'une part l'extension des fonctions du protocole Mobile IP, et d'autre part la conception de services systèmes permettant d'identifier les réseaux disponibles, leurs caractéristiques et de sélectionner le ou les réseaux les mieux adaptés aux qualités de services requises par les différentes applications.