Précédent : Logiciels Remonter : Action RUSKEN, Environnements pour le Suivant : Actions industrielles
Précédent : Logiciels Remonter : Action RUSKEN, Environnements
pour le Suivant : Actions industrielles
Les besoins en matière de suivi de la qualité de service reçue et offerte par les applications de travail coopératif ont nécessité la définition d'un nouveau modèle d'exécution de requête pour des architectures à objets réparties. Ce modèle d'exécution est fondé sur la notion de contrat entre un objet client et un système fournisseur de service. Dans le cadre de Rusken, le concept de contrat classique [Mey92] a été étendu par réification, pour permettre sa manipulation explicite lors de l'exécution du code des différents objets qui composent l'application. Dans le système que nous avons développé, un contrat est une classe d'objets qui permet de définir des propriétés d'exécution des services disponibles. Un contrat lie un objet client à un objet prestataire de service, en définissant les obligations de chacun, par exemple les pré- et postconditions d'exécution de méthode, les contraintes temporelles (délais ou instants) ou le degré d'exactitude d'une information (dernière valeur ou bien valeur approchée d'un résultat). La donnée de telles contraintes contribue à l'amélioration de la fiabilité des logiciels [RHG90]. Un apport important des travaux effectués dans Rusken sur ce concept de contrat est l'obtention de possibilités de configuration étendues. Les contrats sont paramétrables et extensibles par création de nouvelles sous-classes ou par assemblage d'objets spécialisés. Un autre aspect innovant du mécanisme de contrat défini dans Rusken est la prise en compte particulière des problèmes de répartition d'objets. En effet, gérer un contrat entre deux objets s'exécutant sur deux sites physiquement distants nécessite la définition de mécanismes spécifiques. Les difficultés inhérentes aux applications réparties (sensibilité aux variations de la qualité de service offerte par les systèmes de communication, défaillances de sites, partitions de réseaux) imposent la prise en compte de ces problèmes par le mécanisme de contrat. Le modèle proposé par Rusken offre une abstraction des divers aléas de communication via une extension du concept de contrat. En particulier, l'architecture d'exécution répartie Rusken comporte un système de configuration automatique des paramètres de contrats entre objets distants. Une mise en oeuvre répartie prenant en compte le temps physique a été réalisée [1] et intégrée à la plate-forme. Cette mise en oeuvre s'appuie sur le modèle de communication répartie time asynchronous [FC96]. La prise en compte des mécanismes de communication de groupe (gestion du consensus [GA96] en particulier) est actuellement en cours de réalisation, en coopération étroite avec les membres du projet ADP travaillant sur ce domaine.
Les applications de travail coopératif ont des caractéristiques spécifiques liées à la nature même du service qu'elles rendent. En effet, toute application de travail coopératif est à la fois parallèle (plusieurs utilisateurs l'utilisent simultanément) et répartie (les utilisateurs sont géographiquement dispersés). Comme pour toute application parallèle, il est nécessaire que le parallélisme soit parfaitement traité et maîtrisé pour assurer la cohérence et l'exactitude des résultats. Cependant, les modèles de contrôle du parallélisme exigés par les applications de travail coopératif diffèrent notablement de ceux plus fréquemment rencontrés dans les domaines du calcul parallèle ou des bases de données [Ela92]. L'échelle de temps est radicalement différente : les opérations concurrentes effectuées sur des données par des applications de travail coopératif peuvent durer de quelques secondes à quelques mois. Un mécanisme couramment utilisé dans un tel cas est le concept de transaction, qui permet d'imposer un ordre particulier aux opérations s'effectuant concurremment sur un groupe d'objets [PC94]. Pour les besoins de la plate-forme Rusken, un modèle de transaction spécialement adapté au travail coopératif a été défini et mis en oeuvre en Java. La caractéristique originale de ce modèle est le haut degré de découplage entre les objets sur lesquels s'appliquent les opérations et les mécanismes de contrôle du partage de ces données. Grâce à ce découplage, le concepteur d'application de travail coopératif dispose de nombreuses possibilités de configuration et d'extension. En particulier, le système de contrôle du parallélisme conçu dans Rusken permet de changer dynamiquement de politique de contrôle. Cette possibilité de changement joue un rôle important pour le suivi de la qualité de service dans une application de travail coopératif. Il est alors possible d'adapter à tout moment le comportement de l'application aux caractéristiques de son environnement d'exécution. Par exemple, une séance d'édition coopérative peut employer un mode de coopération où les conflits entre lecteurs et rédacteurs sont résolus par verrouillage. Réagissant à une défaillance partielle de réseau, l'application peut modifier le mode de coopération et utiliser des versions multiples pour ne pas bloquer les utilisateurs de l'éditeur.
![[*]](../icons/cross_ref_motif.gif){kind=icon}
), et
permet de s'adapter aux variations de la qualité de service
offerte par les couches logicielles et matérielles sous-jacentes
(réseau, puissance de calcul disponible). De plus, l'ensemble de
la scène tridimensionnelle peut être manipulée par les
utilisateurs ; par exemple, un utilisateur peut déplacer un
objet dans une pièce du bâtiment. Cette capacité d'interaction
multi-utilisateurs avec la scène est une réalisation originale de
Rusken. En effet, l'ensemble des modifications est montrée en
temps réel (avec un temps moyen de propagation des changements de
l'ordre de 0,5 à 1 seconde) à toutes les personnes naviguant dans
l'espace virtuel, avec des garanties de cohérence y compris en
cas de défaillance. En cas de défaillance ou de baisse trop
importante des performances du réseau, l'application de
navigation peut exclure temporairement des utilisateurs pour
préserver le temps de réponse globale. Grâce à l'emploi d'un
mécanisme de maintien du consensus réparti, les utilisateurs
perçoivent tous de façon uniforme les décisions de l'application
de navigation. Ainsi, les garanties sur la cohérence des
différentes vues améliorent beaucoup la confiance que les
utilisateurs ont de leur perception des évolutions de la scène
tridimensionnelle (par exemple, un problème de réseau n'est pas
interprété à tort comme une absence de réaction de certains
utilisateurs)[JB96]. La
gestion de la cohérence influe donc directement sur l'efficacité
de l'application de travail coopératif.
L'expansion très rapide des technologies de l'information et la concurrence intense qui règne en ce domaine rendent nécessaires des activités de veille scientifique et technologique. En 1997, les technologies liées au Web, à Java et à la description de scènes tridimensionnelles au moyen du langage VRML ont été particulièrement considérées. Ces technologies encore récentes possèdent des limites tant conceptuelles que de réalisation (nombreuses limitations des mises en oeuvre, bogues fréquentes). Ces limites sont difficiles à estimer sans une étude expérimentale sérieuse. C'est pourquoi de nombreux essais ont été réalisés parallèlement aux travaux de conception et de réalisation de la plate-forme proprement dite.
Précédent : Logiciels Remonter : Action RUSKEN, Environnements
pour le Suivant : Actions industrielles