Universit dvry-Val dEssonne Institut National des Tlcommunications

Rapport de Stage DEA dInformatique

DANS LES SYSTMES RPARTIS : LE DPLOIEMENT SUR LE TERMINAL MOBILE

M OBILIT

Nabil KOUICI

Responsable de DEA : Jean-Marc D ELOSME Responsable de stage : Denis C ONAN

Juillet 2002

Ce stage de DEA a t ralis au sein du laboratoire Systmes Rpartis du dpartement Informatique de lInstitut National des Tlcommunications

Remerciements
Je tiens remercier, Guy Bernard pour mavoir accueilli dans lquipe Systme Rpartie de lInstitut National des Tlcommunications. La grande qualit de ses enseignements en DEA ma convaincu de me consacrer aux systmes rpartis. Je remercie Denis Conan pour avoir propos ce stage et mavoir encadr pendant ces cinq mois. Quil soit remerci pour son contact chaleureux, ses conseils et encouragements, son soutien permanent et pour la libert de recherche quil a bien voulu me laisser. Je le remercie de mavoir accord le temps ncessaire pour sentretenir avec moi et morient vers le bon chemin dans la recherche. Merci tous ceux qui de prs ou de loin mont aid pendant cette priode. En particulier, les personnes du dpartement informatique et les tudiants du DEA dvry en stage lINT, avec qui les discussions sur les sujets de recherche de chacun ont apport des ides et des points de vue diffrents. Un grand MERCI aux thsards rik Putrycz, Olivier Villin et Victor Budau dont laide a t toute aussi prcieuse. Je remercie enn, mes parents, mes frres, mes surs et mes amis qui mont soutenu tout au long de ce stage.

ii

Table des matires

1 2 Introduction Problmatique et objectifs du stage 2.1 Sujet du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Rsum du contexte du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . tat de lart sur la mobilit 3.1 Paradigmes des modles client-seveur mobiles . . . . . . . . . . . . . . . . . . . . 3.1.1 Adaptation des applications mobiles . . . . . . . . . . . . . . . . . . . . . 3.1.2 Extension des modles client-serveur . . . . . . . . . . . . . . . . . . . . 3.2 tude de projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Coda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1.1 Opration dconnecte et mode faiblement connect . . . . . . . 3.2.1.2 Gestion du cache du client mobile . . . . . . . . . . . . . . . . 3.2.1.3 Dtection et rsolution des conits . . . . . . . . . . . . . . . . 3.2.2 Odyssey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2.1 Agilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2.2 Description dOdyssey . . . . . . . . . . . . . . . . . . . . . . 3.2.2.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Bayou . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Rover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4.1 Objets dynamiques r-adressables et appel de procdure distance non-bloquant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5 Autre projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Pas de cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Mise en cache systmatique . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Mise en cache la demande . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Pr-chargement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture de Domint 4.1 Les intercepteurs portables . . . . . . . . . . . . . . . . 4.1.1 Intercepteur de requtes . . . . . . . . . . . . . 4.1.1.1 Intercepteur ct client et ct serveur 4.1.1.2 Informations sur la requte . . . . . . iii 1 3 3 4 5 5 5 6 6 7 7 7 8 8 9 9 9 10 10 11 11 12 13 13 13 14 14 14 15 17 17 17 18 18

. . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

4.2

4.1.2 Intercepteur de rfrences dobjets . . . . . . . Plate-forme Domint . . . . . . . . . . . . . . . . . . . 4.2.1 Architecture . . . . . . . . . . . . . . . . . . . 4.2.2 Quelques dtails sur les objets de Domint . . . 4.2.2.1 Gestionnaire dobjets dconnects . 4.2.2.2 Gestionnaire de ressources . . . . . 4.2.2.3 Gestionnaire de connectivit . . . . 4.2.2.4 Gestionnaire du journal doprations

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

19 19 20 21 22 22 22 23 25 25 25 27 28 30 30 30 31 32 32 34 34 35 37 39 39 40 40 42

5 Protocole de dploiement dobjets 5.1 Concept de criticit . . . . . . . . . . . . . . . . . . . . 5.1.1 Introduction du concept . . . . . . . . . . . . . 5.1.2 Objets critiques et Objets non critiques . . . . . 5.1.3 Exemple de partitionnement des objets . . . . . 5.2 Dploiement des objets critiques et non critiques . . . . 5.2.1 Dploiement suivant la criticit des objets . . . . 5.2.2 Problme de connectivit . . . . . . . . . . . . . 5.3 tapes de conception . . . . . . . . . . . . . . . . . . . 5.4 Dploiement dans Domint . . . . . . . . . . . . . . . . 5.4.1 Architecture . . . . . . . . . . . . . . . . . . . . 5.4.2 Gestion du cache . . . . . . . . . . . . . . . . . 5.4.2.1 Algorithmes de gestion du cache . . . 5.4.2.2 Remplacement des objets non critiques 5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 Ralisation 6.1 Prototype de ralisation 6.2 Application exemple . 6.3 Mise en uvre . . . . . 6.4 Travail en cours . . . . 7

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Conclusion 43 7.1 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

iv

Table des gures

2.1 3.1 3.2 3.3 3.4 3.5 4.1 4.2 4.3 4.4 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 6.1 6.2 Positionnement du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les stratgies dadaptation . Les tats de Venus dans Coda Larchitecture dOdyssey . . Larchitecture de Bayou . . . Larchitecture de Rover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

. 6 . 8 . 10 . 11 . 12 . . . . . . . . . . . . . . . 18 20 21 23 26 27 28 30 31 32 33 34 35 37 38

Les points dinterception . . . . . . . . . . . . . . . . . . . . . . . . . . . Le comportement de Domint en mode fortement connect . . . . . . . . . . Le comportement de Domint en mode partiellement connect et dconnect Lhystrsis pour la gestion de la conectivit . . . . . . . . . . . . . . . . . Exemple de cration des objets dconnects . . . . . . . . La criticit des objets . . . . . . . . . . . . . . . . . . . . La propagation de la criticit entre classes . . . . . . . . . Le dploiement dobjets . . . . . . . . . . . . . . . . . . Les tapes de conception . . . . . . . . . . . . . . . . . . Le dploiement dans Domint au lancement de lapplication Lalgorithme de Dploiement des objets critiques . . . . . Linterface de lobjet dconnect . . . . . . . . . . . . . . La gestion du cache dans Domint . . . . . . . . . . . . . . La cration dun objet intermdiaire entre PI et RM . . . . Lalgorithme de gestion des objets non critiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Le prototype dimplmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Lapplication de messagerie lectronique . . . . . . . . . . . . . . . . . . . . . . . . 40

vi

Liste des tableaux

3.1 5.1 5.2 La mthode de dploiement dans les diffrents systmes . . . . . . . . . . . . . . . 15 Un exemple de partitionnement dobjets pour lapplication messagerie lectronique . 29 Un exemple de squences dinvocations des objet DossierModel et CarnetAdressePersonnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

vii

viii

Chapitre 1 Introduction
Ces dernires annes ont t marques par une forte volution des quipements utiliss dans les environnements rpartis. Nous sommes successivement passs de rseaux locaux des rseaux grande chelle (Internet), puis des rseaux sans l inter-connectant des machines mobiles comme des tlphones portables ou des assistants personnels numriques (PDA). Cette volution a abouti la dnition dune nouvelle technologie, qui se base sur linfrastructure des rseaux mobiles. Cette technologie est linformatique mobile dans laquelle lutilisateur peut continuer daccder linformation fournie par une infrastructure distribue, sans tenir compte de lemplacement de lutilisateur. Les techniques traditionnelles daccs linformation distribue se basent sur deux hypothses. Premirement, la localisation des utilisateurs dans le systme est stable. Deuximement, la connexion rseau est plutt stable en terme de performance et de abilit. Dans les environnements mobiles, la validit de ces deux hypothses est trs rare. Le problme qui se pose nest pas dans le matriel utilis mais dans le logiciel qui utilise ce matriel, pour le dveloppement des applications qui travaille en mode mobile. Linformatique mobile se distingue des mthodes classiques daccs linformation par quatre contraintes : Par rapport aux lments statiques, les lments mobiles sont plus pauvres en ressources telles que la capacit de la mmoire et la vitesse dexcution. Les lments mobiles sont trs exposs aux vols et lendommagement. La connexion sans l est trs variable en terme de performance et de abilit. Les lments mobiles possdent des sources dnergie nies. Les machines mobiles devenant extrmement courantes, leur utilisation doit devenir aussi naturelle que possible. En dpit de tous les problmes mentionns ci-dessus, un utilisateur mobile souhaite se dplacer librement et continuer travailler le plus normalement possible avec son terminal mobile. Il est donc souhaitable de fournir une continuit de service malgr les dconnexions et les perturbations du rseau sans l. Le besoin de continuer travailler dans un environnement mobile soulve de nombreux problmes. Premirement, il est indispensable de grer la disponibilit des donnes en prsence de dconnexions. Lapproche visant rsoudre ce problme passe par une rplication le plus souvent locale des donnes sur le terminal mobile. Deuximent, il est galement indispensable que le systme et les applications soient ractifs aux changements de lenvironnement mobile. Le stage de DEA est effectu au sein de lquipe MARGE (Middleware pour Applications Rparties Grande chelle) de lInstitut National des Tlcommunications (INT) o des mcanismes ont t proposs pour rpondre aux besoins de disponibilit des donnes et de ractivit aux changements de lenvironnement mobile. Ces mcanismes sont mis en uvre au sein dune 1

plate-forme CORBA (Objects Request Broker Architecture) dnomme Domint. Les mcanismes principaux proposs par Domint sont, dune part, le support de la rplication des objets, et dautre part, le support des dconnexion volontaires et involontaires en utilisant des mcanismes CORBA tels que les objets par valeur et les intercepteurs portables. Ce document prsente lensemble du travail et des rsultats obtenus au cours de ce stage. Il sarticule autour du plan suivant. Dans le chapitre 2, nous examinons la problmatique et les objectifs du stage. Ensuite, le chapitre 3 prsente un tat de lart sur les environnements mobiles o nous tudierons quelques grands projets qui traitent le problme de la mobilit des applications. Dans le chapitre 4 nous donnons une courte prsentation de la plate-forme Domint. Ensuite, nous prsentons lapproche de dploiement et de gestion du cache que nous avons intgres dans Domint. Enn, pour dmontrer la faisabilit de notre approche, le chapitre 6 prsente la ralisation de notre approche de dploiement et de gestion du cache sur une application de messagerie lectronique.

Chapitre 2 Problmatique et objectifs du stage

Linformatique mobile peut dsigner la mobilit matrielle ou la mobilit logicielle. La mobilit matrielle est le dplacement physique dun terminal tel quun ordinateur portable, un tlphone ou un assistant personnel numrique. La mobilit logicielle est le dplacement dune entit logicielle entre deux terminaux physiques. Lentit logicielle mobile est alors appele composant, agent, calcul ou application mobile. Dans la suite de notre travail, nous ne nous intressons qu la mobilit logicielle que nous dsignons par mobilit des applications. Dans ce chapitre, nous prsentons dans un premier temps le sujet du stage. Ensuite, nous rcapitulons le contexte de notre travail.

2.1 Sujet du stage

