La plate-forme JADE

Auteur FERGUEN Adel

Le meilleur moyen pour construire un système multi-agent(SMA) est d'utiliser une plate-forme multi-agent. Une plate-forme multi-agent est un ensemble d'outils nécessaire à la construction et à la mise en service d'agents au sein d'un environnement spécifique. Ces outils peuvent servir également à l'analyse et au test du SMA ainsi créé. Ces outils peuvent être sous la forme d'environnement de programmation (API) et d'applications permettant d'aider le développeur. Nous allons étudier dans cette partie la plate-forme JADE(Java Agent DEvelopment framework).

JADE (Java Agent DEvelopement framework) est une plate-forme multi-agent créé par le laboratoire TILAB [TILAB] et décrite par Bellifemine et al. Dans [BEL 99][BEL 00]. JADE permet le développement de systèmes multi-agents et d'applications conformes aux normes FIPA [FIPA 00][FIPA 02]. Elle est implémentée en JAVA et fourni des classes qui implémentent « JESS » pour la définition du comportement des agents. JADE possède trois modules principaux (nécessaire aux normes FIPA).

• DF « Director Facilitor » fournit un service de « pages jaunes» à la plate-forme ;
• ACC «Agent Communication Channel » gère la communication entre les agents ;
• AMS « Agent Management System » supervise l'enregistrement des agents, leur authentification, leur accès et l'utilisation du système.

Ces trois modules sont activés à chaque démarrage de la plate-forme.

La FIPA (Foundation for Intelligent Physical Agents) est une organisation à but non lucratif fondée en 1996 dont l'objectif est de produire des standards pour l'interopération d'agents logiciels hétérogènes. Par la combinaison d'actes de langages, de logique des prédicats et d'ontologies publiques, la FIPA cherche à offrir des moyens standardisés permettant d'interpréter les communications entre agents de manière à respecter leur sens initial, ce qui est bien plus ambitieux que XML, qui ne standardise que la structure syntaxique des documents. Afin d'atteindre ce but, le FIPA émet des standards couvrant :

• Les applications (applications nomades, agent de voyage personnel, applications de diffusion audiovisuelles, gestion de réseaux, assistant personnel…) ;
• Les architectures abstraites, définissant d'une manière générale les architectures d'agents ;
• Les langages d'interaction (ACL), les langages de contenu (comme SL, CCL, KIF ou RDF) et les protocoles d'interaction ;
• La gestion des agents (nommage, cycle de vie, description, mobilité, configuration);
• Le transport des messages : représentation (textuelle, binaire ou XML) des messages ACL, transport (par IIOP, WAP ou HTTP) de ces messages.

Ces standards évoluent, et sont régulièrement mis à jour, ainsi que de nouveaux standards qui sont nouvellement proposés. Les standards qu'édicte la FIPA ne constituent pas vraiment une plate-forme de construction multi-agents. Ce n'est pas non plus l'objectif que s'est fixé la FIPA. Tout au plus, la FIPA normalise une plate-forme d'exécution standardisée dans un but d'interopérabilité. Ces normes s'appliquent donc pour la plupart en phase de déploiement. Elles n'abordent pas les phases d'analyse ni de conception. Elles peuvent cependant guider certains choix d'implémentation.

JADE reprend donc l'architecture de l'Agent Management Reference Model proposé par FIPA. Les différents modules présentés dans la figure suivante sont présentés sous forme de services. Les services de base proposés sont le Directory Facilitator (DF) et l'Agent Management System (AMS). Il est possible de lui demander de tenir en plus le service de Message Transport Service (MTS) pour communiquer entre plusieurs plates-formes. Mais ce service sera chargé à la demande pour ne conserver par défaut que les fonctionnalités utiles à tout type d'utilisation.
L'agent est l'acteur fondamental de la plate-forme, un Agent Identifier (AID) identifie un agent de manière unique. Le DF est un composant qui fait office d'annuaire. C'est un service de « pages jaunes » qui permet de mettre en relation les agents avec leurs compétences. Un agent peut enregistrer ses compétences dans le DF ou interroger le DF pour connaître les compétences proposées par les autres agents. L'AMS est un autre composant important car il contrôle l'accès et l'utilisation de la plate-forme et maintient un répertoire contenant les adresses de transport des agents de la plate forme. Ce service est plus un service de type « pages blanches » qui effectue la correspondance entre l'agent et l'AID.
Chaque agent doit s'enregistrer à un AMS pour avoir un AID. Il n'y a qu'un AMS par plate-forme. Le MTS est une méthode par défaut de communication entre agents de différentes plates-formes. Cela permet l'interconnexion entre systèmes hétérogènes ou tout au moins de système ne communicant pas de la même façon. L'Agent Platform (AP) constitue l'infrastructure physique sur laquelle se déploient les agents. Il contient le DF, l'AMS et le MTS. Lorsqu'on parle de AP, on inclut souvent le matériel électronique, l'OS, le software et les composants cités ci-dessus avec les agents. Enfin, l'Agent Identifier (AID) est un identifiant précis d'un agent. On lui donne plusieurs paramètres tels que l'adresse de transport, l'adresse de service de résolution de nom, … Un exemple est : name@HAP (Home Agent Platform)

