Services de mobilité et de persistance des applications Java

Services de mobilité et de persistance
des applications Java
Sara Bouchenak and Daniel Hagimont
Chapter 6 of Les intergiciels – développemens récents dans CORBA,
Java RMI et les agents mobiles , Edited by Hermès, 2002.

149
Chapitre 6
Services de mobilité et de persistance
des applications Java
6.1. Introduction
Un service de capture/restauration de l’état des flots de contrôle a de nombreux
domaines d’utilisation, tels que la mobilité des applications ou la persistance des
applications. Ce service, seul ou complété par d’autres, peut aider à la mise en œuvre
d’outils comme l’équilibrage dynamique de charge entre plusieurs machines
[NIC 87], la diminution du trafic réseau par déplacement des clients vers leur serveur
[DOU 92], la reconfiguration dynamique d’applications distribuées [BEL 98,
HOF 93], la mise en œuvre de plates-formes à agents mobiles [CHE 95] ou
l’administration de machines [OUE 96]. Il peut aussi servir à la tolérance aux pannes
[OSM 97] et au débogage des applications. La fourniture de ces outils dépend en
partie de la disponibilité d’un service de capture/restauration de l’état des flots de
contrôle.
Le développement d’applications réparties mettant en œuvre un grand nombre de
machines interconnectées par des réseaux généraux, notamment l’Internet, est un
domaine de recherche en plein essor.1Dans ce contexte, le langage à objets Java a
connu un rapide succès. Le compilateur Java fournit un code intermédiaire (byte
code) interprété par une machine virtuelle, la Java Virtual Machine ou JVM. La
JVM est implantée sur la plupart des stations de travail et des ordinateurs personnels,
Chapitre rédigé par Sara BOUCHENAK et Daniel HAGIMONT.

150 Les intergiciels
ce qui fait que le couple langage Java-JVM est considéré comme la plate-forme de
référence des applications développées pour l’Internet. Un des intérêts majeurs de la
très grande diffusion de cette plate-forme est qu’elle permet de considérer
l’ensemble des machines virtuelles Java de l’Internet comme une base homogène
pour construire des services répartis, et notamment des services systèmes.
La machine virtuelle Java fournit plusieurs services facilitant le développement
des applications :
- les services de sérialisation et désérialisation permettent respectivement de
capturer et de restituer l’état d’un graphe d’objets Java ; ces services peuvent
être utilisés pour déplacer des objets entre différentes machines ou pour
sauvegarder des objets sur le disque ;
- le chargement dynamique des classes permet de déplacer du code Java vers
d’autres nœuds.
En revanche, Java ne fournit pas de service permettant de capturer et de restituer
l’état d’un flot de contrôle (ou thread), car la pile Java d’un flot de contrôle n’est pas
accessible. Un tel service permet d’une part d’extraire l’état courant de l’exécution
du flot, et d’autre part de restituer cet état pour que l’exécution reprenne au point où
elle en était au moment de la capture.
Dans ce chapitre, nous décrivons tout d’abord la réalisation d’un service de
capture/restauration d’état des flots Java, un service générique qui peut être utilisé
aussi bien pour la mobilité des applications Java que pour leur persistance. Nous
présentons ensuite les expérimentations effectuées avec ce service et le résultat des
mesures de performances.
La suite de ce chapitre est organisée comme suit : le paragraphe 6.2 décrit l’état
de l’art. Les paragraphes 6.3 et 6.4 présentent respectivement la conception et la
réalisation de notre service de capture/restauration d’état des flots Java. Le
paragraphe 6.5 présente la mise en œuvre de la mobilité et de la persistance des
applications Java grâce à notre service. Quelques expérimentations effectuées avec le
service fourni, une discussion et une évaluation de ce service sont décrites aux
paragraphes 6.6 et 6.7. Enfin, une conclusion est proposée au paragraphe 6.8.
6.2. Etat de l’art
Il existe principalement trois approches pour aborder le problème de capture et
de restauration de l’état des flots Java : une approche dite explicite, une approche
dite implicite se basant sur un préprocesseur de code et une autre approche implicite
qui étend la JVM.

Services de mobilité et de persistance des applications Java 151
La première approche, appelée gestion explicite, consiste à laisser entièrement à
la charge du programmeur de l’application la gestion de la capture et de la
reconstruction de l’état de son application. Le programmeur doit donc ajouter du
code qui effectue ce travail, en des points fixes de l’application, dits points de
sauvegarde. En un point de sauvegarde, le code ajouté doit enregistrer l’état de
l’exécution : il note la dernière instruction exécutée et l’état courant de l’application.
Lors de la reprise de l’exécution, le premier traitement effectué est un branchement
vers le dernier point de sauvegarde enregistré ; ainsi, l’exécution peut reprendre au
point où elle a été interrompue. Cette solution manque de souplesse, car la gestion
des points de sauvegarde est entièrement à la charge du programmeur. De plus,
l’ajout ou la modification de points de sauvegarde induit une modification de
l’application elle-même. Cette gestion explicite est utilisée dans les applications
faisant appel à des plates-formes à agents mobiles [CHE 95] fournissant une
migration faible tels que les Aglets [IBM 96] ou Mole [BAU 98].
Les deux autres approches, dites implicites, fournissent un service transparent de
capture/restauration de l’état des flots de contrôle. Le service fourni est indépendant
du code de l’application ; il se présente sous la forme d’une primitive appelée par
l’application elle-même ou par une application externe. Ces deux approches diffèrent
par leur mise en œuvre :
- la première approche implicite consiste à fournir un préprocesseur qui injecte
du code soit dans le code source de l’application, soit dans son code
intermédiaire Java. Lors de l’exécution de l’application, le code injecté crée
un objet Java, que l’on nommera backup, et l’associe à l’application. Au fur
et à mesure que l’application s’exécute, le code injecté sauvegarde dans
l’objet backup l’état de l’exécution (les appels de méthodes, les valeurs des
variables locales des méthodes). Lorsque l’application désire capturer son
état, il lui suffit d’utiliser l’objet backup que le préprocesseur lui a associé.
Pour restaurer l’état d’une application, les informations sauvegardées dans
l’objet backup sont utilisées pour réinitialiser l’état de l’application : une
réexécution partielle de l’application est effectuée pour reconstruire la pile
d’exécution et réinitialiser les valeurs des variables locales. La principale
motivation de cette approche est qu’elle ne modifie pas la JVM. Mais son
inconvénient est que d’une part, elle induit un surcoût non négligeable sur les
performances de l’application (dû au code injecté par le préprocesseur)
[BOU 00b] et que d’autre part, le coût de l’opération de restauration de l’état
est important en raison de la réexécution partielle de l’application.
Fünfrocken propose une plate-forme à agents mobiles se basant sur un
préprocesseur qui instrumente le code source des applications Java [FUN 98]
et Truyen, ou encore Sakamoto proposent des implantations de mécanismes
de capture d’état de flots de contrôle Java basés sur un préprocesseur qui
instrumente le code intermédiaire de l’application [SAK 00, TRU 00] ;