Universit dvry-Val dEssonne

Institut National des Tlcommunications

Rapport de Stage
DEA dInformatique

M OBILIT

DANS LES SYSTMES RPARTIS :

LE DPLOIEMENT SUR LE TERMINAL MOBILE

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 enfin, mes parents, mes frres, mes surs et mes amis qui mont soutenu tout au long
de ce stage.

ii

Table des matires

1

Introduction

Problmatique et objectifs du stage

2.1 Sujet du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Rsum du contexte du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3
3
4

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 conflits . . . . . . . . . . . . . . . .
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

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

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

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

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

19
19
20
21
22
22
22
23

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 . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25
25
25
27
28
30
30
30
31
32
32
34
34
35
37

.
.
.
.

39
39
40
40
42

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

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 figures

2.1

Positionnement du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1
3.2
3.3
3.4
3.5

Les stratgies dadaptation .

Les tats de Venus dans Coda
Larchitecture dOdyssey . .
Larchitecture de Bayou . . .
Larchitecture de Rover . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

. 6
. 8
. 10
. 11
. 12

4.1
4.2
4.3
4.4

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 . . . . . . . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

18
20
21
23

5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11

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 . . . . . .

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

26
27
28
30
31
32
33
34
35
37
38

6.1
6.2

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

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

vi

Liste des tableaux

3.1

La mthode de dploiement dans les diffrents systmes . . . . . . . . . . . . . . . 15

5.1
5.2

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 fil inter-connectant des machines mobiles comme
des tlphones portables ou des assistants personnels numriques (PDA). Cette volution a abouti
la dfinition 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 fiabilit. 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 fil est trs variable en terme de performance et de fiabilit.
Les lments mobiles possdent des sources dnergie finies.
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 fil. 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. Enfin, 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 spcification CORBA de lOMG (Objects Management Group) et est conue pour tre extensible et
volutive afin 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 fil.
Nous considrons deux types de dconnexions : les dconnexions volontaires et les dconnexions
involontaires. Les premires, dcides par lutilisateur depuis son terminal mobile, sont justifies
par les bnfices attendus sur le cot financier 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 figure 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 dfinir 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 dfinit trois mode de connectivit :
1. Mode fortement connect : dans ce cas de figure, 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 filaire, soit par une interface de communication sans fil, 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 fil.
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 spcification CORBA.
Une architecture client-serveur flexible (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). Enfin, 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. figure 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 flou [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 afin 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 fixe). 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 fichiers. 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 fichiers 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 modifications, de dtecter les conflits 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 conflits 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 modifications "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 figure 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 fichiers 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 modifications 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
fichiers 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 fichier dans le cache, Venus ne gardera que lopration de suppression dans le
CML.
3.2.1.3 Dtection et rsolution des conflits
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 fichier est mis jour, le serveur incrmente le numro de version du fichier et celui
du volume qui contient le fichier. 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 fichiers
cachs de ce volume. Sil est incorrect alors il doit valider fichier par fichier. Dautre part, si la
validation individuelle dun fichier 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 suffisante pour rsoudre des conflits de fichier,
il offre un mcanisme pour installer et appeler dune manire transparente un rsolveur spcifique
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 conflits, 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].
8

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 fidlit des
donnes. La notion de fidlit dpend du type de donnes dans le systme de fichiers. 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 fidlit. Par exemple, dans les applications multimedia qui traitent des fichiers de type image, nous
donnons pour chaque image trois niveaux de fidlit suivant le nombre de couleurs disponible (noir
et blanc, 256 couleurs, 16 millions couleurs). Le systme de gestion de fichiers 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 figure 3.3. Daprs cette figure, 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 notifie
lapplication quand les bornes de la fentre de tolrance sont franchies. Deuximent, Odyssey offre
une fonctionnalit spcifique 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 figure
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 identifiant une ressource et indiquant une fentre
de tolrance sur sa disponibilit. Cet appel exprime le dsir de lapplication dtre notifie si
la disponibilit de la ressource est en dehors des bornes de la fentre de tolrance.
3. Notifier les applications : quand le vice-roi dcouvre que la disponibilit dune ressource est
infrieure la fentre de tolrance, il envoie une notification "upcall" lapplication correspondante pour ajuster sa fidlit 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.
figure 3.4). Lapplication cliente communique avec le serveur travers une interface spcifique
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 modifications 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 modifi 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 figure 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. figure 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 modifie 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 conflits
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 file ("Wireless CORBA"). Dans ce cas, la mobilit matrielle est provoque par le
changement de cellule ("handover") et par consquent des dconnexions courtes.