Figure 1 : Architecture logiciel de La plate-forme JADE

Dans la plate-forme JADE, deux méthodes sont fournies par la classe Agent afin d'obtenir l'identifiant de l'agent DF par défaut et celui de l'agent AMS : getDefaultDF() et respectivement getAMS(). Ces deux agents permettent de maintenir une liste des services et des adresses de tous les autres agents de la plate-forme. Le service DF propose quatre méthodes afin de pouvoir :

• Enregistrer un agent dans les pages jaunes (register).
• Supprimer un agent des pages jaunes (deregister).
• Modifier le nom d'un service fourni par un agent (modify).
• Rechercher un service (search).

Le service AMS s'utilise généralement de manière transparente (chaque agent créé est automatiquement enregistré auprès de l'AMS et se voit attribué une adresse unique). Ces deux services fournissent donc les annuaires qui permettent à n'importe quel agent de trouver un service ou un autre agent de la plate-forme.

Le langage de Communication de la plate-forme JADE est FIPA-ACL(Agent Communication language). La classe ACLMessage représente les messages qui peuvent être échangés par les agents. La communication de messages se fait en mode asynchrone. Lorsqu'un agent souhaite envoyer un message, il doit créer un nouvel objet ACLMessage, compléter ces champs avec des valeurs appropriées et enfin appeler la méthode send(). Lorsqu'un agent souhaite recevoir un message, il doit employer la méthode receive() ou la méthode blockingReceive().
Un message ACL dispose obligatoirement des champs suivants :

Tous les attributs de la classe ACLMessage peuvent être obtenus et modifiés par les méthodes set/get(). Le contenu des messages peut être aussi bien du texte que des objets car la sérialisation Java est supportée.

Dans le protocole FIPA-request, un agent sollicite un autre agent pour exécuter des actions et l'agent récepteur retourne soit une réponse favorable à l'exécution d'actions, soit une réponse défavorable expliquée par telle ou telle raison.
Supposons que l'agent i aie besoin de l'agent j pour exécuter l'action « action ».

1. L'agent i envoie « request » à l'agent j. Si l'agent j accepte la requête, il retourne « agree ». Ensuite, quand j a fini d'exécuter « action », il en informe i en utilisant « inform ».
2. Si l'agent j accepte mais rencontre un problème durant le traitement de « action », il retourne « failure » et les raisons de l'échec.
3. Si l'agent j n'accepte pas la requête de l'agent i, j retourne « refuse » et les raisons de ce refus.

Le protocole FIPA-Query signifie que l'agent émetteur sollicite l'agent récepteur pour exécuter un des types d'un performatif « inform », c'est-à-dire pour répondre à la demande.
Supposons que l'agent i fasse une demande à l'agent j.

1. L'agent i envoie un performatif « query » à l'agent j. Si l'agent j peut répondre à la demande, il l'informe en utilisant le performatif « inform ».
2. Si l'agent j a essayé de répondre à la demande mais qu'il ne le peut pas, il retourne « failure » et les raisons de cette impossibilité.
3. Si l'agent j refuse de répondre à la demande, il retourne « refuse » et les raisons de ce refus.

Le Protocole Contract-Net (CNP) a été défini par Smith [SMI 80]. Il est un mécanisme de négociation par appel d'offre (ou Contract) entre deux types d'agents : l'agent gestionnaire et les agents contractants. L'agent gestionnaire, souhaitant sous-traiter une tâche qu'il doit accomplir, est l'initiateur du contrat. Chaque agent contractant est un agent auquel on propose ce contrat. Le fonctionnement du CNP à été décrit dans [SCD 92]. Ce protocole très souvent utilisé, a été normalisé par l'organisation FIPA et implémenté dans la plate-forme JADE.

- Initiateur Contract-Net