Ce stage de DEA sinsre dans une action plus globale ralise dans le cadre du projet ITEA VIVIAN (http ://www-nrc.nokia.com/Vivian) concernant louverture des plates-formes mobiles pour le dveloppement dapplications base de composants. La plate-forme VIVIAN repose sur la spcication CORBA de lOMG (Objects Management Group) et est conue pour tre extensible et volutive an de permettre la prise en compte des besoins varis des applications. Lquipe Systmes Rpartis de INT axe ses travaux sur le fonctionnement des applications en mode dconnect. Lobjectif est de fournir un support logiciel pour adapter des applications client-serveur existantes au fonctionnement dconnect du terminal dans les rseaux sans l. Nous considrons deux types de dconnexions : les dconnexions volontaires et les dconnexions involontaires. Les premires, dcides par lutilisateur depuis son terminal mobile, sont justies par les bnces attendus sur le cot nancier des communications, lnergie, la disponibilit du service applicatif et la minimisation des dsagrments induits par des dconnexions inopines. Les secondes sont le rsultat de coupures intempestives des connexions physiques du rseau, par exemple, lors du passage de lutilisateur dans une zone dombre radio. Dune manire gnrale, le projet est divis en trois tapes, reprsentes dans la gure 2.1. La premire tape consiste traiter le problme du dploiement des objets dans le terminal mobile en rpondant quelques questions telles que : Quels sont les critres (inter-dpendance, taille, nombre) pour le choix des objets quil faut dployer localement sur le terminal mobile ? Comment dnir cet ensemble dobjets locaux dits dconnects ? Quand dployer cet ensemble dobjets ? La deuxime partie du projet de lINT consiste traiter le problme de la cration des objets dconnects et la manire dont le client mobile travaille dans les diffrents modes de connectivits. La troisime partie du projet de lINT traite de problme de la cohrence et de la rconciliation entre 3

F IG . 2.1 Positionnement du stage

les diffrentes objets distants et les objets dconnects. Le prototype actuel de Domint ne sintresse qu la deuxime partie. Il dnit trois mode de connectivit : 1. Mode fortement connect : dans ce cas de gure, le mobile dispose dune connexion normale au rseau, la manire dune station de travail classique. La connexion peut alors tre ralise soit par une liaison laire, soit par une interface de communication sans l, qui fournit en gnral un dbit plus faible quune liaison cble. 2. Mode partiellement connect : le mobile ne dispose plus pour communiquer que dun lien faible dbit. Cette perte de capacit peut tre due des perturbations physiques ou des surcharge de traitements dans le rseau. 3. Mode dconnect : dans ce mode le mobile est dconnect soit parce quil ny plus de liaison physique ou parce quil est impossible de maintenir une connexion sans l. Lobjectif de ce stage et de fournir un protocole de dploiement des objets dconnects sur le terminal mobile pour lincorporer dans Domint. Ce protocole gnre un autre problme au niveau du cache, puisque le prototype actuel de Domint ne tient pas compte de la prsence de plusieurs objets dans le cache, qui dpend de la taille de la mmoire disponible. Ce problme nous conduit proposer un mcanisme de gestion de cache au niveau client et pas au niveau de tout le systme.

2.2 Rsum du contexte du stage

Les contributions de ce stage peuvent se rsumer en deux grands points. Tous dabord, nous proposons un protocole de dploiement des objets sur le terminal mobile bas sur la notion de criticit dobjet. Ensuite, nous proposons un mcanisme de gestion de cache bas sur le critre de la taille de la mmoire. Dune manire gnrale, le contexte de notre travail peut se rsumer dans les points suivants : Un modle de conception orient objets bas sur la spcication CORBA. Une architecture client-serveur exible (dans le sens o le client peut tre un serveur pour lui-mme). Un fonctionnement des applications dans les trois modes de connectivit.

Chapitre 3 tat de lart sur la mobilit

Il existe de nombreux travaux lis la mobilit dans les systmes client-serveur, et plus rcemment, sur les systmes client-serveur orient objets. Cest pourquoi cette tude commence par une prsentation des domaines de la mobilit. Dans ce chapitre et pour mieux comprendre le fonctionnement des applications mobiles, nous tudierons en premier lieu les paradigmes des modles client-serveur mobiles (Cf. section 3.1), avant de parcourir les grands projets qui sintresse au problme de la mobilit (Cf. section 3.2). Enn, la section 3.3 dcrit les diffrentes techniques de dploiement de donnes sur les terminaux mobiles.

3.1 Paradigmes des modles client-seveur mobiles

Les recherches qui existent sur les systmes client-seveur mobiles peuvent se caractriser en deux grand paradigmes. Cette section prsente ces deux paradigmes o nous verrons comment les applications client-seveur peuvent sadapter au changement de lenvironnement mobile et quelles sont les extensions faire dans les modles client-serveur classiques.

3.1.1 Adaptation des applications mobiles

Les systmes client-serveur mobiles doivent avoir des ractions dynamiques dans linteraction entre les clients mobiles et les machines statiques. Daprs [Sat96a], lintervalle des stratgies pour ladaptation est dlimit par deux extrmits (Cf. gure 3.1). Le premier extrme sappelle "laissefaire" : ladaptation est entirement de la responsabilit des applications. Il vite le besoin dun support systme, mais il manque un contrleur central pour rsoudre les demandes de ressources incompatibles entre diffrentes applications et pour imposer des limites sur lutilisation des ressources. lautre extrmit, "transparence lapplication", ladaptation est entirement de la responsabilit du systme. Donc, cest au systme de faire face aux problmes de la mobilit des application, en particulier la variation de la bande passante du rseau. Linconvnient de cette approche est quil peut y avoir des situations dans laquelle ladaptation ralise par le systme est insatisfaisante ou mme contre productive pour certaines applications. Entre ces deux extrmes, il existe une autre stratgie dadaptation appele "collaboration entre lapplication et le systme", dans laquelle ladaptation se fait en collaboration entre lapplication et le systme. Le systme surveille les ressources et signale aux applications tout changement de niveaux de ressources. Dautre part, cest le systme qui fournit les mcanismes dadaptation pour faire face aux problmes de la mobilit des applications. Lapplication, quand elle, fournit les politiques de cette adaptation, qui dpend de la smantique de lapplication. 5

F IG . 3.1 Les stratgies dadaptation

3.1.2 Extension des modles client-serveur

Une autre voie de caractrisation de limpact de la mobilit est lexamen de son effet sur le modle client-serveur classique. Le modle client-serveur classique suppose que la localisation du client et du serveur ne peut pas changer et que la connexion entre ces machines ne peut pas changer non plus. En consquence, les fonctionnalits entre le client et le serveur sont statiquement rparties. Dans les environnements mobiles, la distinction entre le client et le serveur peut tre temporairement ou [Sat96b]. Les ressources limites dun client peuvent satisfaire certaines oprations dune manire normale et performante, mais il est besoin davoir de nouvelles ressources du serveur pour que le client manipule des donnes rcentes. Par exemple, le client doit se dbrouiller de fonctionner comme un serveur (pour lui ou pour dautres machines), dans le cas o il existe des problmes de connectivit, en crant des proxies dans la machine locale pour les donnes du serveur. Daprs [JHE99], lenvironnement mobile a gnr de nouvelles techniques daccs linformation : Objets mobiles : ce sont des objets qui peuvent se dplacer dune machine une autre en excutant une instruction du type "go". Ces objets donnent aux utilisateurs la possibilit dexcuter des applications distantes dans leurs propres machines en tlchargeant les objets dans la machine locale. Dans notre travail, on ne sintresse pas ce type dobjets puisque notre objectif et de crer des copies de ces objets dans les terminaux mobiles qui sont semblables aux objets distants et non pas la migration de ces objets. Mobilit virtuelle des serveurs : cette technique permet au client mobile de changer le serveur avec lequel il communique suivant lendroit o il se trouve, ceci an de rduire le temps de rponse. En consquence, chaque serveur doit avoir une copie des donnes que le client manipule. Utilisation dun proxy : un proxy sert dun intermdiaire entre le client et le serveur. Il peut tre local (dans la machine du client) ou distant (dans la machine du serveur ou sur une autre machine du rseau xe). Le proxy permet de crer des copies locales des donnes du serveur pour augmenter la disponibilit des donnes dans le systme. Cette technique est trs utilise dans les navigateurs Internet tel que WebExpress [HL96]. Le protocole de dploiement dobjets sur le terminal mobile que nous proposons se base sur lutilisation dun proxy dans la machine mobile.

3.2 tude de projets

Cette section prsente une tude de quatre prototypes de plates-formes qui permettent laccs linformation mobile. Ces systmes servent dmontrer comment les paradigmes analyss dans les sections prcdentes sont appliqus dans la pratique. Les quatre systmes, savoir Coda, Odyssey, 6

Rover et Bayou, dmontrent quelques approches des nouveaux paradigmes pour les systmes clientserveur mobiles.

3.2.1 Coda
Coda [Sat96b] est un systme de gestion de chiers. Son but est doffrir au client la continuit daccs aux donnes en cas darrts des serveurs ou dventuelles dconnexions. Coda hrite de plusieurs caractristiques dutilisation et de conception de AFS (Andrew File System). Les clients visualisent Coda comme un simple systme de gestion de chiers partag UNIX. Lespace de nommage de Coda est partag sur plusieurs serveurs darchivage qui construisent des sous-arbres appels les volumes. 3.2.1.1 Opration dconnecte et mode faiblement connect Lopration de dconnecte est le premier concept introduit par Coda [KS91]. Cest une tape importante dans la gestion des dconnexions. Dans le mode dconnect, le client continue davoir accs aux donnes dans son cache pendant les dconnexions intermittentes. La possibilit de fonctionner en mode dconnect peut tre utile mme lorsque la connexion est disponible, par exemple, pour prolonger la vie de la batterie ou rduire les dpenses de transmission. La transparence est prserve du point de vue de lapplication, puisque cest le systme qui porte la responsabilit de propager les modications, de dtecter les conits et de faire les mises jour quand la connexion est restaure. Dans les applications client-serveur mobiles, un client en mode dconnect souffre de beaucoup de limitations telles que : La mise jour nest pas visible tous les utilisateurs. Labsence des donnes dans le cache peut empcher lutilisateur de travailler sur son terminal mobile. La mise jour est expose au perte et lendommagement des donnes. Les conits de mises jour deviennent de plus en plus probables. Pour traiter ces problmes, Coda [Mum96] exploite la faible connectivit pour deux raisons principales, premirement, faire une validation rapide du cache aprs une faute intermittente, deuximement, oprer une propagation des modications "goutte goutte" en tche de fond pour ne pas dgrader les performances. 3.2.1.2 Gestion du cache du client mobile Dans Coda, pour chaque client, un gestionnaire de cache appel Venus. Il peut tre dans ltat daccumulation, dmulation ou de rintgration. La gure 3.2 reprsente le diagramme de transition UML du gestionnaire de cache. Venus est normalement dans ltat accumulation : il se base sur les serveurs pour les oprations sur les chiers mais reste toujours en alerte pour dventuelles dconnexions. Sil y a une dconnexion, Venus passe dans ltat dmulation et lutilisateur continue son travail sur les volumes disponibles dans le cache. la reconnexion, Venus passe ltat de rintgration pour rintgrer les modications effectues durant la dconnexion. Dans lalgorithme de gestion de cache de Coda, Venus combine des sources de donnes implicite et explicite. Les donnes implicites se composent de lhistorique du client, comme par exemple les chiers les plus utiliss par lutilisateur. Les donnes explicites prennent la forme dune base de donnes spciale au client Hoard Data Base (HDB). Le chargement des donnes explicites se fait au lancement de lapplication. Un programme appel "Hoard" permet lutilisateur de mettre 7

F IG . 3.2 Les tats de Venus dans Coda

jour la HDB directement ou via un script de commandes appel "Hoard Walking". Labsence de donne dans le cache ne peut pas tre masque, elle apparat comme erreur aux programmes et aux utilisateurs de lapplication. La persistance des changements fait lors de la dconnexion est ralise par des oprations de journalisation sur un journal doprations appel le Change Modify Log (CML) . Venus met en application un certain nombre doptimisations pour rduire la taille du CML. Avant quun enregistrement dopration soit ajout au CML, Venus contrle sil peut annuler leffet de prcdents enregistrements. Par exemple, si un client fait deux oprations dcritures et une opration de suppression sur un chier dans le cache, Venus ne gardera que lopration de suppression dans le CML. 3.2.1.3 Dtection et rsolution des conits Coda traite le problme des mises jour en utilisant une stratgie optimiste de contrle des rpliques. Ceci offre un degr plus lev de disponibilit, puisque les donnes peuvent tre mises jour dans nimporte quel serveur. Lors de la rintgration, le systme assure la dtection des mises jour contradictoires et fournit des mcanismes daide aux utilisateurs pour liminer ces problmes. Quand un chier est mis jour, le serveur incrmente le numro de version du chier et celui du volume qui contient le chier. Quand la connexion est restaure, le client prsente les numros de volume pour la validation. Si le numro de volume est valide alors Coda valide tous les chiers cachs de ce volume. Sil est incorrect alors il doit valider chier par chier. Dautre part, si la validation individuelle dun chier nest pas possible cause de la faible connectivit, le client peut supposer que tous les lments dans le volume sont incorrects ou reporter la validation jusqu la prochaine utilisation de llment. Coda ne possde pas la connaissance smantique sufsante pour rsoudre des conits de chier, il offre un mcanisme pour installer et appeler dune manire transparente un rsolveur spcique lapplication (ASR). LASR est un programme qui encapsule la connaissance dtaille et ncessaire lapplication pour distinguer les incohrences des diffrentes rconciliations. Si lASR ne peut pas rsoudre les conits, lincohrence est expose lutilisateur pour la rparation manuelle.

3.2.2 Odyssey
Avant de prsenter Odyssey, nous prsentons un facteur important dans la construction des systmes ralisant une adaptation "collaboration entre lapplication et le systme" ; ce facteur est lagilit [NSN 97].

3.2.2.1 Agilit Prendre une meilleure dcision exige une connaissance plus prcise de la disponibilit de ressources. Dans le meilleur des cas, une application devrait toujours avoir la connaissance parfaite des niveaux de disponibilit de ressources. En dautres termes, il ne devrait y avoir aucun dlai entre un changement de valeur de la disponibilit et la dtection de changement. Lagilit est la proprit dun systme mobile qui dtermine lenvironnement le plus turbulent dans lequel lapplication peut fonctionner dune manire acceptable. Lagilit peut avoir plusieurs niveaux de complexit : par exemple, un systme peut tre beaucoup plus sensible aux changements de la largeur de bande passante du rseau quaux changements du niveau de puissance de la batterie. Un autre point important dans lagilit est lexistence de diffrentes origines des changements de la disponibilit des ressources. Le changement peut tre provoqu par la variation dans lapprovisionnement en ressources due la mobilit ou par les demandes concurrentes des applications. Ces deux types de changement peuvent tre dtects par la mise en uvre de mcanismes de contrle de ressources. 3.2.2.2 Description dOdyssey Odyssey [Sat96a] est un projet de recherche de CMU men par M. Satyanarayanan la suite du projet Coda . Odyssey utilise dans la gestion des donnes un paramtre qui est la dlit des donnes. La notion de dlit dpend du type de donnes dans le systme de chiers. Dans Odyssey, pour chaque type de ressources et tout instant, une fentre de tolrance est dlimite par une borne infrieure et une borne suprieure. Part consquent, pour chaque ressource il existe plusieurs niveaux de dlit. Par exemple, dans les applications multimedia qui traitent des chiers de type image, nous donnons pour chaque image trois niveaux de dlit suivant le nombre de couleurs disponible (noir et blanc, 256 couleurs, 16 millions couleurs). Le systme de gestion de chiers Odyssey est dcompos en plusieurs sous-espaces appels des tomes. Les tomes sont conceptuellement semblables aux volumes dans Coda, mais ils ajoutent la notion de type, le type dun tome dtermine le type de ressources (image, texte, vido . . .). En outre, un tome rside entirement sur un seul serveur. 3.2.2.3 Architecture Larchitecture dOdyssey est prsente dans la gure 3.3. Daprs cette gure, Odyssey offre deux fonctionnalits. Premirement, une fonctionnalit gnrique qui est implante par un vice-roi ("viceroy" en anglais) qui a le rle dun contrleur de ressources dans le systme. Le vice-roi a un rle central dans la ngociation des ressources. Il surveille la disponibilit de la ressource et notie lapplication quand les bornes de la fentre de tolrance sont franchies. Deuximent, Odyssey offre une fonctionnalit spcique au type du tome. Cette fonctionnalit est implante dans le gestionnaire de ressources qui sappelle le gardien ("Warden" en anglais). Il y a un gardien pour chaque type de tome. En outre, larchitecture dOdyssey permet de : 1. Faire des oprations sur des objets Odyssey : Odyssey est intgr dans NetBSD comme un nouveau VFS (Virtual File System). Le vice-roi et les gardiens sont implants dans lespace de lutilisateur plutt que dans le noyau du systme. Les oprations sur les objets dOdyssey sont rorientes vers le vice-roi par un intercepteur dans le noyau reprsent dans la gure par le rectangle "Intercepteur". Tous les autres appels du systme sont traits directement par NetBSD. Les gardiens sont statiquement lis avec le vice-roi, la communication entre eux se fait par des appels de procdures et des structures de donnes partages. Les gardiens sont entirement responsables de la communication avec les serveurs. Lapplication ne contacte jamais directement le serveur. 9

2. Demander des ressources : lapplication demande les ressources Odyssey en utilisant lappel systme suivant : request (in path, in resource-descriptor, out request-id) cancel (in request-id) Lappel prend un descripteur de ressources identiant une ressource et indiquant une fentre de tolrance sur sa disponibilit. Cet appel exprime le dsir de lapplication dtre notie si la disponibilit de la ressource est en dehors des bornes de la fentre de tolrance. 3. Notier les applications : quand le vice-roi dcouvre que la disponibilit dune ressource est infrieure la fentre de tolrance, il envoie une notication "upcall" lapplication correspondante pour ajuster sa dlit selon la politique de lapplication.

F IG . 3.3 Larchitecture dOdyssey

3.2.3 Bayou
Bayou est un projet de Xerox PARC. Son but est de construire un support systme pour partager des donnes entre utilisateurs mobiles via une communication point--point entre les terminaux (directement ou par lintermdiaire dautre machines) [TTP 95, PTT 94] . Le client peut accder des donnes de nimporte quel serveur avec lequel il peut communiquer. Rciproquement, nimporte quelle machine y compris les machines mobiles, qui possde une copie dune collection de donnes doit tre disponibles pour des requtes dcriture ou de lecture pour dautre machines. Donc, les machines mobiles peuvent tre des serveurs pour certaines bases de donnes et des clients pour dautres. 3.2.3.1 Architecture Dans Bayou, chaque collection de donnes est rplique dans plusieurs serveurs de donnes (Cf. gure 3.4). Lapplication cliente communique avec le serveur travers une interface spcique Bayou. Cette interface est implante dans la souche du client et elle fournit deux oprations de base de lecture et dcriture. Bayou ralise un schma de rplication Read-any/Write-any, cest--dire Bayou utilise un modle de cohrence faible des rpliques. Un problme de lapproche Read-any/Write-any est que les incohrences peuvent apparatre mme lorsque seulement un utilisateur ou une application fait des modications sur les donnes. Par exemple, un client crit sur une base de donnes dun serveur, et aprs un moment, lit des donnes dun autre serveur. Le client peut voir des rsultats 10

F IG . 3.4 Larchitecture de Bayou

contradictoires moins que les deux serveurs aient mis jour leurs bases de donnes de faon cohrente. Pour atteindre le maximum de cohrence entre les diffrentes copies de la base de donnes, Bayou utilise un protocole dit anti-entropique pour la propagation des mises jour [PTT 97]. Le protocole anti-entropique assure que toutes les copies dune base de donnes sont convergentes vers le mme tat. En plus, le protocole anti-antropique permet deux machines quelconques qui peuvent communiquer de propager priodiquement leurs mises jour entre elles.

3.2.4 Rover
Rover est un projet de recherche au MIT (Massachusetts Institute of Technology) men par Kaashoek [JTK97]. Rover offre un environnement pour supporter une adaptation transparente lapplication et une adaptation par collaboration entre lapplication et le systme pour des applications client-serveur mobiles. Ladaptation transparente lapplication est ralise en dveloppant des proxies pour les services du systme. Ladaptation par collaboration entre lapplication et le systme introduit les concepts dobjet dynamique r-adressables RDO ("Relocatable Dynamic Objects" en anglais) et dappel de procdure distance non-bloquant QRPC ("Queued Remote Procedure Call" en anglais). 3.2.4.1 Objets dynamiques r-adressables et appel de procdure distance non-bloquant Un RDO est un objet qui peut tre dynamiquement charg sur le client partir du serveur (ou vice versa) pour rduire les communications client-serveur et offrir une disponibilit de lobjet du ct client. Le client utilise ces objets mme dans le cas o il est en mode fortement connect. Dans le cycle de vie dun RDO, son tat peut tre import mais pas encore arriv, prsent dans lenvironnement local, peut-tre modi localement par des invocations de mthodes, en attente pour tre export vers le serveur, ou en attente dans le serveur pour tre rconcili.

11

Les QRPC est un systme de communication qui permet aux applications de continuer faire des RPC non-bloquants lorsque la machine est dconnecte. Les requtes et les rponses sont journalises puis changes aprs la reconnexion. Dans ce rapport, on ne traite pas les appels (asynchrones) non-bloquants de CORBA. 3.2.4.2 Architecture Lapplication Rover emploie des modles check-in, check-out pour la manipulation des objets partags [JTK95]. Dans la gure 3.5, lapplication importe des RDO dans son espace dadressage, invoque les mthodes fournit par ces objets et exporte ces objets vers le serveur. Rover stocke les objets dans le terminal mobile dans un cache qui est partag par toutes les applications Rover de ce terminal. Les objets dploys sont une rplique des objets du serveur.

F IG . 3.5 Larchitecture de Rover Lorsque lapplication Rover invoque une mthode dun objet, Rover contrle dabord le cache. Si lobjet rside dans le cache, Rover applique linvocation directement sur lobjet du cache sans contacter le serveur, mme sil ny a pas de problme de connexion. Ainsi, ces objets sont marqus provisoirement valides, ces objets seront marqus valides lorsque les invocations seront accomplies sur les objets serveurs. Dans ce cas, les applications peuvent continuer de fonctionner mme dans le cas des dconnexions intermittentes. Si lobjet est non prsent dans le cache, Rover cherche cet objet dans le serveur en utilisant des requtes QRPC. Il sauvegarde ces QRPC dans un journal dopration sur le client et retourne le contrle lapplication. Lorsque le client mobile se reconnecte, le Network Scheduler (Cf. gure 3.5) transmet ces oprations vers le serveur. Le Network Scheduler peut dlivrer les QRPC dans un autre ordre que lordre de leur mission (cela dpend de la priorit et du cot de communication avec le serveur). Lorsquune invocation de mthode modie lobjet dans le cache, Rover met jour la copie primaire (dans le serveur). Rover maintient un vecteur de version [RS96] de chaque objet pour que les mthodes puissent facilement dtecter les changements sur lobjet. Les mthodes des RDO comportent du code de dtection et de rsolution des conits qui dpend de la smantique de lapplication. Larchitecture de Rover est structur en trois couches (application, support systme, transport) et se compose de quatre composants. Le premier composant est le gestionnaire daccs. Il est responsable du traitement de toutes les interactions entre les applications clientes et le serveur, et entre les applications clientes entre-elles. Le gestionnaire daccs est responsable du traitement des demandes dobjets par les clients. Il permet aussi de grer la connectivit avec le serveur et contrler le cache des objets. Le deuxime composant est le cache dobjets. Il fournit une mmoire stable pour les copies locales des objets imports, il se compose dun cache priv local situ dans lespace dadressage 12

de lapplication et dun cache global partag situ dans lespace dadressage du gestionnaire daccs. Le cache dobjets offre plusieurs option, pour maintenir la cohrence des objets avec la copie primaire :Verify-before-use, Verify-if-service-is-accessible, Expire-after-date, Service-callback Rover essaie dinformer le client lorsque lobjet change. Le troisime composant est le journal doprations. Il permet denregistrer les requtes envoyes par le client vers les objets locaux pour les excuter sur les objets distants. Le quatrime composant est le Network Scheduler. Il permet de mettre en uvre un mcanisme de contrle de ressources rseau pour choisir le moment de faire la mise jour qui dpend de larchitecture de rseau et la largeur de la bande passante.

3.2.5 Autre projets

Dans le contexte de CORBA qui est le contexte de notre travail, deux projets, [RSK00] et ALICE [Lyn99], traitent le problme de la mobilit matrielle ou physique dans le contexte de CORBA sans le ("Wireless CORBA"). Dans ce cas, la mobilit matrielle est provoque par le changement de cellule ("handover") et par consquent des dconnexions courtes. Larchitecture de se base sur la mise au point de deux proxies (un sur le terminal mobile et un autre dans le rseau laire) dans le but de rendre les dconnexions involontaires transparentes lutilisateur. ALICE utilise aussi un proxy. Il fournit des mcanismes pour supporter les dconnexions volontaires et involontaires. Dans ALICE, quand une dconnexion se produit, une exception est envoye par lORB au client. Le code ncessaire pour commuter vers le mode dconnect doit tre inclus dans le code de lapplication.

3.3 Dploiement
Un cache est un systme qui se place entre les fournisseurs de donnes (les serveurs) et les consommateurs (les clients) [Bag98]. Un grand nombre de travaux ont t raliss ces dernires annes sur les techniques et les mthodes de gestion du cache. Cette section prsente une synthse de ltat de lart prcdent sur la question prcise des diffrentes stratgies de dploiement.

3.3.1 Pas de cache

Cette stratgie est utilise pour les terminaux mobiles qui ne disposent pas dun support spcique la mobilit. Dans ce cas, lutilisateur dploie une copie de donnes manuellement pour travailler lors des dconnexions. Cette stratgie pose beaucoup de problmes. Premirement, elle est limite des applications qui traitent des chiers ou des bases de donnes, car il est trs difcile de dcider quel objet charger sur le terminal puisque les objets ne sont pas manipulables directement par lutilisateur. Deuximement, cette stratgie ne fonctionne pas pour les dconnexions involontaires. Pour rgler le problme des dconnexions involontaires, une technique a t propose pour cette approche o lapplication attend jusqu ce que ltat du rseau dcroisse ou jusqu ce quune dconnexion peut se produire bientt pour informer le client qui doit sauvegarder une copie des donnes quil manipule. Le problme avec cette approche est quun transfert peut ne pas se produire avec succs. 13

3.3.2 Mise en cache systmatique

Dans cette stratgie, si lapplication essaie daccder lobjet distant, le systme cre automatiquement une copie de cet objet dans le terminal mobile et le client utilise uniquement cette copie. Un avantage de cette technique est quelle offre une grande disponibilit des objets dans le cache. En revanche, le cache ne contient que les objets dj utiliss. Donc, en mode dconnect, le client na pas le droit dinvoquer de nouveaux objets. En outre, puisqu chaque fois quun objet est invoqu une copie locale est cre dans le cache, une politique de gestion de lencombrement de la taille du cache est obligatoire. Bayou utilise cette approche qui se base sur la copie totale de la base de donnes dans les terminaux mobiles.

3.3.3 Mise en cache la demande

Dans cette approche, la cration dune copie locale se fait la demande de lutilisateur. Cette approche est trs utilise dans les navigateurs Web tels que Exmh avec Rover [JHE99]. Le chargement des objets se fait la premire invocation. La diffrence avec la mise en cache systmatique est que le systme cre une copie locale uniquement pour les objets slectionns par lutilisateur. Dans cette stratgie, le problme dencombrement du cache est gr par le client et un objet non vu en cache ne sera pas disponible lors des dconnexions. Le systme SEER [Kue94] utilise une approche prdictive automatique de dploiement. Cette approche est base sur lide quun systme peut observer le comportement de lutilisateur, faire des infrences sur les relations smantiques entre les chiers et utiliser ces infrences pour aider lutilisateur slectionner les objets mettre en cache. Un composant observateur observe le comportement de lutilisateur et ses accs aux chiers, classant chaque accs selon le type (de chier : texte, vido, image . . .). SEER [GG97] emploie un concept connu de distance smantique pour mesurer lintuition dun utilisateur concernant les relations entre les chiers. SEER dnit plusieurs distance smantique entre les chiers : La distance smantique temporelle est la dure qui spare lutilisation des deux chiers. La distance smantique base de squences est le nombre de rfrences vers dautre chiers entre lutilisation des deux chiers. Par exemple, dans la squence daccs suivante A,S,S,X,B, la distance smantique entre le chier A et le chier B est gale trois. La distance smantique de vie entre louverture dun chier A et louverture dun chier B est dnie 0 si A na pas t ferm pendant que B est ouvert. Sinon, cest le nombre dinterventions douvertures dautres chiers y compris louverture du chier B. Lobservateur fournit les rsultats des observations un composant de corrlation. Le composant de corrlation value les rfrences des chiers et calcule les distances smantiques. Quand un nouveau contenu de cache doit tre choisi, le composant de corrlation examine lensemble des chiers pour trouver ceux qui sont actuellement en activit et choisit les chiers ayant la plus grande distance smantique jusqu ce que la taille maximum du cache soit atteinte.

3.3.4 Pr-chargement
Cette stratgie permet de charger des objets au lancement de lapplication. La liste des objets a dployer sur le terminal mobile est pr-dnie. Cette approche est utilise dans plusieurs systmes tels que Coda (Cf. section 3.2.1) et UPidata [AFM98] qui utilisent une approche de pr-chargement priodique avec notication des utilisateurs lorsque ltat de lobjet change. 14

Le pr-chargement peut tre fait au moment de lexcution de lapplication. Par consquent, la liste des objets a dployer sur le terminal mobile est dynamique. Dans ce cas, le pr-chargement consiste charger des donnes dans le cache lorsque lapplication prdit que lutilisateur va effectuer une requte dans un futur proche. Si la prdiction est exacte, lutilisateur gagne le temps de retrait du document. Si la prdiction est errone, lutilisateur a consomm des ressources du rseau et de stockage dans le cache pour rien. Par exemple, lapproche classique pour le pr-chargement dans les applications Web consiste extraire les liens hyper-texte contenus dans les documents demands par lutilisateur et commencer aussitt charger les documents sur lesquels ils pointent. Cette approche est coteuse. Dans certains cas, cela peut mener pr-charger un grand nombre de documents inutilement. Il est prfrable dessayer didentier parmi eux un petit nombre de documents davantages susceptibles dtre accds. Le tableau 3.1 donne un rsum sur les projets tudis et leurs approches de dploiement. Systme Coda Rover ALICE Bayou SEER UPidata Mthode de dploiement pr-chargement (une liste pr-dnie par lutilisateur) la demande ( la premire invocation) la demande ( la premire invocation) systmatique prdictive automatique pr-chargement

TAB . 3.1 La mthode de dploiement dans les diffrents systmes

3.4 Conclusion
Dans ce chapitre, nous avons esquiss un tat de lart sur ladaptation des applications clientserveur dans les environnements mobiles et les extensions faire dans ces applications pour faire face la mobilit. Ensuite, nous avons tudi quatre systmes qui traitent le problme de la mobilit. Enn, nous avons fait une synthse sur les approches de dploiement utilises dans les systmes tudis dans ce chapitre. Le prototype actuel de Domint utilise lapproche de mise en cache systmatique pour le dploiement des objets dans le cache. Dans la suit de ce rapport, nous allons prsent notre approche de dploiement qui utilise une mise en cache systmatique pour une catgorie dobjets, et un pr-chargement pour dautre catgorie dobjets. Mais avant de dcrire ces catgories dobjets, nous prsentons dans le chapitre suivant larchitecture de Domint.

15

16

Chapitre 4 Architecture de Domint

Dans les applications distribues classiques avec une forte connectivit, linterface graphique de lutilisateur GUI (Graphical User Interface) est charge dans le terminal mobile, tandis que les objets du serveur rsident sur une machine du rseau xe. La continuit du service dans le cas o le terminal mobile se dconnecte est assure par le dploiement des objets du serveur dans le terminal mobile avant la perte de connectivit. Dans le mode dconnect, le terminal mobile journalise les oprations effectues sur les objets locaux. La rconciliation entre les diffrentes copies est effectue lorsque la connexion est restaure. Dans ce chapitre, nous prsentons la plate-forme Domint (Cf. section 4.2), aprs avoir donner une courte prsentation dun mcanisme CORBA utilis dans le dveloppement de la plate-forme Domint : les intercepteurs portables (Cf. section 4.1). Nous signalons que ltude de Domint et des intercepteurs portables est trs importante pour comprendre notre approche de dploiement et de gestion du cache prsente dans le chapitre 5. En outre, des dtails techniques sur Domint est les intercepteurs portables sont donns dans ce chapitre.

4.1 Les intercepteurs portables

Un point dinterception est un point daccrochage dans lORB ("Object Request Broker") par lequel les services de lORB peuvent intercepter le ux normal dexcution [OMG01]. Ces intercepteurs sont portables au sens o le service est utilisable dans tous les ORB. Donc, un intercepteur est construit indpendamment de lORB. Les intercepteurs portables sont des objets CORBA, leur interface est spcie dans le module PortableInterceptor. CORBA dnit deux groupes dintercepteurs : les intercepteurs des requtes et les intercepteurs dIOR ("Interoperable Object Reference"). Les services de lORB peuvent utiliser ces intercepteurs pour faire des traitements sur les requtes-rponses et changer des informations en ajoutant un contexte de service aux requtes et aux rponses.

4.1.1

Intercepteur de requtes

Lintercepteur de requtes est implant pour intercepter le ux des requtes-rponses travers lORB en des points spciques appels des points dinterception. Deux types dintercepteur de requtes sont dnis : les intercepteurs ct client et les intercepteurs ct serveur. 17

4.1.1.1 Intercepteur ct client et ct serveur Dans la gure 4.1, dans lORB ct client, il y a cinq points dinterceptions. Les points Send_request et Send_poll interceptent toutes les requtes que le client met vers le serveur. Les points dinterception Receive_reply, Receive_exception et Receive_other permettent dintercepter toutes les rponses destines au client. Similairement, il y a cinq points dinterception dans lORB ct serveur. Les points dinterception Receive_request_service_contexts et Receive_request interceptent toutes les requtes destines au serveur. Les points dinterceptions Send_reply, Send_exeption et Send_other interceptent toutes les requtes du serveur vers le client.

F IG . 4.1 Les points dinterception

4.1.1.2 Informations sur la requte chaque point dinterception est donn un objet ClientRequestInfo ct client et un objet ServerRequestInfo ct serveur travers lequel lintercepteur portable peut accder aux donnes de la requte. Il existe deux objets dinformation qui sont : . Ces deux objets hrites de la mme interface RequestInfo dcrite de la faon suivante : local interface RequestInfo { readonly attribute unsigned long request_id; readonly attribute string operation; readonly attribute Dynamic::ParameterList arguments; readonly attribute Dynamic::ExceptionList exceptions; readonly attribute Dynamic::ContextList contexts; readonly attribute Dynamic::RequestContext operation_context; readonly attribute any result; readonly attribute boolean response_expected; readonly attribute Messaging::SyncScope sync_scope; readonly attribute ReplyStatus reply_status; readonly attribute Object forward_reference; any get_slot (in SlotId id) raises (InvalidSlot); IOP::ServiceContext get_request_service_context ( 18

in IOP::ServiceId id); IOP::ServiceContext get_reply_service_context ( in IOP::ServiceId id); };

4.1.2 Intercepteur de rfrences dobjets

Dans plusieurs cas, lORB a besoin dajouter des composants aux rfrences des objets pour permettre aux deux autres types dintercepteurs de dterminer le traitement effectuer. Cette fonctionnalit est ralise travers les interfaces IORInterceptor et IORInfo dnies comme suit : local interface IORInterceptor : Interceptor { void establish_components (in IORInfo info); }; local interface IORInfo { CORBA::Policy get_effective_policy (in CORBA::PolicyType type); void add_ior_component (in IOP::TaggedComponent a_component); void add_ior_component_to_profile (in IOP::TaggedComponent a_component, in IOP::ProfileId profile_id); };

4.2 Plate-forme Domint

Domint [CCVB02b, CCVB02c] est une plate-forme CORBA supportant le fonctionnement dconnect. Dans Domint, CORBA est choisi pour sa capacit tre utilis dans des domaines multiples et parce quil fournit des mcanismes tels que les intercepteurs portables pour tablir une adaptation transparente lapplication. Les principaux objectifs de Domint peuvent se rsumer en : Supporter laccs concurrent de plusieurs applications sur les objets locaux. Centraliser le gestionnaire de ressources et le gestionnaire du journal doprations, en dautres termes, fournir un gestionnaire de ressources et un gestionnaire du journal doprations pour toutes les applications qui tournent sur le terminal mobile. Le prototype actuel de Domint se base sur deux hypothses [CCVB02a]. Premirement, lobjet distant ne peut pas tre accd concurremment par plusieurs clients. Par consquent, Domint ne gre pas le problme de cohrence des donnes. Deuximement, les requtes du client ne comportent pas un mixage de paramtres de types in, in-out et out. Donc, le prototype actuel de Domint ne supporte que les requtes qui soit renvoient des rsultats soit acceptent des paramtres en entre. An de continuer travailler mme lors de dconnexion, lide principale de Domint est de crer sur le terminal mobile des objets proxies appels les objets dconnects (DO). Un DO est un objet CORBA qui est semblable dans la conception lobjet du ct du serveur, mais spciquement construit pour faire face aux dconnexions et la faible connectivit. Dans les prochaines sections, nous dcrivons larchitecture de Domint et le fonctionnement de tous les objets de Domint. 19

4.2.1 Architecture
Larchitecture de Domint est reprsente dans les gures 4.2 et 4.3 [CCVB02c]. Les deux gures prsentent respectivement, des diagrammes de collaboration UML du client envoyant la premire demande un objet distant quand la connectivit est forte puis envoyant une demande dans le cas de faible connectivit. Dans le reste de la section, nous prsentons les diffrentes entits de larchitecture de Domint. Tous les rectangles sur les gures 4.2 et 4.3 reprsentent des objets CORBA. Lintercepteur portable PI est galement un objet CORBA local, cest--dire quil ne peut pas tre appel en dehors de son entit dexcution (une entit dexcution est attache un seul ORB). Toutes les requtes du ou vers le client sont interceptes par PI. Sur les requtes sortantes, PI agit en tant que commutateur entre le DO et lobjet distant. Sur la rception de la rponse, PI dtecte les fautes de communication entre lenvoi de la demande et la rception de la rponse.
1

PI

Client
<< new >> 2.1 2.2 2.3 2.2.1.1 2.2.1.2 4.1.1 2.2.1.3 4.1.2 4.2

Remote Object DO

DOM
2.2.1

LM RM
<< new >> 2.2.2

CM

1: Clients request before interception 2.1: findRM() 2.2: findCM() 2.2.1: createDO() 2.2.1.1: findRM() 2.2.1.2: findLM() 2.2.1.3: addInterpretLogOBV() 2.2.2: createCM() 2.3: getCMInfo() 3: Clients request after interception 4.1.1: findCM() 4.1.2: getCMInfo() 4.2: <<periodic>> incrementalStateTransfer()

F IG . 4.2 Le comportement de Domint en mode fortement connect

Linterface du client (Client dans les diagrammes) et le PI appartiennent la mme entit dexcution tandis que le gestionnaire dobjets dconnects DOM, le gestionnaire de ressources RM, le gestionnaire de connectivit CM et le gestionnaire du journal LM sont groups dans une autre entit dexcution, galement sur le terminal mobile. Lentit dexcution des gestionnaires est lance avant que le client ne manipule des applications dans son terminal. Le DOM est le point dentre pour trouver les autres gestionnaires. Le RM est une fabrique de CM. Dans Domint, chaque DO correspond un CM . Au premire appel de lobjet distant, RM cre un DO et le CM correspondant sur la demande de PI. La gure 4.2 montre les interactions entre les diffrents objets de Domint lors du premier appel un objet distant dans le cas de la forte connectivit. Dans le diagramme, chaque che est une requte CORBA. Les demandes 1 et 3 sont des cas particuliers : la requte 1 est intercepte par PI qui ne linterprte pas mais laisse lORB la transmettre en tant que requte 3 lobjet distant. Entre ces deux demandes, PI recherche la rfrence du CM associ cet objet dans sa table interne et conclut que cest le premier appel pour cet objet distant. Dans ce cas, PI demande au DOM (2.1) la rfrence du RM pour que ce dernier cre le DO (2.2.1) et le CM associ (2.2.2). Pendant sa construction, DO obtient les rfrences de RM et de LM en appelant le DOM (2.2.1.1, 2.2.1.2). Ensuite, PI dcide o 20

la requte du client va tre envoye (soit vers lobjet distant soit vers lobjet dconnect). Dans le scnario o la connectivit est forte, les requtes du client sont excutes sur les objets distants (3). Enn, lobjet dconnect appelle priodiquement lobjet distant pour un transfert incrmental dtat (4.2). Cependant, il doit dabord contrler la connectivit en appelant le CM (4.1.2).
1

PI
3 5.b.3

Client

Remote Object

DO
5.a.1 5.b.1 5.b.2 5.a.2.2

DOM RM CM

5.a.2.1

LM

1: Client request before interception 2: getCMInfo() 3: Client request after interception 4: getCMInfo() 5.a.1: addLog() 5.a.2.1: << periodic >> getCMInfo() 5.b.1: treatLog() 5.b.2: getCMInfo()

5.a.2.2: DO request 5.b.3: DO request

F IG . 4.3 Le comportement de Domint en mode partiellement connect et dconnect

Quand la connectivit devient faible ou nulle, le client entre dans les modes partiellement connect ou dconnect respectivement. Ce cas est reprsent par la gure 4.3. Les requtes du clients sont interceptes par le PI (1). PI obtient linformation de connectivit du CM (2) et oblige lORB transmettre les requtes du client vers le DO (3). Domint donne deux scnarios possibles dexcution dans ce mode : 5.a et 5.b. Si la requte du client est interprte en tant que fournissant des informations lobjet distant, le cas 5.a, DO met jour son tat et prpare une nouvelle requte, appele une DO requte, pour lobjet distant. Le cas le plus simple est que la DO requte est quivalente en termes de types et de nombre de paramtres et en termes de contenu la requte du client. Ensuite, DO encode la requte dans un Any CORBA [GAK00] et envoie cet Any au LM (5.a.1). Priodiquement, le LM dcode la requte enregistre, teste la connectivit (5.a.2.1), et si possible, envoie la requte lobjet distant. Le deuxime cas 5.b se produit par exemple quand la requte du client est interprte comme une requte qui renvoie des rsultats au client. Si la taille du journal dopration indique par le LM (5.b.1) est nulle et linformation sur la connectivit obtenue partir du CM (5.b.2) permet la transmission sans l avec lobjet distant, DO essaie dabord de charger linformation demande par le client de lobjet distant (5.b.3) et ensuite de mettre jour son tat avant de renvoyer linformation au client.

4.2.2 Quelques dtails sur les objets de Domint

Cette section donne le rle de chaque entit dans larchitecture de Domint, prsente linterface crite dans CORBA IDL de ces entits et dveloppe les lments (attributs, excutions) de linterface de chaque entit. 21

4.2.2.1 Gestionnaire dobjets dconnects Comme dj indiqu dans la dernire section, DOM est le point dentre du service de gestion des objets dconnects, son nom dinterface est DOManager. Linterface fait partie du module nomm dom qui contient galement les sous-modules rm et lm pour le gestionnaire de ressources et le gestionnaire du journal respectivement, et le sous-module pi qui dcrit lintercepteur portable. Les mthodes FindLogManager() et ndResourceManager() servent obtenir la rfrence du gestionnaire du journal et le gestionnaire de ressources. module dom { interface DOManager { lm::LogManager findLogManager(); rm::ResourceManager findResourceManager(); }; module rm; module lm; module pi; }; 4.2.2.2 Gestionnaire de ressources Le gestionnaire de ressource centralise la commande de toutes les ressources dans le terminal mobile. Domint se focalise sur les ressources lies la connectivit : lactivit du rseau, largeur de bande disponible, cot de transmission, charge de la batterie... Lintercepteur, lobjet dconnect et le gestionnaire du journal obtiennent la rfrence de CM grce la mthode ndConnectivityManager() du gestionnaire de ressource. Les gestionnaires de connectivit sont crs et dtruits par lintercepteur avec le createConnectivityManager() et le destroyConnectivityManager(). module rm { interface ResourceManager { ConnectivityManager createConnectivityManager (in Object remoteObject); void destroyConnectivityManager (in Object remoteObject); ConnectivityManager findConnectivityManager (in Object remoteObject); }; interface ConnectivityManager; }; 4.2.2.3 Gestionnaire de connectivit Le gestionnaire de connectivit CM manipule une connexion logique entre un client sur le terminal mobile et un objet distant sur le terminal xe. Domint dnit un mcanisme dlhystrsis (Cf. gure 4.4) qui permet de grer la connectivit entre lobjet distant et DO. Sur la gure 4.4, quand le niveau de ressource augmente et est infrieur au seuil lowUp (resp. highUp), le terminal mobile est dconnect (resp. partiellement connect). Quand le niveau de ressource diminue mais est plus lev que la valeur highDown (resp. lowDown), le terminal mobile est connect (resp. partiellement connect). Sans la gure 4.4-2, il peut y avoir un effet de "ping-pong" autour de la valeur highDown. Ainsi, quand la connexion arrive dans ltat F en provenance de ltat E et quand le niveau de ressource dpasse la valeur highDown, le mode demeure "partiellement connect" jusqu la valeur highUp. 22

highDown

highUp

highDown

highUp

F A
lowDown

C B
lowUp

F A
lowDown

C B
lowUp

(1) disconnected partially connected

(2) connected direction of variation

F IG . 4.4 Lhystrsis pour la gestion de la conectivit

interface ConnectivityManager { attribute double lowDown; attribute double highDown; attribute double lowUp; attribute double highUp; readonly attribute double resLevel; readonly attribute char state; readonly attribute char mode; readonly attribute boolean forward; attribute boolean voluntaryDisc; readonly attribute Object remoteObject; readonly attribute Object localObject; string computeCI(); string getConnectionStateInfo(); }; 4.2.2.4 Gestionnaire du journal doprations Le gestionnaire du journal doprations LM est responsable du contrle des oprations enregistres avec les mthodes addLogRequest(), compactLog(), treatLog(). Les oprations sont classes par objet distant. Le gestionnaire du journal ne peut pas interprter les donnes enregistres, mais les objets dconnects fournissent le code qui permettra par exemple de les transmettre lobjet distant. module lm { abstract interface DORequest { void compactLog(in Object remoteObject); long treatLog(); }; interface LogManager { void addLogRequest(in any data); void compactLog(in Object remoteObject); long treatLog(in boolean optimistic); void receiveOBV(in DORequest applObject); }; }; 23

24

Chapitre 5 Protocole de dploiement dobjets

Aprs avoir tudi les diffrentes approches de dploiement (Cf. section 3.3) et le fonctionnement gnral de larchitecture Domint (Cf. chapitre 4), nous prsentons la conception de notre approche de dploiement qui sera implante dans la plate-forme Domint. Lapproche que nous proposons est une synthse des approches tudies dans le chapitre 3 en introduisant le concept de criticit des objets. La criticit permet de dnir deux groupes dobjets : les objets critiques qui sont les objets ncessaires pour le fonctionnement des applications en mode dconnect et les objets non critiques dont labsence nempche pas le fonctionnement de lapplication en mode dconnect. Dans ce chapitre, nous prsentons le concept de criticit (Cf. section 5.1). Ensuite, nous rpondons dans la section 5.2 la question "quand dployer les objets ?". La section 5.3 dveloppe les tapes suivre pour la mise en uvre du dploiement sur un systme. Enn, la section 5.4 dcrit notre approche de dploiement dans Domint et le mcanisme de gestion du cache associ.

5.1 Concept de criticit

5.1.1 Introduction du concept
Dans la conception dune application rpartie CORBA, la premire tape est la spcication du contrat sous forme dinterfaces crites en IDL, qui permettent de dnir tous les types dobjets. La plate-forme Domint dcompose lensemble des objets de lapplication en deux catgories : 1. Les objets autorisant un proxy pour le mode dconnect : cette catgorie comporte les objets que lapplication peut dployer dans le terminal mobile pour le fonctionnement en mode dconnect. Dans Domint le choix de ces objets est fait par le programmeur de lapplication. Ce choix dpend en particulier de la smantique de lapplication. 2. Les objets qui nautorisent pas un proxy pour le mode dconnect : contrairement la premire catgorie, cette catgorie contient les objets que lutilisateur ne peut pas manipuler localement. De mme que pour la premire catgorie, le choix des objets qui nautorisent pas un proxy pour le mode dconnect se fait lors de la conception de lapplication par le programmeur. Comme dcrit dans la section 4.2, lobjet proxy (objet dconnect) est un objet CORBA qui est semblable lobjet prsent du ct du serveur. La premire diffrence est que linterface de lobjet dconnect comporte des oprations supplmentaires ajoutes pour faire face au fonctionnement en mode dconnect, notamment la sauvegarde doprations dans le journal et le transfert dtat avec lobjet distant. La deuxime diffrence est que le comportement des oprations communes avec 25

lobjet distant est diffrent : par exemple, le message lectronique nest pas transmis mais journalis dans le journal doprations. La gure 5.1 donne un exemple de cration dobjets dconnects dans une application de messagerie lectronique. Les rectangles en pointills reprsentent deux clients mobiles (A et B) et un serveur xe qui contient les objets distants. Lapplication comporte deux objets. Le premier type est le MailBoxManager qui permet de crer, supprimer, renommer et dplacer les botes aux lettres. Cet objet nest manipulable que par ladministrateur de lapplication. Le deuxime type dobjet est le MailBox. Dans cette application, un objet de type MailBox est cr par utilisateur. La cration seffectue partir de lobjet de type MailBoxManager. Dans la gure 5.1, lobjet de type MailBox est manipul par le client travers une interface graphique GUI.

F IG . 5.1 Exemple de cration des objets dconnects

Dans cette application, supposons que le client mobile B cre dans son terminal mobile un objet dconnect MailBoxManagerDM proxy de lobjet MailBoxManager du serveur xe. Dans le scnario o le client B a le droit de manipuler cet objet et cre une nouvelle bote aux lettres pour un utilisateur C partir de lobjet MailBoxManagerDM, lutilisateur C ne pourra pas utiliser sa bote aux lettres tant que le client B est dconnect. Donc, dans ce cas de gure, lobjet MailBoxManager doit tre class par le programmeur de lapplication comme tant un objet qui nautorise pas le fonctionnement en mode dconnect. Par contre, lobjet MailBox du serveur xe peut avoir un objet dconnect, puisque lutilisation de cet objet par lutilisateur en mode dconnect permet quand mme lobjet rest sur le serveur xe de recevoir les messages destination de lutilisateur. Cette utilisateur verra ses messages lors de la reconnexion. Donc, cest partir de la smantique et du fonctionnement de lapplication que le programmeur dcide quels sont les objets qui autorisent la cration dun objet dconnect pour le mode dconnect. En conclusion, contrairement Coda ou Rover, Domint ne traite pas tous les objets de lapplication de la mme manire et larchitecture de lapplication est fortement lie la smantique de lapplication. Le problme avec cette dcomposition est quelle ne traite pas le problme des objets proxy qui doivent absolument exister dans le terminal mobile pour le fonctionnement en mode dconnect. Notre approche de dploiement commence par une rponse ce problme avec lintroduction du concept de criticit. Le concept de criticit permet de donner un "poids" aux objets quand leur prsence dans le cache du terminal mobile. Ce concept nous amne classer les objets qui autorisent 26

un proxy pour le mode dconnect. Cette classication est prsente dans la gure 5.2. La catgorie des objets qui autorisent un proxy pour le mode dconnect est partitionne en deux classes : les objets critiques (OC) et les objets non critiques (ONC).

F IG . 5.2 La criticit des objets

5.1.2 Objets critiques et Objets non critiques

Un objet critique est un objet dont la prsence dans le cache est obligatoire pour le fonctionnement en mode dconnect. Lutilisateur doit avoir un objet proxy pour le mode dconnect dans son cache. Un objet non critique est un objet dont labsence dans le cache ne peut pas empcher le fonctionnement de lapplication en mode dconnect. Lapplication doit tre construite de telle faon quun tel objet absent pendant une dconnexion nempche pas lapplication de continuer fonctionner. Cette classication doit tre respecte dans la conception de lapplication. La conception oriente objets se base sur linstanciation des objets partir dune classe. Nous envisageons deux mthodes possibles pour la classication de ces objets. La premire mthode est de classier partir des classes dobjets. Dans ce cas, nous parlons dattribut de classe : tous les objets instancis partir de cette classe possdent la mme criticit. Cette classe peut tre une superclasse (classe de base) ou une classe hrite partir dautres classes. Cette solution pose un problme dhritage de lattribut criticit entre les diffrentes classes. Dans la gure 5.3, la classe Classe 1 est dclare comme tant une classe qui gnre des objets critiques (marque par une toile dans la gure). La classe Classe 3 hrite de la classe Classe 1. Donc, un problme se pose avec cet hritage, notamment avec la possibilit de propager lattribut criticit entre les classes. La deuxime 27

mthode est la classication partir des objets. Dans ce cas, nous parlons dattribut dinstance : la criticit de lobjet est attribue au moment de son instanciation.

F IG . 5.3 La propagation de la criticit entre classes

Pour dterminer qui partitionne les objets, nous envisageons deux solutions possibles. Premirement, le partitionnement est la tche du programmeur de lapplication. Dans ce cas, le partitionnement se fait partir des classes et/ou des objets de lapplication par le programmeur. Deuximement, le partitionnement se fait en collaboration entre le programmeur et lutilisateur de lapplication. Cette solution est illustre dans la gure 5.2. Au moment de la conception de lapplication, le programmeur partitionne les classes et les objets qui autorisent un proxy pour le mode dconnect en OC programmeur et ONC programmeur . Ensuite, chaque lancement de lapplication ou dans la conguration de lapplication au moment de linstallation, lutilisateur peut forcer un objet non critique du programmeur devenir critique. Dans la gure 5.2, les rectangles griss reprsentent les objets critiques de lapplication, cest--dire lunion des objets critiques programmeur et des objets critiques utilisateur. En outre, lutilisateur ne peut pas forcer un objet critique programmeur devenir un objet non critique utilisateur. Nous considrons que le programmeur connat mieux que lutilisateur quels sont les objets dconnects qui doivent imprativement exister dans le terminal mobile pour le fonctionnement en mode dconnect.

5.1.3 Exemple de partitionnement des objets

An de mieux comprendre notre concept de criticit, nous donnons dans cette section un exemple de classication des objets qui se basent sur la smantique de lapplication. Lexemple que nous traitons est lapplication de messagerie lectronique dcrite dans la section 5.1.1 avec les deux classes MailBox et MailBoxManager. Cette fois-ci, nous ajoutons notre application quatre autres objets : CarnetAdressePersonnel qui donne les adresses que le client utilise pour envoyer des messages. Cet objet offre une interface permettant au client dajouter, de supprimer et de rcuprer des adresses de destinataires. DossierMsgSupprime qui contient tous les messages supprims par le client de son MailBox. partir de cet objet, le client peut rcuprer un message quil a supprim de sa bote aux lettres. 28

 DossierModel qui contient un ensemble de messages pr-dnis que le client peut utiliser pour viter de rcrire les mmes messages plusieurs fois. partir de cet objet, lutilisateur peut rcuprer, ajouter ou supprimer des modles de messages. DossierMsgEnvoye qui sauvegarde les messages envoys par le client. Ces messages ne sont sauvegards que lorsque le client slectionne loption correspondante. Le client peut lire, supprimer ou renvoyer un message de ce dossier vers dautres destinataires. Les objets DossierMsgSupprime, DossierModel et DossierMsgEnvoye sont instancis de la mme classe Dossier. La table 5.1 reprsente un partitionnement des objets. Cette table comporte quatre colonnes. La premire colonne "classe" reprsente les classes utilises par lapplication. La deuxime colonne "objet" liste les objets de lapplication. La troisime colonne "autorisant le mode dconnect" donne la classication, par le programmeur, des objets en objets autorisant un proxy en mode dconnect ("oui" dans la table) et ceux qui nautorisent pas un proxy pour le mode dconnect ("non" dans la table). La quatrime colonne"criticit" indique la criticit de chaque objet de lapplication. Cette colonne est dcompose en trois sous-colonnes : "Choix P" : criticit des objets de lapplication vue par le programmeur. "Choix U" : criticit vue par lutilisateur sur les objets non critiques du programmeur. "Choix nal" : union du choix du programmeur et de lutilisateur. Autorisant le Classe Objet mode dconnect oui non oui oui Criticit

MailBox BotMessage MailBoxManager Gestionnaire CarnetAdresse CarnetAdressePersonnel DossierMsgSupprime Dossier DossierModel DossierMsgEnvoye

Choix P OC ONC ONC

Choix U Choix nal OC OC ONC ONC ONC OC ONC ONC ONC

TAB . 5.1 Un exemple de partitionnement dobjets pour lapplication messagerie lectronique

Lobjet Gestionnaire instanci de la classe MailBoxManager est un objet qui nautorise pas un proxy dans le terminal mobile en mode dconnect. Par contre, les objets BotMessage, CarnetAdressePersonnel, DossierMsgSupprime, DossierModel et DossierMsgEnvoye autorisent un proxy pour le mode dconnect. Puisque, la manipulation locale de ces objets naffecte pas le fonctionnement de lapplication. Dans la table 5.1, les quatre derniers objets sont classs comme tant des objets non critiques par le programmeur par le fait quils sont instancis de la classe Dossier considre par le programmeur comme tant une classe qui gnre des objets non critiques. Par contre, le programmeur classe lobjet BotMessage dans la catgorie des objets critiques. Donc, la prsence de lobjet dconnect qui lui correspond dans le terminal mobile est obligatoire pour le fonctionnement de lapplication en mode dconnect. Par ailleurs, lutilisateur lance son application de messagerie lectronique sur son terminal mobile et saperoit quil a le droit de modier la criticit des objets CarnetAdressePersonnel, DossierMsgSupprime, DossierModel et DossierMsgEnvoye. Lutilisateur pense quil va envoyer plusieurs messages des destinataires diffrents ou quil ne connat pas par cur leur adresse. Par consquent, il force la criticit de lobjet CarnetAdressePersonnel. 29

5.2 Dploiement des objets critiques et non critiques

Aprs avoir prsenter notre vision du classement des objets dans une application rpartie, nous allons dcrire notre approche de dploiement qui se base sur la notion de criticit dobjet.

5.2.1 Dploiement suivant la criticit des objets

La gure 5.4 prsente notre approche de dploiement. Cette approche dpend de la nature des objets dployer. Daprs la gure 5.4, pour les objets critiques, le dploiement se fait au lancement de lapplication. Contrairement Coda qui utilise le dploiement au lancement de lapplication, les objets dployer peuvent ne pas tre instancis (prsents en mmoir) dans le serveur. Par exemple, une application qui utilise un activateur des serviteurs (Servant Activator en anglais) [GAK00], lobjet serveur est cr la premire invocation dun client cet objet. Lactivation des objets au moment de linvocation ne pose pas de problmes pour le dploiement, puisque lobjet dconnect est cr indpendamment de lobjet distant. Une fois lobjet dconnect est cr, il doit faire un transfert dtat avec lobjet distant. Donc, lobjet distant va tre activ par la requte du transfert dtat.

F IG . 5.4 Le dploiement dobjets

Pour les objets non critiques, la cration des objets dconnects se fait la premire invocation. Quand lapplication invoque un objet non critique, le systme vrie si lobjet existe dans le cache. Si ce nest pas le cas, le systme cre automatiquement un objet proxy dans le cache.

5.2.2 Problme de connectivit

Notre approche se base sur lhypothse que le dploiement ne se fait que dans le mode fortement connect. Or, le problme avec cette hypothse est que le dploiement peut tre interrompu si la connectivit passe au mode faiblement connect voir dconnect. Nous prvoyons deux cas de gure ce problme selon que lobjet invoqu est critique ou non. Premirement, supposons quil y a une dconnexion involontaire au moment du chargement des objets critiques. La premire solution ce problme est dattendre une bonne connectivit pour terminer le chargement des objets critiques. Cette solution est en contradiction avec notre approche qui se base sur le principe quun objet critique doit tre prsent dans le cache. Pour viter ce problme, 30

nous proposons une deuxime solution o nous avons dcider de crer des objets dconnects sans tats ("objets dconnects vides") pour les objets non dploys. Un objet dconnect vide est tout simplement un objet qui respecte linterface de lobjet dconnect mais sans faire un transfert dtat avec lobjet distant. Une consquence cette solution est que lutilisateur ne verra pas ltat actuel de ces objets. Enn, pour viter les dconnexions volontaires au moment du chargement des objets critiques, nous proposons dinterdire les dconnexions volontaires au moment du chargement des objets critiques. Deuximement, supposons que la premire invocation sur un objet non critique survient dans le mode dconnect ou partiellement connect. Contrairement au premier cas o nous crons un objet dconnect vide, nous utilisons la mme approche que Rover qui sauvegarde les requtes dans un journal doprations. Au passage au mode connect ou partiellement connect, la requte est renvoye vers lobjet serveur. Dans ce cas, nous vitons la cration dun objet dconnect vide parce que la requte de lapplication peut tre destine modier ltat de lobjet ou rcuprer des donnes.

5.3 tapes de conception

Le gure 5.5 reprsente les deux problmes traiter pour la mise en uvre de notre approche de dploiement. Premirement, au moment de la programmation de lapplication, le programmeur doit choisir sil propage lattribut criticit entres les diffrentes classes de lapplication. Deuximement, au moment de la conguration de lapplication sur le choix des types dobjets, nous envisageons deux visions possibles : Une vision programmeur o le partitionnement des objets se fait au moment de la programmation. Ce partitionnement est statique dans le sens o la criticit de lobjet ne peut pas tre modie une fois quelle est xe par le programmeur. Une vision programmeur plus utilisateur dans le sens o lutilisateur peut changer la criticit dun objets.

F IG . 5.5 Les tapes de conception

31

5.4 Dploiement dans Domint

Larchitecture de dploiement que nous avons tudie jusqu maintenant nest lie aucune plate-forme. Dans cette section, nous prsentons le fonctionnement de notre approche dans la plateforme Domint. Nous traitons le problme de partitionnement des objets en objets critiques est objets non critiques (Cf. section 5.4.1). Ensuite, dans la section 5.4.2 nous dtaillons notre mcanisme de gestion du cache.

5.4.1 Architecture
Larchitecture de dploiement dans Domint est reprsente dans la gure 5.6. Cette gure prsente un diagramme de collaboration UML, il dcrit lalgorithme de dploiement des objets critiques prsent dans la gure 5.7. Les information sur la criticit des objets sont contenus dans un chier de conguration. Chaque entre de ce chier comporte deux champs : 1. Nom logique Le champ "nom logique" reprsente la rfrence de lobjet dans le systme. Dans le contexte CORBA, le nom logique de lobjet peut tre rcupr partir du service de nommage ou partir dun chier de dsignation. Ce champ est rempli par le programmeur de lapplication qui connat comment trouver la rfrence de chaque objets. 2. Type Le champ "type" reprsente la criticit de lobjet. Dans le cas o lobjet est critique, ce champ est gal "OC". Dans le cas contraire, ce champ est gal "ONC".

F IG . 5.6 Le dploiement dans Domint au lancement de lapplication

Le chier de conguration est construit par le programmeur de lapplication durant la phase de programmation. Au lancement de lapplication ou au moment de la conguration de lapplication, 32

lutilisateur peut modier ce chier pour choisir parmis les objets non critiques du programmeur ceux qui deviennent critiques. Au lancement de lapplication et aprs la mise jour du chier de conguration par le client (Client dans la gure 5.6), lintercepteur portable (PI) demande DOM (2.1) la rfrence de RM. Nous rappelons que lunit dexcution de DOM nest pas la mme que celle du client. Puisque le client et le DOM se trouvent dans la mme machine et selon lhypothse que lapplication cliente connat le port dentre pour trouver le DOMServer, PI peut construire la rfrence de DOM partir de ces informations. Une fois la rfrence de RM obtenue, PI invoque lobjet RM (2.2) via la mthode Deployer() prsente dans la gure 5.7 en lui passant ladresse du chier de conguration. Dans cet algorithme, RM parcourt le chier de conguration, et pour chaque entre, effectue les oprations suivantes. Dabord, il vrie le type de lobjet travers le champ "type". Si lobjet est un objet critique, RM cre lobjet dconnect DO de cet objet et le gestionnaire de connectivit CM associ (3.1, 3.2) de la mme manire que dans Domint. Ensuite, RM invoque lobjet distant (4) pour faire un transfert dtat. Si la cration de lobjet dconnect choue suite une dfaillance de la connexion, lobjet dconnect reste vide. Le transfert dtat entre lobjet serveur et lobjet dconnect se fait quand la connexion redevient bonne. Ensuite, DO essaie priodiquement de contacter lobjet distant pour faire un transfert dtat. Algorithme Deployer(chaine fichierConf) { file fichier; objet do; info objet; file = lireFichier(fichierConf); Tant que (non fin de fichier(file)) { info = recupererInfoTable(); nomObjet = info.nom; typeObjet = info.type; Si (typeObject == "OC") { do = creerobjetDeconnecteEtCM(nomObjet); Si (do != null) { do.incrementalStateTransfer(); } } } } F IG . 5.7 Lalgorithme de Dploiement des objets critiques

Si le type de lobjet est "non critique", RM ne fait rien puisque le dploiement de ces objets se fait la premire invocation. Lors de linterception dune requte, PI recherche la rfrence du CM associ lobjet distant dans sa table interne. Sil ne la trouve pas, il conclut que cest la premire invocation pour cet objet distant. Dans ce cas, PI appelle RM via la mthode createConnectivityManager() pour que ce dernier cre lobjet dconnect DO et le gestionnaire de connectivit CM associ dans le cache. Lobjet dconnect que RM cre dans le terminal mobile respecte linterface donn dans la gure 5.8. la mthode incrementalStateTransfer() permet de faire le transfert dtat avec lobjet distant, tandis 33

que les mthodes disconnect() et reconnect() sont utilises pour commuter entre lobjet distant et lobjet dconnect dans le cas de la dconnexion volontaire. interface ObjetDM { //les mmes mthodes que lobjet distant ....................... ....................... ....................... //ajouter pour grer la dconnexion void incrementalStateTransfer(); void disconnect(); void reconnect(); } F IG . 5.8 Linterface de lobjet dconnect

5.4.2 Gestion du cache

Pour rsoudre le problme dencombrement du cache, nous dcrivons dans cette section le mcanisme de gestion du cache que nous proposons pour Domint (Cf. section 5.4.2.2) aprs avoir prsent quelques algorithmes classiques de la littrature (Cf. section 5.4.2.1). 5.4.2.1 Algorithmes de gestion du cache De nombreuses recherches ont t consacres la gestion de la mmoire virtuelle. Entre autres aspects, la majorit de ces recherches se sont intresses aux algorithmes de remplacement ou de suppression des donnes. Si nous considrons que la taille du cache est trs infrieure la taille des donnes accessibles (gnralement cest le cas de gure), il devient essentiel de ne conserver en cache que les objets les plus utiliss. Il est donc vital pour la performance du cache de choisir le meilleur algorithme de remplassement possible. Parmi les algorithmes de la littrature les plus utiliss dans la gestion du cache nous citons les algorithmes suivants [SG98] : FIFO (First in, First Out) : cest lalgorithme le plus simple qui soit. Les objets sont expulss du cache dans le mme ordre quils y sont entrs. Cependant, cet algorithme nest pas performant : un objet jug utile par lutilisateur devrait avoir une chance de rester longtemps en cache, tandis quun objet peu utile devrait tre expulse rapidement. Lalgorithme FIFO, qui ne tient pas compte de la popularit des objets, ne rpond pas ce cahier des charges. LRU (Least Recently Used) : dans cette algorithme, chaque fois quun objet doit tre expuls, lalgorithme choisit lobjet qui na pas t accd depuis le plus longtemps. Cette politique est nettement plus efcace que FIFO car elle permet aux objets de rester dans le cache tant quils sont trs utiles. Cependant, LRU est plus compliqu mettre en uvre que FIFO. LFU (Least Frequently Used) : cet algorithme consiste expulser lobjet qui a t accd avec la plus faible frquence. Cet algorithme est plus compliqu implanter que LRU. Son inconvnient est quil a tendance ne rien oublier : si un objet est extrmement utile pendant un moment, puis cesse brusquement dtre utilis, il restera en cache longtemps aprs. Une variante qui rpond ce problme est dutiliser un paramtre de vieillissement des objets dans le cache. 34

5.4.2.2 Remplacement des objets non critiques Dans notre approche, il est vident que les objets choisir pour le remplacement appartiennent au groupe des objets non critiques, puisque le principe de notre approche de dploiement se base sur lhypothse quun objet critique doit toujours tre prsent dans le cache. Dans notre approche, nous supposons que la taille du cache est suprieure la somme des tailles des objets critiques. Cette hypothse nous assure que lexistence de tous les objets critiques dans le cache ne gnre pas un encombrement du cache. Lapproche de gestion du cache que nous proposons pour la gestion des objets non critiques se base sur lalgorithme LFU. Cette approche est reprsente dans la gure 5.9. Notre approche dnit deux nouveaux paramtres spcis par lutilisateur qui sont le seuil de disponibilit du cache et la priode sur laquelle lalgorithme LFU calcule la frquence dutilisation de chaque objet. Le seuil de disponibilit du cache est dni comme tant la taille minimale disponible du cache au dessous de laquelle RM doit faire des suppressions dobjets dans le cache. La priode permet de dnir la priodicit du calcul de la frquence dutilisation de chaque objet. Par consquence, dans notre cas, la frquence dutilisation de chaque objet est gale au nombre dinvocations pendant la dernire priode divise par la priode

F IG . 5.9 La gestion du cache dans Domint La table 5.2 reprsente un exemple dinstants dinvocation des objets CarnetAdressePersonnel et DossierModel dans lapplication de messagerie lectronique vue dans la section 5.1.3. La premire colonne de cette table donne les deux objets tudis. La deuxime colonne donne les instants dinvocation pour chaque objet. Dans notre exemple, nous supposons que lheure dinvocation est donne en seconde. Par exemple, lobjet CarnetAdressePersonnel est invoqu aux instants 2, 3,....., 26 et 29. Si nous appliquons lalgorithme LFU sur cet exemple, lobjet CarnetAdressePersonnel est invoqu dix fois et lobjet DossierModel est invoqu onze fois. Par consquence, cest lobjet CarnetAdressePersonnel qui va tre choisi dans lalgorithme pour le remplacement. Or, cet objet est plus frquemment accd que lobjet DossierModel dans les dix dernires secondes. Dans lalgo35

rithme que nous proposons,si la priode est par exemple gale dix secondes, le calcul du nombre dinvocations pour chaque objet commence partir de la vingtime seconde. Avec cet algorithme, la frquence de lobjet DossierModel est zro et celle de CarnetAdressePersonnel est cinq. Par consquence, cest lobjet DossierModel qui doit tre choisi par lalgorithme pour le remplacement. Objet CarnetAdressePersonnel DossierModel Instant dinvocation 2 , 3 , 7 , 9 , 12 , 21 , 23 , 25 , 26 , 29 1 , 2 , 4 , 6 , 10 , 13 , 15 , 16 , 17 , 18 , 19

TAB . 5.2 Un exemple de squences dinvocations des objet DossierModel et CarnetAdressePersonnel Nous envisageons deux solutions possibles pour concevoir notre algorithme de gestion du cache. La premire solution est que RM dispose dune table interne qui permet denregistrer le nombre dinvocations du client vers chaque objet non critique. Cette fonctionnalit est implante dans la mthode incrementeNumber() ajoute dans linterface ResourceManager. Cette mthode est appele par PI chaque invocation dun objet non critique. Lorsquun client invoque un objet non critique, RM incrmente le nombre dinvocations de cet objet dans sa table interne. Pour que le problme de la premire invocation dun objet non critique napparaisse pas, la cration de lobjet dconnect et lappel de la mthode incrementeNumber() sont faits aprs que RM ajoute une entre pour cet objet dans sa table interne. Le nombre dinvocations dun nouvel objet dans le cache est initialis zro. Priodiquement, RM ordonne cette table suivant la frquence dinvocations sur les objets (du moins invoqu vers le plus invoqu pendant la dernire priode). Quand RM dcouvre que la taille restant du cache est infrieure au seuil de disponibilit, il prend la premire entre de sa table interne et contrle si lobjet slectionn ne comporte pas des requtes sauvegardes dans le journal doprations (2) dans la gure 5.9. Dans le cas o le journal doprations ne contient pas dentres spciques lobjet slectionn, RM supprime du cache le DO et le CM (3, 4). RM excute la mme procdure avec la prochaine entre de la table interne jusqu ce que la taille du cache restante devienne suprieure au seuil de disponibilit. Linconvnient de cette solution est quelle gnre un nombre trs important de requtes, puisqu chaque fois que le client invoque un objet non critique lintercepteur portable invoque RM pour que ce dernier mette jour sa table interne. La deuxime solution que nous proposons est de mettre la table dinvocations dans lintercepteur portable. Dans cette solution, PI met jour la table dinvocations chaque fois que le client invoque un objet non critique. Quand RM saperoit que la taille du cache restante est infrieure au seuil, il demande PI de lui fournir la table dinvocations. Quand RM reoit la table dinvocations, il effectue le mme traitement que dans la premire solution. Cette solution pose le problme dinvocation de PI, puisque PI est un objet CORBA local qui ne peut pas tre invoqu de lextrieur de son unit dexcution. Nous proposons deux solutions ce problme. La premire solution prsente dans la gure 5.10 est de crer un objet corba (non local) PITable dans lunit dexcution de PI qui comporte une table interne dinvocation. Chaque fois que PI intercepte un invocation vers un objet non critique, il transmet les rfrences (nom de lobjet, heure dinvocation) de cette requte PITable. Si RM saperoit que la taille du cache restante est infrieure au seuil de disponibilit, il demande la table dinvocation de PITable. La deuxime solution est de crer un socket TCP ou UDP dans PI pour quil puisse tre invoqu par RM. Nous prfrons a priori la solution base dobjet CORBA.

36

F IG . 5.10 La cration dun objet intermdiaire entre PI et RM

Pour que RM sache que la taille du cache est infrieure au seuil, nous envisageons deux solutions. La premire solution (1.a dans la gure 5.9) consiste utiliser des notications du systme (UpCall en anglais). Dans cette solution, le systme doit notier RM chaque fois que la taille restante dans le cache est infrieure au seuil de disponibilit. Cependant, cette solution est trs difcile mettre en uvre puisquelle demande beaucoup de programmation systme. En outre, la plupart des systmes noffrent pas ce type de notication et si un systme offre cette notication, cela reste trs limits : par exemple, les signaux dans UNIX sont des notications au plus une fois et nacceptant pas dargument. La deuxime solution possible est que RM interroge le systme priodiquement pour rcuprer la taille du cache restante (1.b dans la gure 5.9). Cette solution est plus simple implanter que la premire solution et cest la solution que nous choisissons dans notre approche de gestion du cache. Lalgorithme de gestion du cache est donn dans la gure 5.11. Dans le cas o le journal doprations contient des entres spciques lobjet slectionn, RM passe lentre suivante jusqu ce quil trouve un objet qui ne comporte pas de requtes sauvegardes dans le journal doprations. Le problme est que le journal doprations peut contenir des entres pour tous les objets dconnects. En consquence, daprs lalgorithme de la gure 5.11, un bouclage linni sur la table interne du RM peut avoir lieu. Dans Domint, LM essaie priodiquement de vider le journal doprations (Cf. section 4.2). Donc, la procdure de traitement du journal doprations converge vers la transmission de toutes les requtes sauvegardes dans le journal doprations. Par consquent, RM tend trouver un objet qui ne comporte pas doprations sauvegardes dans le journal doprations.

5.5 Discussion
La mthode de dploiement propose dans ce chapitre peut se rsumer en deux points. Dabord, nous avons dvelopp un nouveau concept qui est la criticit des objets dans une application rpartie et les diffrentes algorithmes de dploiement de chaque catgorie dobjets. Ensuite, nous avons propos un algorithme de gestion du cache. Un point fort de notre approche de dploiement est que, tout moment, le cache du terminal mobile contient au minimum tous les objets critiques. Par rapport Coda qui utilise une approche de pr-chargement par le client pour le dploiement, dans notre approche, le choix des objets dployer sur le terminal mobile se fait entre le programmeur de lapplication et le client. En consquence, dans Coda, lapplication cliente en mode dconnect peut ne pas fonctionner si le client fait un mauvais choix. En outre, notre approche de partitionnement des objets de lapplication en objets critiques et objets non critiques est trs similaire celle de Coda qui partitionne les chiers de lutilisateur 37

Algoritme remplacerobjetNonCritique() { rel taillerestanteCache; objetCible objet; boolean aucun; taillerestanteCache = Systme.tailleRestante(cache); tant que (taille != seuil) { objetCible = tableInterne.suivant(); objet = objetCible.nom; aucun = LM.verifierExistenceOperationJournalisee(objet); Si (aucun == vrai) { // pas dentres dans le log pour cet objet SupprimerDO-et-CM-associ(); } Sinon { attentePassivement(dure); } } } } F IG . 5.11 Lalgorithme de gestion des objets non critiques

en donnes explicites qui reprsentent le choix du client et donnes implicites qui se composent de lhistorique du client. Le dploiement des donnes implicites se fait suivant un algorithme de chargement (les plus rcemment utiliss). Donc, un chier non choisi par lutilisateur peut ne pas exister dans le cache mme si le client utilise ce chier. Par contre, dans notre approche, si un client invoque un objet non critique, un objet dconnect est cr automatiquement dans le cache. Donc si le client se dconnecte juste aprs linvocation de cet objet, il peut faire des traitements sur lobjet dconnect cr dans son cache. Un autre point important dans notre approche est que lorsquun client mobile se dconnecte volontairement au lancement de lapplication, il peut travailler puisque son cache contient au minimum tous les objets critiques. Dans Rover et Coda, si un client se dconnecte volontairement au lancement de lapplication, il y a peu de chance que ce client puisse travailler en mode dconnect. Linconvnient de notre approche de dploiement est que le dploiement de tous les objets critiques au lancement de lapplication peut prendre du temps et est conditionn par la taille du cache. Notre protocole de dploiement peut tre dans une situation o tous les objets de lapplication existent dans le cache, en particulier, si lapplication invoque tous les objets non critiques ou si lutilisateur choisit tous les objets comme tant des objets critiques. Cette situation gnre le problme dencombrement du cache, notamment avec les terminaux mobiles. Pour rgler ce problme, nous avons propose un protocole de gestion de cache qui est prsent dans la section 5.4.2. Lavantage principale de ce protocole est quil ne supprime que les objets non utiliss dernirement par le client. De plus, les objets que lalgorithme peut supprimer sont les objets non critiques de lapplication. Linconvnient majeur est que la taille du cache doit tre infrieure la somme de toutes les tailles des objets critiques. Or, cette hypothse ne tient pas compte de la croissance des objets critiques.

38

Chapitre 6 Ralisation
Dans ce chapitre, nous illustrons et validons lapproche de dploiement et de gestion du cache que nous avons tudie dans le chapitre 5. Cette validation se fait dans le cadre dune application de messagerie lectronique dans un environnement sans l.

6.1 Prototype de ralisation

La ralisation est effectue sur la plate-forme Domint.Dans cette ralisation, nous utilisons lORB ORBacus 4.1.0 de O.O.C. (Object Oriented Concept). Il est conforme la norme CORBA 2.4 qui fournit plusieurs mcanismes, en particulier, les intercepteurs portables. En outre, nous utilisons le langage JAVA. Cette ralisation respecte larchitecture prsente dans la gure 6.1. Dans cette architecture, chaque terminal mobile dispose dun service DOM (gestionnaire des objets dconnects) qui permet de grer les dconnexions de lutilisateur et faire la commutation transparente entre lobjet distant et lobjet dconnect, suivant le niveau de connectivit donn par lhystrsis.

F IG . 6.1 Le prototype dimplmentation

39

6.2 Application exemple

Pour illustrer lutilisation de lapproche de dploiement et de gestion du cache que nous avons dveloppes dans ce rapport, nous avons choisi dimplanter cette approche sur lapplication de messagerie lectronique vue dans la section 5.1.3. Nous rappelons que cette application est la mme que celle dveloppe par lquipe MARGE de lINT pour illustrer larchitecture de Domint. Cette application offre des fonctionnalits simplies similaires des logiciels courants tels que Netscape messenger ou Microsoft IE. Lutilisateur manipule des messages consistant en un corps et un en-tte compos de lidentiant du message (un entier), les noms de lmetteur et du destinataire, le sujet, la date dmission et ltat du message (lu ou non lu). Les principales oprations accessibles par linterface graphique sont lenvoi dun nouveau message, dune rponse ou dun message suivre, la rception dun message et leffacement dun message. Pour implanter notre mcanisme de dploiement et celui de gestion du cache, nous avons ajout quatre objets lapplication de messagerie lectronique. Ces objets sont prsents dans la gure 6.2 et sont les mmes tudis dans la section 5.1.3.

F IG . 6.2 Lapplication de messagerie lectronique

Tous les interfaces du serveur sont spcies dans le module IDL Mail, tandis que les objets dconnects sont spcis dans le module IDL MailDM. Lobjet Gestionnaire est cr au lancement de lapplication ct serveur. Par contre, les autres objets sont crs partir de lobjet Gestionnaire. En plus, dans notre application, tous les objets sont enregistrs dans le service de nommage.

6.3 Mise en uvre

Dans lapplication de messagerie lectronique, les IOR des objets qui permettent le mode dconnect sont "tagues" par la politique de dconnextion ajouts par les intercepteurs dIOR (Cf. section 4.1.2). Lintercepteur dIOR permet dajouter un composant mode dconnect toutes les rfrences des objets dune application demandant le support des oprations dconnectes. Le nouveau composant contient un boolen localCopy indiquant si lobjet rfrenc doit possder ou non un objet dconnect sur le terminal mobile. Ce boolen est gal faux pour les objets qui nautorisent pas un objet dconnect pour le mode dconnect et vrai si cest le cas. Limplantation de cette nouvelle politique se fait dans la classes DOMPolicyFactory. Donc, lintercepteur portable (PI) 40

ne demande de crer des objets dconnects que pour les objets dont lIOR comporte la politique de dconnexion. Pour implanter cette politique, lapplication de messagerie lectronique comporte le module pi donn par la dclaration IDL suivante : module pi { /** * Objet politique pour la gestion des dconnexion * Cet objet sera associe au IOR de lobjet distant */ const CORBA::PolicyType DOM_POLICY_ID = 1010; /** * Ajouter le boolen "localCopy" dans CORBA::Policy * pour indiquer si lORB autorise les objets * dconnects sur les terminaux mobiles. */ local interface DOMPolicy : CORBA::Policy { readonly attribute boolean localCopy; }; const IOP::ComponentId DOM_TAG_COMPONENT = 1010; } Le fonctionnement du lintercepteur portable est donn dans la classe CRIDisconnect. Cette classe implante linterface ClientRequestInterceptor vue dans la section 4.1.1. Toutes les requtes et les rponses sont interceptes du ct du terminal mobile. Lors de lenvoi de la premire requte un objet dont la rfrence contient un composant avec localCopy vrai, lintercepteur cre un adaptateur puis un objet dconnect vide. Lobjet vide est rempli en appelant lopration incrementalStateTransfert() sur lobjet distant. Ensuite, cette mise jour de lobjet dconnect est effectue priodiquement condition que la connectivit soit bonne. Pour chaque requte du client, lintercepteur ct client dcide quel objet recevra la requte. Si la destination effective doit changer, le point dinterception excut lors de lenvoi lve lexception CORBA RequestForward. Cette exception contient lIOR de la nouvelle destination. LORB retransmet automatiquement la mme requte sur la nouvelle destination. Le mcanisme de dploiement que nous avons dvelopp se base sur le partitionnement des objets en objets critiques et objets non critiques. La premire ide que nous avons eu pour ce partitionnement est dajouter un composant "type dobjet" tous les IOR des objets. Le nouveau composant contient un boolen ObjetCritique indiquant si lobjet est critique ou non. Cette solution nest oprationnelle que pour les applications pour lesquelles les objets du serveur ne sont manipulables que par un seul client, puisque chaque objet contient une seul politique de criticit. La deuxime solution est de travailler avec un chier de conguration qui contient le nom logique et la criticit de lobjet. Chaque utilisateur peut ainsi possder son propre chier de conguration. Dans cette ralisation, cest la deuxime solution que nous choisissons. Un exemple de partitionnement des objets de lapplication de messagerie lectronique est donn dans la table 5.1. La cration des objets dconnects pour les objets non critiques se fait dans la mthode deployer() de lobjet ResourceManager. Cette mthode prend en entre deux chanes de caractres : 41

 fichier qui reprsente le chemin daccs du chier de conguration. userName qui reprsente le nom de lutilisateur de la bote au lettres. Lopration deployer() est appele par lintercepteur portable dans le constructeur de lobjet CRIDisconnect. Lintercepteur portable trouve le point dentre de DOM qui permet de trouver les objets ResourceManager et LogManage en appelant les mthodes findResourceManager et findLogManager respectivement. Le traitement faire dans lopration deployer() peut se rsumer comme suit. Dabord, lopration deployer() rcupre le chier de conguration dont le chemin daccs est donn par le paramtre dentre fichier. Ensuite, pour chaque entre de ce chier, elle contrle le type de criticit de cet objet via la champ "type" du chier de conguration. Si lobjet est critique, lopration deployer() rcupre la rfrence de lobjet distant du service de nommage et cre lobjet dconnect qui sera attach lORB de DOM. Une fois lobjet dconnect activ, lopration deployer() cre un gestionnaire de connectivit (CM) pour lobjet dconnect qui sera attach au mme ORB. Enn, une entre est ajoute dans la table interne de lintercepteur portable qui comporte la rfrence de lobjet distant et la rfrence du gestionnaire de connectivit associ. Comme dcrit dans le chapitre 5, le dploiement des objets non critiques se fait la premire invocation sur cet objet. Au lancement de lapplication, lintercepteur portable rcupre le chier de conguration que lutilisateur a modi. linterception dune requte, lORB appelle la mthode send_request() de lobjet ClientRequestInterceptor implant dans la classe CRIDisconnect. Cet appel prend comme paramtre un objet de type ClientRequestInfo qui donne toutes les informations sur la requte, en particulier, la rfrence de lobjet invoqu, lopration invoque et les paramtres de cette invocation (Cf. section 4.1.1.2). Aprs avoir rcupr la rfrence de lobjet invoqu, lintercepteur portable vrie le type de criticit de cet objet partir du chier de conguration. Dans le cas o lobjet est non critique, lintercepteur portable parcourt sa table interne pour vrier si lobjet existe dans le cache. Si la table interne de lintercepteur portable ne comporte pas dentre pour cet objet, lintercepteur portable appelle la mthode createConnectivityManager() de lobjet gestionnaire de ressources RM. Cette mthode prend en paramtre la rfrence de lobjet invoqu et elle permet de crer lobjet dconnect et le gestionnaire de connectivit associ. Une fois lobjet dconnect cr, lintercepteur portable ajoute une entre pour cet objet dans sa table interne.

6.4 Travail en cours

linstant o nous crivons ces lignes, nous navons implant que le mcanisme de dploiement que nous avons propos. Le travail en cours est dimplanter notre approche de gestion du cache. Ensuite, nous envisageons de faire des tests de performance sur le dploiement et la gestion du cache.

42

Chapitre 7 Conclusion
Le domaine des systmes rpartis est en pleine volution, en particulier les applications rparties qui relient des terminaux mobiles et des serveurs xes. Or, la plupart de ces applications sont rarement optimales. En effet, de trop nombreux paramtres inuent sur la performance de ces applications. Il est donc souhaitable de fournir une continuit de service malgr les dconnexions et les perturbations du rseau sans l, notamment sur les terminaux mobiles. Pour fournir la continuit de service, le systme doit avoir un mcanisme de dploiement des donnes dans le terminal mobile pour traiter le problme de dconnexion. Ltude de la littrature sur la mobilit dans les systmes rpartis a permis de souligner les besoins en dploiement pour les applications fonctionnant en mode dconnect. Cette tude de la littrature nous a permis de classer les diffrents mcanismes de dploiement qui existent en quatre approches : pas de cache local au terminal mobile, mise en cache systmatique des donnes, mise en cache des donnes la demande et pr-chargement des donnes. Nous avons propos des algorithmes pour, dune part, dvelopper un mcanisme de dploiement des objets dans les terminaux mobiles pour le fonctionnement en mode dconnect, dautre part, grer la mmoire virtuelle du terminal mobile. Nous avons tendu la plate-forme Domint pour traiter le problme du dploiement et de la gestion du cache. Bien que la priode du stage ne soit pas sufsante pour ralisation entirement de notre approche, nous avons complt une application de messagerie lectronique sur la plate-forme Domint et nous avons implant les parties concernant le dploiement. Lapproche dfendue dans ce rapport repose sur la notion de criticit dobjet. La premire tape du dploiement consiste partitionner les objets de lapplication en objets critiques et objets non critiques. Les objets critiques sont les objets ncessaires pour le fonctionnement de lapplication en mode dconnect, tandis que les objets non critiques sont les objets dont labsences pendant une dconnexion nempche pas lapplication de continuer fonctionner. Le dploiement des objets critiques se fait au lancement de lapplication. Par contre, le dploiement des objets non critiques se fait la premire invocation par lapplication. Lalgorithme de gestion du cache propos se base sur lalgorithme LFU. Dans cet algorithme, le remplacement des objets nest effectu que sur les objets non critiques. Larchitecture de dploiement et de gestion du cache peut tre implante sur nimporte quel systme qui offre le mcanisme dinterception des requtes. Par ailleurs, le cache du terminal mobile contient au minimum tous les objets ncessaires pour le fonctionnement de lapplication, ce qui donne une meilleur disponibilit du service applicatif en mode dconnect. Cependant, larchitecture est trs lie la smantique de lapplication, ce qui rend lapplication non transparente lutilisateur. En outre, la mise en uvre de notre approche de dploiement et de gestion du cache est lie au mcanisme des intercepteurs non disponibles dans tous les systmes. 43

7.1 Perspectives
Larchitecture dcrite dans ce rapport permet aux programmeurs et aux utilisateurs de congurer facilement leur systme de dploiement et de gestion du cache. Cependant, la dmarche nest pas totalement intuitive. Pour pouvoir tre utilise le plus largement, il faudra donc la simplier au maximum. Plusieurs extensions du travail prsent dans ce rapport peuvent tre envisages en termes de faciliter dutilisation, denrichissement et dapplication dautres types de systmes. La premire extension possible pour le concept de criticit des objets est de dnir une criticit dynamique des objets. Cette ide est semblable celle utilise dans le systme SEER : lapplication doit prdire le future besoin de lutilisateur pour mettre jour la liste des objets qui doivent exister dans le cache. La deuxime extension possible est lajout du rle de ladministrateur de lapplication dans le partitionnement des objets de lapplication et de traiter le problme de propagation de la criticit entre les classes de lapplication. La collecte dinformations sur le cache est base sur lalgorithme LFU. Or, cet algorithme est trs limit en termes de performances. Une ide de dpart pour amliorer notre approche de gestion du cache est de dnir une fonction de cot sur les objets de lapplication. Cette fonction peut tenire en comte la criticit de lobjet, le type de rseau partir duquel se fait la communication avec lobjet distant et la taille de lobjet. La forme de cette fonction reste un sujet de recherche dans les annes venir.

44

Bibliographie
[AFM98] A.P. Afonso, S.R. Francisco, and J.S Mrio. UbiData : An Adaptable Framework for Information Dissemination to Mobile Users. In Proc ECOOP 98 Workshop on Mobility and Replication, DI Campo Grande, Lisboa Portugal, 1998. A. Baggio. Replication and Caching Strategies in Cadmium. Technical Report 3409, INRIA France, Avril 1998.

[Bag98]

[CCVB02a] D. Conan, S. Chabridon, O. Villin, and G. Bernard. Disconnected Operations in Mobile Environments. In Proc. 2nd IPDPS Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing, Ft. Lauderdale, USA, April 2002. [CCVB02b] D. Conan, S. Chabridon, O. Villin, and G. Bernard. A Disconnected Object Management Service for Mobile Environments. Technical report, INT France, Avril 2002. [CCVB02c] D. Conan, S. Chabridon, O. Villin, and G. Bernard. Weak Connectivity and Disconnected CORBA Objects. submitted, Avril 2002. [GAK00] [GG97] [HL96] B. Gerald, V. Andreas, and D. Keith. Java Programming with CORBA. Wiley Computer Publishing, 2000. H.K. Geoffrey and J.P. Gerald. Automated Hoarding for Mobile Computers. In Proc 16th Symposium on Operating Systems Principles (SOSP97), pages 264275, 1997. B.C. Housel and D.B. Lindquist. WebExpress : A system for optimizing Web Browsing in a Wirless Environment. In Proc. ACM Symposium on Principles of Distributed Computing (MOBICOM96), NY USA, November1996. J. Jing, A. Helal, and A. Elmagarmid. Client-Server Computing in Mobile Environments. ACM Computing Surveys, 31(2), June 1999. A.D. Joseph, J.A. Tauber, and M.F. Kaashoek. Rover : A toolkit for mobile information access. Proc 16th Symposium on Operating Systems Principles (SOSP95), December 1995. A.D. Joseph, J.A. Tauber, and M.F. Kaashoek. Mobile computing with the Rover toolkit. ACM Transactions on Computers, 46(3), 1997. J. J. Kistler and M. Satyanarayanan. Disconnected Operation in the Coda File System. In Proc 13th ACM Symposium on Operating Systems Principles, number 5, pages 213 225, Pacic Grove, USA, 1991. G. Kuenning. Design of the SEER predictive caching schema. In Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, U.S.A, 1994. N. Lynch. Supporting Disconnected Operation in Mobile CORBA. M.sc. thesis, Trinity College Dublin, 1999. L.B. Mummert. Exploiting Weak Connectivity in a Distributed File System. PhD thesis, September 1996. 45

[JHE99] [JTK95]

[JTK97] [KS91]

[Kue94] [Lyn99] [Mum96]

[NSN 97]

[OMG01] [PTT 94]

[PTT 97]

[RS96] [RSK00]

R. Ruggaber, J. Seitz, and M. Knapp. - A Generic Proxy Platform for Wireless Access and Mobility. In Proc. 19th ACM Symposium on Principles of Distributed Computing (PODC2000), Portland, Oregon, July 2000. M. Satyanarayanan. Fundamental Challenges in Mobile Computing. In Proc 15th Symposium on Principles of Distributed Computing (PODC96), pages 17, 1996. M. Satyanarayanan. Mobile Information Access. IEEE Personal Communications, 3(1), 1996. A. Silberschatz and P.A. Galvin. "Principes des systmes dexploitation". AddisonWesley, 1998. D.B. Terry, M.M. Theimer, K. Petersen, A.J. Demers, M.J. Spreitzer, and C.H. Hauser. Managing Update Conicts in Bayou : A Weakly connected Replicated Storage System. Proc 15th Symposium on Operating Systems Principles (SOSP95), 1995.

[Sat96a] [Sat96b] [SG98] [TTP 95]

46

B.D. Noble, M. Satyanarayanan, D. Narayanan, J.E. Tilton, J. Flinn, and K.R. Walker. Agile Application-Aware Adaptation for Mobility. In Proc. 16th ACM Symposium on Operating System Principles (SOSP97), Saint-Malo, France, October 5-8, 1997. OMG. Portable Interceptors. Interceptors Finalization Task Force. Published draft, Object Management Group, September 2001. K. Petersen, D.B. Terry, M.M. Theimer, A.J. Demers, J. Spreitzer, and B. Welch. The Bayou Architecture : Support for Data Sharing among Mobile Users. In Proc of the 1994 Workshop on Mobile Computing Systems and Applications, 1994. K. Petersen, D.B. Terry, M.M. Theimer, A.J. Demers, and J. Spreitzer. Flexible Update Propagation for Weakly Consistent Replication. Proc 16th Symposium on Operating Systems Principles (SOSP97), 1997. M. Raynal and M. Singhal. Capturing Causality in Distributed Systems. Computer IEEE, February 1996.