se base sur la mise au point de deux proxies (un sur le terminal mobile et
Larchitecture de
un autre dans le rseau filaire) 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 spcifique 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 fichiers ou des bases de donnes, car il est trs difficile 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 fichiers 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 fichiers, classant chaque accs selon le type (de fichier :
texte, vido, image . . .). SEER [GG97] emploie un concept connu de distance smantique pour mesurer lintuition dun utilisateur concernant les relations entre les fichiers. SEER dfinit plusieurs
distance smantique entre les fichiers :
La distance smantique temporelle est la dure qui spare lutilisation des deux fichiers.
La distance smantique base de squences est le nombre de rfrences vers dautre fichiers
entre lutilisation des deux fichiers. Par exemple, dans la squence daccs suivante A,S,S,X,B,
la distance smantique entre le fichier A et le fichier B est gale trois.
La distance smantique de vie entre louverture dun fichier A et louverture dun fichier
B est dfinie 0 si A na pas t ferm pendant que B est ouvert. Sinon, cest le nombre
dinterventions douvertures dautres fichiers y compris louverture du fichier B.
Lobservateur fournit les rsultats des observations un composant de corrlation. Le composant
de corrlation value les rfrences des fichiers et calcule les distances smantiques. Quand un nouveau contenu de cache doit tre choisi, le composant de corrlation examine lensemble des fichiers
pour trouver ceux qui sont actuellement en activit et choisit les fichiers 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-dfinie. 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 notification 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 didentifier 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-dfinie 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.
Enfin, 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 fixe. 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 flux 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 spcifie dans le module PortableInterceptor.
CORBA dfinit 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 flux des requtes-rponses travers
lORB en des points spcifiques appels des points dinterception. Deux types dintercepteur de
requtes sont dfinis : les intercepteurs ct client et les intercepteurs ct serveur.
17

4.1.1.1 Intercepteur ct client et ct serveur

Dans la figure 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 dfinies 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.
Afin 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 spcifiquement
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 figures 4.2 et 4.3 [CCVB02c]. Les deux
figures 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 figures 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.
PI

Remote
Object

Client
<< new >>
2.1

4.2

DO

2.2
2.3

2.2.1.1
2.2.1.2

2.2.1.3
4.1.2

4.1.1

DOM

LM
2.2.1

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 figure 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 flche 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).
Enfin, 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

Client

Remote
Object

5.b.3

DO
5.a.1
5.b.1

5.a.2.2

5.b.2

DOM

LM

5.a.2.1

RM
CM
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 figure 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 fil 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 findResourceManager() 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 findConnectivityManager() 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 fixe. Domint dfinit un mcanisme dlhystrsis (Cf.
figure 4.4) qui permet de grer la connectivit entre lobjet distant et DO.
Sur la figure 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 figure 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

B
lowDown

B
lowDown

(1)
disconnected

highUp

A
lowUp

lowUp

(2)
partially
connected

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 dfinir 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. Enfin, 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 spcification du
contrat sous forme dinterfaces crites en IDL, qui permettent de dfinir 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 figure 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 fixe 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 figure 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 fixe.
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 figure,
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 fixe peut avoir un objet dconnect, puisque lutilisation de cet objet par lutilisateur en
mode dconnect permet quand mme lobjet rest sur le serveur fixe 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 classification est prsente dans la figure 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 classification 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 classification de ces objets. La premire mthode est
de classifier 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 figure 5.3, la classe Classe
1 est dclare comme tant une classe qui gnre des objets critiques (marque par une toile dans la
figure). 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 classification 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 figure 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 configuration de lapplication au moment de linstallation, lutilisateur peut forcer un objet non critique
du programmeur devenir critique. Dans la figure 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

Afin de mieux comprendre notre concept de criticit, nous donnons dans cette section un exemple
de classification 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-dfinis 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 classification, 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 final" : union du choix du programmeur et de lutilisateur.
Autorisant le
Classe

Objet

mode
dconnect

MailBox
BotMessage
MailBoxManager
Gestionnaire
CarnetAdresse
CarnetAdressePersonnel
DossierMsgSupprime
Dossier
DossierModel
DossierMsgEnvoye

oui
non
oui
oui

Criticit

Choix P
OC
ONC
ONC

Choix U Choix final

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 modifier 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 figure 5.4 prsente notre approche de dploiement. Cette approche dpend de la nature des
objets dployer. Daprs la figure 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 vrifie 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 figure
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. Enfin, 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 modifier ltat de lobjet ou rcuprer des
donnes.

5.3 tapes de conception

Le figure 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 configuration 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
modifie une fois quelle est fixe 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 figure 5.6. Cette figure prsente un diagramme de collaboration UML, il dcrit lalgorithme de dploiement des objets critiques
prsent dans la figure 5.7. Les information sur la criticit des objets sont contenus dans un fichier
de configuration. Chaque entre de ce fichier 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 fichier 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 fichier de configuration est construit par le programmeur de lapplication durant la phase de

programmation. Au lancement de lapplication ou au moment de la configuration de lapplication,
32

