De nombreux langages permettant l’interaction entre agents existent d´ej`a depuis une dizaine d’ann´ees. L’association internationale FIPA (Foundation for Intelligent Physical Agents) tente actuellement de d´efinir une normalisa-tion, appel´ee ACL (Agent Communication Language). Cependant, de nos jours, des propositions de nouveaux langages utilisant diff´erentes approches continuent `a apparaˆıtre. Cet ensemble de langages a augment´e beau-coup avec l’arriv´ee du langage Java parce que Java offre la facilit´e de cr´eer des objets et les faire migrer en utilisant RMI. Parmi les SAMs bas´es sur Java, on peut citer, entre autres : Concordia[WEB Concordia], Aglets
[WEB Aglets]et Voyager[WEB Voyager].
Une des approches qui a montr´e sa puissance dans plusieurs domaines est l’approche r´eactive. Cette approche fournit un ensemble de primitives qui permettent la construction de syst`emes, comme l’interaction entre des
agents qui r´eagissent `a des ´ev´enements. L’approche r´eactive offre un bon moyen pour cr´eer des agents ; cepen-dant, les langages r´eactifs existant (Esterel, Signal, Lustre, etc.) ne permettent pas la migration de code. De plus, on a besoin d’un langage qui propose des fonctions sp´ecifiques pour la manipulation des agents.
Le premier essai pour construire un SAM dans le cadre r´eactif a ´et´e RAMA [NIK 99]. Cependant la pro-grammation en RAMA est de bas niveau par rapport aux besoins li´es `a la pr´esence d’agents. Le r´esultat est une programmation difficile qui ne cache pas les d´etails de l’impl´ementation de la plate-forme et qui laisse la responsabilit´e de l’affectation des noms d’agents au programmeur, ce qui peut g´en´erer divers probl`emes, par exemple de s´ecurit´e.
Rejo est un nouveau langage r´eactif, plus pr´ecis´ement une extension `a Java pour cr´eer des Objets Java R´eactifs (REactive Java Objets). On propose d’utiliser Rejo pour construire des agents mobiles r´eactifs. Les objets r´eactifs peuvent ainsi migrer de fa¸con naturelle dans le cadre r´eactif et les fonctions n´ecessaires typiques d’Agent Mobile (comme l’affectation d’un nom) sont fournis par une plate-forme appel´ee ROS, d´ecrite dans ce chapitre. Cette plate-forme ex´ecute les objets et fournit les op´erations typiques d’un SAM. La figure7.1montre la position de Rejo parmi les diverses approches utilis´ees.
SyncChart Argos Esterel Signal Lustre Aglets Voyager Concordia SugarCubes Junior Jester Approche Reactive Synchrone Approche synchrone Agents Mobiles Java REJO Messengers
Fig. 7.1: Situation de Rejo par rapport aux objectifs
De mˆeme que les langages d’agents, les SAM[FUG 98]ont ´evolu´e vers des syst`emes de plus en plus complexes. Parmi les caract´eristiques que poss`edent les SAM, on peut identifier un ensemble basique de propri´et´es com-munes : mobilit´e, nommage, communication (pour la collaboration), s´ecurit´e. Il existe une analogie forte avec les Syst`emes d’Exploitation R´epartis (SER)[TAN 95]. Un SER contient un administrateur de processus et un administrateur de processeurs pour diriger la migration des processus. La migration des processus peut ˆetre utilis´ee pour ´equilibrer la charge du syst`eme. De mˆeme, dans un SAM, un agent est un processus ayant la propri´et´e de migration et la migration peut ˆetre utilis´ee pour ´equilibrer la charge du syst`eme (et ´eventuellement celle du r´eseau).
Le syst`eme RAMA a montr´e que l’approche r´eactive est bien adapt´ee `a la construction des SAM. Cependant, l’architecture de RAMA ne permet pas d’ajouter facilement de nouvelles fonctionnalit´es. La principale raison est que son dessin est monolithique : il m´elange l’interface graphique de l’utilisateur et la notion de groupe avec les composants r´eactifs.
Puisqu’un SAM est tr`es proche d’un syst`eme d’exploitation, on a construit un syst`eme, ROS, bas´e sur le mod`ele actuel des SERs, c’est-`a-dire, utilisant un micro-kernel . Le micro-kernel impl´emente les fonctions basiques dont les agents ont besoin et permet d’ajouter des nouveaux modules pour augmenter sa fonctionnalit´e. Si on a besoin d’un petit kernel (rapide et qui utilise peu de m´emoire), on peut enlever certains modules.
ROS est un syst`eme qui permet l’ex´ecution des instructions r´eactives et en particulier l’ex´ecution des objets Rejo. L’architecture de ROS est similaire `a celle d’un SER et il a ´et´e impl´ement´e avec Junior.
On va maintenant pr´esenter un des probl`emes principaux qui existent en Java pour impl´ementer la migration. Ce probl`eme est qu’en Java on peut pas migrer les threads ; ceci veut dire que, lorsqu’on migre un agent, il migre sans son ´etat d’ex´ecution (migration faible). Plusieurs propositions d´ecrites dans la suite ont ´et´e faites pour pouvoir ´egalement migrer l’´etat ; dans la sous-section7.3.2, on pr´esente la migration de nos agents. La migration en Java
Il existe principalement trois approches pour aborder le probl`eme de capture et de restauration de l’´etat des flots Java : une approche dite explicite, une approche dite implicite se basant sur un pre-processeur de code et une approche implicite qui ´etend la JVM.
La premi`ere approche, appel´ee gestion explicite, consiste `a laisser enti`erement `a la charge du programmeur de l’application la gestion de la capture et de la reconstruction de l’´etat de son application. Le programmeur doit donc ajouter du code qui effectue le travail, en des points pr´ecis de l’application dits points de sauvegarde. En un point de sauvegarde, le code ajout´e doit enregistrer l’´etat de l’ex´ecution : il note la derni`ere instruction ex´ecut´ee ainsi que l’´etat courant de l’application. Lors de la reprise de l’ex´ecution, le premier traitement effectu´e est un branchement vers le dernier point de sauvegarde enregistr´e ; ainsi, l’ex´ecution peut reprendre au point o`u elle a ´
et´e interrompue. Cette solution manque de souplesse car la gestion des points de sauvegarde est enti`erement `a la charge du programmeur. De plus, l’ajout ou la modification de points de sauvegarde induit une modification de l’application elle-mˆeme. Cette gestion explicite est utilis´ee dans les applications faisant appel `a des plates-formes `a agents mobiles [CHE 95] fournissant une migration faible tels que les Aglets [WEB Aglets]ou Mole
[WEB Mole].
Les deux autres approches, dites implicites, fournissent un service de capture/restauration de l’´etat des flots de contrˆole. Le service fourni est ind´ependant du code de l’application et se pr´esente sous la forme d’une primitive appel´ee par l’application elle-mˆeme ou par une application externe. Ces deux approches diff`erent par leur mise en oeuvre :
1. La premi`ere approche implicite consiste `a fournir un pr´e-processeur qui injecte du code dans le code de l’application Java, soit dans le code source, soit dans le code interm´ediaire Java. Lors de l’ex´ecution de l’application, le code inject´e cr´ee un objet Java, que l’on nommera backup, et l’associe `a l’application. Au fur et `a mesure que l’application s’ex´ecute, le code inject´e sauvegarde dans l’objet backup l’´etat de l’ex´ecution (les appels de m´ethodes et les valeurs des variables locales des m´ethodes). Lorsque l’application d´esire capturer son ´etat, il lui suffit d’utiliser l’objet backup que le pre-processeur lui a associ´e. Pour restaurer l’´etat d’une application, les informations sauvegard´ees dans l’objet backup sont utilis´ees pour re-initialiser l’´etat de l’application : une re-ex´ecution partielle de l’application est effectu´ee pour reconstruire la pile d’ex´ecution et re-initialiser les valeurs des variables locales. Le principal int´erˆet de cette approche est qu’elle ne modifie pas la JVM. Mais son inconv´enient est que, d’une part, elle induit un sur-coˆut non n´egligeable des performances de l’application (du au code inject´e par le pr´e-processeur) [BOU 00c]
et que, d’autre part, le coˆut de l’op´eration de restauration de l’´etat est important `a cause de la re-ex´ecution partielle de l’application. [FUN 98] propose une plate-forme `a agents mobiles se basant sur un pr´e-processeur qui instrumente le code source des applications Java et [TRU 00]ou encore[SAK 00]
proposent des implantations de m´ecanismes de capture d’´etat de flots de contrˆole Java bas´es sur un pr´e-processeur qui instrumente le code interm´ediaire de l’application.
2. La seconde approche implicite consiste `a ´etendre la machine virtuelle Java pour en extraire l’´etat des flots et le rendre accessible par les programmes Java. Cette extension doit permettre de capturer l’´etat courant d’un flot et de le stocker dans un objet Java. L’extension doit ´egalement permettre de cr´eer un nouveau flot et de l’initialiser avec un ´etat pr´ealablement captur´e. Un service de capture/restauration construit en suivant cette approche n’est certes utilisable que sur des machines virtuelles ´etendues. Nous avons tout de mˆeme choisi cette approche pour les deux raisons suivantes :
(a) Elle r´eduit le sur-coˆut induit par le service sur les performances de l’application (pas de code inject´e) et elle r´eduit le coˆut du service de capture/restauration car sa mise en oeuvre dans la machine virtuelle Java est principalement native (en C).
(b) Du fait que ce service poss`ede plusieurs domaines d’applications, nous pensons que c’est un service de base que doit ˆetre int´egr´e `a la JVM.
Le m´ecanisme de migration que l’on va utiliser appartient, en quelque sorte, aux deux classifications ; il est du premier type car on ins`ere du code (les instructions Stops) pour sauver l’´etat de l’agent. Le code est ins´er´e par le programmeur et non par un pre-processeur mais le m´ecanisme est ´egalement du deuxi`eme type car il n´ecessite une machine virtuelle sp´eciale (la machine r´eactive de Junior) pour ex´ecuter le code et effectuer la capture de l’´etat (avec freezable qui place la copie dans la machine) et sa restauration (add dans la machine).
Pour plus d’information sur les m´ecanismes de migration de threads en Java, le lecteur peut lire[TRU 00].