| Précédent DIMA | Haut Introduction | Suivant MadKit |
JADE
(Développement et Implémentation de systèmes Multi-Agents)
Systèmes Multi-Agents
Professeur : J-P.Sansonnet
Etudiant : Lotfi RAMDANI
1.FIPA (Fondation for Intellegent Physical Agents)
2.1 L'architecture de la plate-forme
2.4.1Conformité à la norme FIPA
JADE est une plate-forme multi-agents développée en entier en JAVA, par F. Bellifemine & A. Poggy, G. Rimassa, P. Turci pour la société CSELT (Italie) en 1999, qui a comme but de faciliter le développement des applications agent conforment à la nome FIPA97 (Fondation for Intellegent Physical Agents) pour les systèmes multi-agents inter opérable. JADE essayer d’optimiser les performances d’un système d’agent distribué.
1.
FIPA (Fondation for Intellegent Physical Agents)
FIPA est une association internationale sans but lucratif, travaillant pour produire des spécifications pour des technologies d’agent générique.
Le premier document de la FIPA, et le FIPA97, établissant les règles normatives qui permettent à une société d’agents d’inter opérer. Les documents FIPA décrivent le modèle de référence d’une plate-forme multi-agents ou il identifient les rôles de quelques agents clés nécessaires pour la gestion de la plateforme, et spécifient le contenu du langage de gestion des agent et l’ontologie du langage. Trois rôles (agent) principaux sont identifiés dans une plate-forme d’agent :
1. Le Système de gestion d’Agent (AMS- Agent Management System)
Agent qui exerce le contrôle de supervision sur l’accès et l’usage de la plateforme ; il est responsable d’authentifier les agents résidents et de contrôler la les enregistrements.
2. Le Canal De communication (ACC- Agent Communication Canal)
Agent qui fournit le chemin pour les interactions de base entre les agents dans et en d’hors de la plateforme ; c’est la méthode de communication implicite qui offre un service fiable et précis pour le routage des messages ; il (l’agent) doit aussi être compatible avec le protocole IIOP () pour assurer l’interopérabilité entre les différentes plateformes.
3. Le faciliteur d’Annuaire (DF- Directory Facilitor)
Agent qui fournit un service de pages jaunes à la plateforme.
FIPA spécifie aussi le Langage de Communication d’agents (ACL- Agent Communication Language). La communication entre agents ne se fait que par envoi de messages seulement.
FIPA ACL est le langage standard des messages et impose le codage, la sémantique et la pragmatique des messages. La norme n’impose pas de mécanisme spécifique pour le transport interne de messages. Plutôt, puisque les agents pourraient s’exécuter sur des plateformes différents et utilisent des technologies différentes ‘interconnexion, FIPA spécifie que les messages transportés entre les différentes plateforme devrait être codé sous forme textuelle.
· La plate-forme multi-agents compatible FIPA, qui inclut le AMS, DF, ACC – voir ci dessus. Ces trois agents sont automatiquement créés et activés à l’activation de la plate-forme.
· La plate-forme d'agents distribuée. La plate-forme d'agents peut être distribuée sur plusieurs machines, à condition qu'il n'y ait pas de pare-feu entre ces machines. Une seule application Java (Machine Virtuelle Java) est exécutée sur chaque machine. Les agents sont implémentés comme des threads d'exécution Java et les événements Java sont utilisés pour la communication efficace et légère entre agents sur une même machine. Un agent peut exécuter des tâches parallèles et JADE planifie ces tâches d'une manière plus efficace (et même plus simple pour le programmeur) que la planification faite par la Machine Virtuelle Java pour les threads d'exécution.
· Un certain nombre de DF (Facilitateurs d'Annuaire) compatibles FIPA peuvent être activés quand on lance la plate-forme pour exécuter les applications multi-domaines, ou le domaine est logique comme décrit dans FIPA97 Part1.
· Une interface de programmation pour simplifier l'enregistrement de services d'agents avec un ou plusieurs domaines (exemple : DF).
· Un mécanisme de transport et une interface pour l'envoi et la réception des messages de et vers les autres agents.
· Le protocole IIOP compatible avec le document FIPA97 pour connecter les différentes plates-formes multi-agents.
· Le transport léger de messages ACL sur la même plate-forme d'agents. Dans le but de simplifier la transmission, les messages internes (sur la même plate-forme) sont transférés et codés comme des objets Java et non comme des chaînes de caractères. Quand l'expéditeur ou le récepteur n'appartient pas à la même plate-forme, le message est automatiquement converti en chaîne de caractères spécifiés par la FIPA. De cette façon, la conversion est cachée au programmeur d'agents, qui a seulement besoin de traiter la classe d'objets Java.
· Une bibliothèque de protocoles d'interaction compatibles FIPA.
· L'enregistrement automatique d'agents dans le Système de Gestion d'Agents (AMS).
· Un service d'attribution de noms compatible FIPA ; quand on lance la plate-forme, un agent obtient un identificateur unique (Globally Unique Identifier - GUID).
· Une interface graphique utilisateur pour gérer plusieurs agents et plates-formes multi-agents en partant d'un agent unique. L'activité de chaque plate-forme peut être supervisée et enregistrée.
2.1
L'architecture de la plate-forme
La plateforme JADA est conforme aux spécifications FIPA97, et inclus tous les agents rôles qui constituent la plateforme, c’est le ACC,AMS et le DF, tous les communications entre agents est faite par l’envoi de message, ou le FIPA ACL est le langage utiliser pour écrire ces messages.
L'architecture du logiciel est basée sur la coexistence de plusieurs Machines Virtuelles (VM) Java et la communication se fait par la méthode RMI (Remote Method Invocation) de Java entre machines virtuelles (VMs) différentes. Chaque VM est un réceptacle d'agents qui fournit un environnement d'exécution complet pour l'exécution des agents et permet d'avoir plusieurs agents qui s'exécutent simultanément sur un même hôte. En principe, l'architecture permet aussi à plusieurs VMs d'être exécutées sur le même hôte ; cependant, ceci n'est pas à encourager, car on crée ainsi un surcroît de travail au système qui n'apporte aucun bénéfice. Chaque réceptacle d'agents est un environnement multi-threads d'exécution composé d'un thread d'exécution pour chaque agent et, en plus, des threads créés à l'exécution par le système RMI pour envoyer des messages. Un récipient spécial joue le rôle du frontal de la plate-forme ; il contient les agents de gestion et représente la plate-forme toute entière pour le monde extérieur.
Une plate-forme multi-agents JADE est alors composée de plusieurs réceptacles (containers) d'agents. La distribution de ces réceptacles à travers un réseau d'ordinateurs est permise, à condition que la communication RMI entre leurs hôtes soit conservée. Un réceptacle léger spécial est implémenté pour l'exécution des agents dans un navigateur Web. Chaque réceptacle d'agents est un objet serveur RMI qui gère localement un ensemble d'agents. Il règle le cycle de vie des agents en les créant, les suspendant, les reprenant et les détruisant. En plus, il traite tous les aspects de la communication : répartition des messages ACL reçus, routage des messages selon le champ de destination (:receiver) et dépôt des messages dans les files de messages privées des agents. Pour les messages vers l'extérieur, le réceptacle d'agents maintient assez d'information pour chercher l'emplacement de l'agent récepteur et pour choisir une méthode de transport convenable pour expédier le message ACL.
Architecture de JADE
La plate-forme offre une interface graphique utilisateur (GUID) pour la gestion à distance qui permet de contrôler et superviser les états des agents, par exemple arrêter et remettre en marche un agent. L'interface graphique permet aussi de créer et de commencer l'exécution d'un agent sur un hôte éloigné, à condition qu'un réceptacle d'agents s'exécute déjà sur cet hôte. L'interface elle-même a été implémentée comme un agent, appelé RMA (Remote Monitoring Agent). Toute la communication entre les agents et l'interface (GUI) et toute la communication entre cette interface et l'AMS est faite par ACL via une extension ad hoc de l'ontologie des agents de gestion FIPA.
L’interface
utilisateur (GUI)
L’agent Dummy
L’agent Sniffer
On a vu qu'une propriété importante d'un agent est son autonomie : un agent ne doit pas se limiter à réagir aux événements externes, mais il doit être aussi capable de prendre l'initiative de nouveaux actes communicatifs d'une façon autonome. Ceci exige que chaque agent ait un thread interne de contrôle ; cependant, un agent peut engager des conversations simultanées multiples, tout en poursuivant d’autres activités qui n'impliquent pas d’échanges de messages.
JADE utilise l'abstraction Comportement (behavior) pour modéliser les tâches qu'un agent peut exécuter et les agents instancier leurs comportements selon leurs besoins et leurs capacités. De point de vue de la programmation concurrente, un agent est un objet actif, ayant un thread de contrôle. JADE utilise un modèle de programmation concurrente un thread par agent au lieu d'un modèle un thread par comportement pour éviter une augmentation du nombre de threads d'exécution exigés sur la plate-forme d'agents. Ceci signifie que, pendant que les différents agents s'exécutent dans un environnement multi- threads de préemption, deux comportements d'un même agent sont planifiés coopérativement.
En dehors de la préemption, les comportements travaillent tous comme des threads d'exécution coopératifs, mais il n'y a pas de pile à sauvegarder. Un planificateur (scheduler), exécuté par la classe de base Agent et caché au programmeur, exécute une politique de "round-robin" de non-préemption entre tous les comportements disponibles dans la file des processus prêts. Ainsi, il permet l'exécution d'une classe dérivée de la classe Comportement jusqu'à ce qu'elle abandonne le contrôle d'exécution par elle-même. Si la tâche qui a le contrôle n'est pas encore finie, elle sera re-planifiée pendant le prochain tour du round-robin à moins qu'elle ne soit pas bloquée ; en fait, un comportement peut se bloquer lui-même, par exemple pendant qu'il attend des messages, pour éviter le gaspillage du temps CPU réalisant ainsi un comportement d'attente occupée.
Donc, le développeur d'agents doit étendre la classe Agent et implémenter les tâches spécifiques de l'agent par une ou plusieurs classes Comportement, les instancier et les ajouter à l'agent. La classe Agent représente une super-classe commune pour tous les agents définis par l'utilisateur. Du point de vue du programmeur, la conséquence est qu'un agent JADE est simplement une classe Java qui étend la classe de base Agent. Cela permet à l'agent d'hériter un comportement fondamental caché (qui traite toutes les tâches liées à la plate-forme, telles que l'enregistrement, la configuration, la gestion à distance, etc.), et un ensemble de méthodes qui peuvent être appelées pour implémenter les tâches spécifiques à l'agent, par exemple envoi des messages, utilisation des protocoles d'interaction standard, enregistrement sur plusieurs domaines, etc. De plus, il y a encore deux méthodes qui sont héritées pour gérer la file de comportements d'agents : addBehaviour(Behaviour) et removeBehaviour(Behaviour). JADE inclut aussi quelques comportements prêts à être utilisés pour les tâches les plus communes dans la programmation des agents, tels que l'envoi et la réception des messages et la décomposition des tâches complexes en des agrégations de tâches plus simples. Entre autres, JADE offre aussi une classe JessBehaviour qui permet l'intégration avec le système expert JESS (Java Expert System Shell), où JADE fournit le noyau de l'agent et garantit (autant que possible) la conformité avec les normes FIPA, alors que JESS est le moteur d'inférence de l'agent qui exécute le raisonnement nécessaire pour la résolution du problème.
Nous allons donner dans ce qui va suive des résultat publies (par Mikko Laikanen) qui étaient le fruit d’une séries de teste sur la plateforme JADE 1.2.
2.4.1
Conformité à la norme FIPA
|
conditions accomplies |
% |
options accomplies |
% |
|
27/28 |
96% |
6/15 |
40% |
Dans cette partie ils ont pris en compte tous les aspects d’un logiciel, documentation, guide d’installation, design, etc.
|
JADE |
échelle |
|
Interaction avec l’utilisateur 1 |
0-1 |
|
Documentions 3.3 |
0-4 |
|
facilité d'installation 3 |
0-3 |
|
Disponibilité des fichiers binaires 5 |
0/5 |
|
Disponibilité des sources 0 |
0/4 |
|
techniques mérites 3.7 |
0-4.6 |
|
facilité de mettre en application des
agents 4 |
0-4 |
|
Développement ultérieur 1 |
0-5 |