lutilisateur peut modifier ce fichier pour choisir parmis les objets non critiques du programmeur
ceux qui deviennent critiques.
Au lancement de lapplication et aprs la mise jour du fichier de configuration par le client
(Client dans la figure 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 figure 5.7 en lui passant ladresse du fichier de configuration. Dans cet algorithme,
RM parcourt le fichier de configuration, et pour chaque entre, effectue les oprations suivantes.
Dabord, il vrifie 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 figure 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 figure), 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 efficace 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 figure 5.9.
Notre approche dfinit deux nouveaux paramtres spcifis 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 dfini 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 dfinir 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 figure 5.9. Dans le cas o le journal
doprations ne contient pas dentres spcifiques 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 figure 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 figure 5.9) consiste utiliser des notifications du systme (UpCall
en anglais). Dans cette solution, le systme doit notifier RM chaque fois que la taille restante
dans le cache est infrieure au seuil de disponibilit. Cependant, cette solution est trs difficile
mettre en uvre puisquelle demande beaucoup de programmation systme. En outre, la plupart des
systmes noffrent pas ce type de notification et si un systme offre cette notification, cela reste trs
limits : par exemple, les signaux dans UNIX sont des notifications 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 figure 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 figure 5.11. Dans le cas o
le journal doprations contient des entres spcifiques 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 figure 5.11, un bouclage
linfini 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 fichiers 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 fichier non choisi par lutilisateur peut ne pas
exister dans le cache mme si le client utilise ce fichier. 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 fil.

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 figure 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 simplifies 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 lidentifiant 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 figure 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 spcifies dans le module IDL Mail, tandis que les objets
dconnects sont spcifis 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 fichier de configuration qui contient le
nom logique et la criticit de lobjet. Chaque utilisateur peut ainsi possder son propre fichier de
configuration. 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 fichier de configuration.

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 fichier de configuration dont le chemin daccs est donn
par le paramtre dentre fichier. Ensuite, pour chaque entre de ce fichier, elle contrle le
type de criticit de cet objet via la champ "type" du fichier de configuration. 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. Enfin, 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 fichier de
configuration que lutilisateur a modifi. 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 vrifie le type de criticit de cet objet partir du fichier de configuration.
Dans le cas o lobjet est non critique, lintercepteur portable parcourt sa table interne pour vrifier
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 fixes. Or, la plupart de ces applications sont
rarement optimales. En effet, de trop nombreux paramtres influent 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 fil, 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 suffisante 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 configurer
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 simplifier 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 dfinir 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 dfinir 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.

[Bag98]

A. Baggio. Replication and Caching Strategies in Cadmium. Technical Report 3409,

INRIA France, Avril 1998.

[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]

B. Gerald, V. Andreas, and D. Keith. Java Programming with CORBA. Wiley Computer Publishing, 2000.

[GG97]

H.K. Geoffrey and J.P. Gerald. Automated Hoarding for Mobile Computers. In Proc
16th Symposium on Operating Systems Principles (SOSP97), pages 264275, 1997.

[HL96]

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.

[JHE99]

J. Jing, A. Helal, and A. Elmagarmid. Client-Server Computing in Mobile Environments. ACM Computing Surveys, 31(2), June 1999.

[JTK95]

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.

[JTK97]

A.D. Joseph, J.A. Tauber, and M.F. Kaashoek. Mobile computing with the Rover toolkit. ACM Transactions on Computers, 46(3), 1997.

[KS91]

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, Pacific Grove, USA, 1991.

[Kue94]

G. Kuenning. Design of the SEER predictive caching schema. In Workshop on Mobile

Computing Systems and Applications, Santa Cruz, CA, U.S.A, 1994.

[Lyn99]

N. Lynch. Supporting Disconnected Operation in Mobile CORBA. M.sc. thesis, Trinity

College Dublin, 1999.

[Mum96]

L.B. Mummert. Exploiting Weak Connectivity in a Distributed File System. PhD thesis,
September 1996.
45

[NSN 97]

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.

[OMG01]

OMG. Portable Interceptors. Interceptors Finalization Task Force. Published draft,

Object Management Group, September 2001.

[PTT 94]

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.

[PTT 97]

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.

[RS96]

M. Raynal and M. Singhal. Capturing Causality in Distributed Systems. Computer

IEEE, February 1996.

[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.

[Sat96a]

M. Satyanarayanan. Fundamental Challenges in Mobile Computing. In Proc 15th

Symposium on Principles of Distributed Computing (PODC96), pages 17, 1996.

[Sat96b]

M. Satyanarayanan. Mobile Information Access. IEEE Personal Communications,

3(1), 1996.

[SG98]

A. Silberschatz and P.A. Galvin. "Principes des systmes dexploitation". AddisonWesley, 1998.

[TTP 95]

D.B. Terry, M.M. Theimer, K. Petersen, A.J. Demers, M.J. Spreitzer, and C.H. Hauser. Managing Update Conflicts in Bayou : A Weakly connected Replicated Storage
System. Proc 15th Symposium on Operating Systems Principles (SOSP95), 1995.

46