La classe ContractNetInitiator (abstraite) implémente le protocole FIPA ContractNet du point de vue de l'agent qui initialise le protocole ie. L'agent qui envoie un message CFP (Call For Proposal).

Le comportement d'initiateur doit également prendre en compte les délais d'attente pour les réponses. Le temps limite est spécifié dans le champ reply-by du message ACL passé au constructeur de cette classe. Si rien n'est spécifié alors une attente infinie est utilisée par défaut. Toutes réponses arrivées hors délais ne sont pas consommées et reste dans la file d'attente des messages de l'agent.

Cette classe propose également un jeu de méthodes destinées à superviser chaque étape du protocole. Elles sont appelées lorsque des messages particuliers sont reçus ou sont à envoyer et doivent être surchargées afin d'adapter le protocole à son contexte d'utilisation :

• La méthode prepareCfps() est la première invoquée. C'est l'appel d'offre ou proposition (message CFP).
• La méthode handlePropose() est appelée dés que le message PROPOSE a été reçu (ie. l'offrant fait une proposition). Elle prépare les messages d'acceptation ou de refus correspondant (message ACCEPT-PROPOSAL ou REJECT-PROPOSAL).
• La méthode handleRefuse() est appelée dés que le message REFUSE a été reçu (ie. l'offrant refuse toute proposition).
• La méthode handleNotUnderstood() est appelée dés que le message NOT-UNDERSTOOD a été reçu (ie. l'offrant ne comprend pas la proposition).
• La méthode handleInform() est appelée dés que le message INFORM a été reçu .(ie. l'offrant confirme que sa proposition a bien été acceptée par l'initiateur).
• La méthode handleFailure() est appelée dés que le message FAILURE a été reçu (ie. l'offrant ne peut satisfaire la demande de l'initiateur pour une raison quelconque).
• La méthode handleOutOfSequence() est appelée si un message hors séquence (ie. avec un mauvais conversation-id) et respectant le protocole ContractNet est reçu.

Afin de pouvoir être en interaction avec plusieurs offrants, deux méthodes supplémentaires sont disponibles afin de collecter les messages par volé : handleAllResponse() et handleAllResultNotifications qui permettent respectivement de récupérer la première série de réponses (ie. NOT-UNDERSTOOD, REFUSE, PROPOSE) et la seconde (ie. FAILURE, INFORM).

Enfin, la classe ContractNetInitiator dispose d'une alternative aux méthodes décrites ci-dessus : il est possible de les remplacer par des comportements génériques correspondants.
Les méthodes registerPrepareCfps(), registerHandlePropose(), registerHandleAllResponses(), registerHandleAllResultNotifications(), permettent de spécifier ces comportements et d'écraser les méthodes qu'ils remplacent.

Dans ce cas le DataStore de la classe doit être utilisé comme mémoire partagée afin d'échanger les messages entre les différents comportements. JADE fournit un jeu de constantes, identifiables par le suffixe KEY, qui représente les clefs pour accéder au DataStore et retrouver tous messages envoyés ou reçus.

- Offrant ContractNet

La classe ContractNetResponder (abstraite) implémente le protocole FIPA ContractNet du point de vue d'un agent qui répond au message CFP (ie. l'offrant). Il est important de passer le bon modèle de message au constructeur de cette classe car il est utilisé afin de séparer les messages ACL du protocole des autres messages reçus par l'agent. La méthode createMessageTemplate peut être utilisée à ces fins.

Tout comme la classe ContractNetInitiator, cette classe peut être facilement étendue en surchargeant une ou plusieures de ses méthodes prepare() afin de l'adapter à son contexte d'utilisation. Ces méthodes permettent de superviser les étapes du protocole et en particulier de préparer les messages à renvoyer à l'agent initiateur :

• La méthode prepareResponse est invoquée dès que l'appel d'offre de l'initiateur a été reçu. Cette méthode prépare le message de proposition PROPOSE (pour répondre au message CFP). Elle permet aussi de préparer un message REFUSE (refus de toute négociation) ou un message NOT-UNDERSTOOD en cas d'incompréhension de la demande de l'initiateur.
• La méthode handleRejectProposal() est appelée si un message de rejet d'offre est reçu.
• La méthode prepareResultNotification() est appelée dés que le message ACCEPT_PROPOSAL a été reçu (ie. l'initiateur a accepté la proposition). Elle prépare le message de confirmation correspondant (message INFORM) ou en cas de problème un message FAILURE signalant l'échec de la négociation.
• La méthode handleOutOfSequence() est appelée si un message hors séquence (ie. avec un mauvais conversation-id) et respectant le protocole Contract-Net est reçu.

Les attributs des messages ACL retournés par ces différentes méthodes doivent être correctement sélectionnés. L'utilisation de la méthode createReply() est donc incontournable pour préparer les réponses. Elle permet entre autre de mettre la valeur appropriée dans le champ in-reply-to du message ACL. Ce champ est important car il contient le conversation-id qui est en fait un identificateur commun pour une série de messages échangés entre deux agents. Ceci permet à tout agent de maintenir plusieurs conversations sans se tromper dans les différents messages à envoyer.

Tout comme la clase ContractNetInitiator il est possible de remplacer les méthodes prepare() de la classe par des comportements spécifiques.
Les méthodes suivantes nommées registerHandleRejectProposal(), registerPrepareResponse(), registerPrepareResultNotification() et registerHandleOutOfSequnece() permettent cette opération. Le Datastore de la classe aura dans ce cas la même fonction que celui de la classe ContractNetInitiator.
L'API fournie par la plate-forme pour le protocole ContractNet est donc très complète et générique. Les opérations qui sont à la charge du programmeur reste la surcharge des différentes méthodes afin de les adapter au contexte d'utilisation du protocole et éventuellement la définition de comportement(s) visant à remplacer certaine(s) méthode(s).

Un agent doit être capable de gérer plusieurs tâches de manière concurrente en réponse à différents évènements extérieurs. Afin de rendre efficace cette gestion chaque agent de JADE est composé d'un seul thread et chaque comportement qui le compose est en fait un objet de type Behaviour. Des agents multi-thread peuvent être créés mais il n'existe pour l'heure actuelle aucun support fournis par la plate-forme (excepté la synchronisation de la file des messages ACL).
Afin d'implémenter un comportement, le développeur doit définir un ou plusieurs objets de la classe Behaviour, les instancier et les ajouter à la file des tâches « ready »de l'agent. Il est à noter qu'il est possible d'ajouter des comportements et sous-comportements à un agent ailleurs que dans la méthode setup().
Tout objet de type Behaviour dispose d'une méthode action() (qui constitue le traitement à effectuer par celui-ci) ainsi que d'une méthode done() (qui vérifie si le traitement est terminé). Dans les détails, l'ordonnanceur exécute la méthode action() de chaque objet Behaviour présent dans la file des tâches de l'agent. Une fois cette méthode terminée, la méthode done() est invoquée. Si la tâche a été complétée alors l'objet Behaviour est retiré de la file. L'ordonnanceur est non-préemptif et n'exécute qu'un seul comportement à la fois, on peut donc considérer la méthode action() comme étant atomique. Il est alors nécessaire de prendre certaines précautions lors de l'implémentation de cette dernière, à savoir éviter des boucles infinies ou des opérations trop longues. La façon la plus classique de programmer un comportement consiste à le décrire comme une machine à états finis. L'état courant de l'agent étant conservé dans des variables locales.
Enfin, il existe également quelques méthodes supplémentaires afin de gérer les objets Behaviour :

• reset() qui permet de réinitialiser le comportement;
• onStart() qui défini des opérations à effectuer avant d'exécuter la méthode action();
• onEnd() qui finalise l'exécution de l'objet Behaviour avant qu'il ne soit retiré de la liste des comportements de l'agent;

La plate-forme JADE fournit sous forme de classes un ensemble de comportements ainsi que des sous-comportements prêt à l'emploi. Elle peut les exécuter selon un schéma prédéfini, par exemple la classe SequentialBehaviour est supportée et exécute des sous-comportements de manière séquentielle. Toutes les classes prédéfinies dans JADE hérite de la classe Abstraite Behaviour. On peut les citer :

• Classe SimpleBehaviour (abstraite): modélise un comportement simple. Sa méthode reset() n'effectue aucune opération.
• Classe CompositeBehaviour (abstraite) : modélise un comportement composé. Les actions effectuées par cette classe sont définies dans les comportements enfants.
• Classe FSMBehaviour : Cette classe hérite de CompositeBehaviour et éxecute des comportements enfants suivant un automate à états finis défini par l'utilisateur. Lorsqu'un comportement enfant termine, sa valeur de fin retournée par la fonction onEnd() indique le prochain état à atteindre. Le comportement correspondant à cet état sera exécuté à la prochaine exécution de la classe. Elle se termine lorsque qu'un comportement associé à un état final à été exécuté.
• Classe SenderBehaviour : elle étend la classe OneShotBehaviour et encapsule une unité atomique qui effectue une opération d'envoie de message.
• Classe ReceiverBehaviour : Elle encapsule une unité atomique qui effectue une opération de reception de message. Ce comportement s'arrête dés qu'un message a été reçu. S'il n'y a pas de message dans la file d'attente de l'agent ou que le message ne correspond pas au MessageTemplate du constructeur de cette classe, alors il se met en attente.
• On peut aussi citer d'autres classes par exemples : Classe WakerBehaviour (abstraite), ParrallelBehaviour, SequentialBehaviour, CyclicBehaviour. (abstraite), OneShotBehaviour (abstraite).

Pour supporter la tâche difficile du débogage des applications multi-agents, des outils ont été développés dans la plate-forme JADE. Chaque outil est empaqueté comme un agent, obéissant aux mêmes règles, aux mêmes possibilités de communication et aux mêmes cycles de vie d'un agent générique (agentification de service).

Le RMA permet de contrôler le cycle de vie de la plate-forme et tous les agents la composant. L'architecture répartie de JADE permet le contrôle à distance d'une autre plate-forme. Plusieurs RMA peuvent être lancés sur la même plate-forme du moment qu'ils ont des noms distincts.

Figure 2 : L'interface de l'agent RMA

L'outil DummyAgent permet aux utilisateurs d'interagir avec les agents JADE d'une façon particulière. L'interface permet la composition et l'envoi de messages ACL et maintient une liste de messages ACL envoyés et reçus. Cette liste peut être examinée par l'utilisateur et chaque message peut être vu en détail ou même édité. Plus encore, le message peut être sauvegardé sur le disque et renvoyé plus tard.

Figure 3 : L'interface de l'agent Dammy

L'interface du DF peut être lancée à partir du menu du RMA .Cette action est en fait implantée par l'envoi d'un message ACL au DF lui demandant de charger son interface graphique. L'interface peut être juste vue sur l'hôte où la plate-forme est exécutée. En utilisant cette interface, l'utilisateur peut interagir avec le DF.

Figure 4 : L'interface de l'agent DF

Quand un utilisateur décide d'épier un agent ou un groupe d'agents, il utilise un agent sniffer. Chaque message partant ou allant vers ce groupe est capté et affiché sur l'interface du sniffer. L'utilisateur peut voir et enregistrer tous les messages, pour éventuellement les analyser plus tard. L'agent peut être lancé du menu du RMA ou de la ligne de commande suivante : Java jade.Boot sniffer:jade.tools.sniffer.sniffer

Figure 5 : L'interface de l'agent Sniffer

Cet agent permet de gérer et de contrôler le cycle de vie d'un agent s'exécutant et la file de ses messages envoyés et reçus.

Figure 6 : L'interface de l'agent Inspector

[BEL 00] Bellifemine F., Giovani C., Tiziana T. Rimassa G., "Jade Programmer's Guide" Jade version 2.6 (http://sharon.cselt.it/projects/jade/), 2000.
[BEL 99] Bellifemine F., Poggi A., Rimassa G., "JADE -- A FIPA-compliant agent framework", CSELT internal technical report. Part of this report has been also published in Proceedings of PAAM'99, London, pp.97-108, April 1999.
[JADE 02] JADE P.G., Bellifemine F., Caire G., Trucco T., Rimassa G., "JADE : Programmer's Guide", Février 2002.
[JADE 00] Java Agent DEvelopment framework. 2000. (http://sharon.cselt.it/projects/jade/)
[RIM 00] Rimassa G., Bellifemine F., Poggi A., "JADE - A FIPA Compliant Agent Framework", PMAA`99, p. 97-108, Londres, Avril 1999.
[SCD 92] Sassi M, Chaib-draa B., "Stratégie de négociation entre agents dans le domaine du transport". Internal raport, Département d'informatique, faculté des sciences et de Génie, Université de Laval, Canada, 1992. [SMI 80] Smith R.G., Davis R., "Framework for cooperation in distributed problem solving". IEEE Transactions on System, Man and Cybernetics, SMC, Vol. 11 No.161-70. 1980. http://www.telecomitalialab.com/
http://www.fipa.org/specs/fipa00001/
http://www.fipa.org/specs/fipa00023/
http://www.fipa.org/specs/fipa00037/
http://www.fipa.org/specs/fipa00008/
http://www.fipa.org/specs/fipa00067/
http://www.telecomitalialab.com/