MadKit: Multi-Agents Developpement Kit

Page réalisé par: Mohamed MAHJOUBI

La plateforme MadKit (« Multi-Agent Development Kit »), a été conçue en 1996 par Olivier GUTKNECHT et Michel FERBER pour exploiter exclusivement les avantages de la programmation multi-agents. Elle est implémenté en java et a l'originalité d'être basé sur un modèle organisationnel plutôt qu'une architecture d'agent ou un modèle d'interaction spécifique. L'utilisation de groupes et de rôles associés à des agents est mis en œuvre tant en tant qu'outil de modélisation et de conception pour les développeurs de systèmes multi-agents, que de principe d'architecture de la plate-forme elle-même.
Cette architecture est basée sur un noyau agent minimal découplé de tout modèle individuel d'agent. Dans cette plate-forme, les services classiques de passage de message distribués, de migration ou de surveillance sont fournis au meta-niveau par des agents spécialisés afin d'obtenir un maximum de flexibilité. Une interface graphique componentielle et découplée du noyau et des agents permets de supporter différentes modes d'utilisation et d'exploitation de la plate-forme. 

MadKit est basé sur un modèle organisationnel; Chaque agent est une entité autonome et communicante qui joue un ou plusieurs rôles dans un ou plusieurs groupes. Chaque groupe permet un rapprochement de certains agents ayant des affinités de communication ou de fonctionnalité. Les communications entre agents sont autorisées uniquement au sein d'un même groupe. Les rôles des agents représentent leurs capacités à effectuer un service pour un groupe donné. Un agent peut avoir plusieurs rôles et appartenir à plusieurs groupes en même temps, ce qui offre des possibilités de communication entre groupes ou alors un agent mixte peut servir d'intermédiaire entre deux groupes distincts

FIG. 1 - Le Modèle Organisationnel

Quasiment aucune contrainte n'est posée sur l'architecture interne ou le modèle de comportement de l'agent. L'agent est simplement décrit comme une entité autonome communicante qui joue des rôles au sein de différents groupes. La très faible sémantique associée à l'agent dans ce modèle est tout à fait volontaire. L'optique est bien de laisser la définition d'agent en retrait, non seulement pour ne pas prendre part dans le débat classique de « qu'est-ce qu'un agent », mais surtout pour laisser au concepteur toute liberté pour choisir l'architecture interne appropriée à son domaine applicatif.
Cette liberté se retrouvera dans les principes de MadKit

Le groupe est la notion primitive de regroupement d'agents. Chaque agent peut être membre d'un ou plusieurs groupes. D'une façon un peu simpliste, un groupe peut être vu comme un moyen d'identifier par regroupement un ensemble d'agents. Plus classiquement, associé au rôle, il définira la structuration organisationnelle d'un SMA usuel. Les différents groupes peuvent se recouper librement.

Le rôle est une représentation abstraite d'une fonction, d'un service ou d'une identification d'un agent au sein d'un groupe particulier. Chaque agent peut avoir plusieurs rôles, un même rôle peut être tenu par plusieurs agents, et les rôles sont locaux aux groupes. L'hétérogénéité des situations d'interaction est rendue possible par le fait qu'un agent peut avoir plusieurs rôles distincts au sein de plusieurs groupes, les communications étant clôturées par les groupes. 

3.1 Principes

La structure organisationnelle que nous venons de décrire est implémentée au coeur de la plate-forme MADKIT, tant pour fournir un modèle organisationnel aux SMA exécutés que pour le fonctionnement interne du système. L'utilisation de groupes d'agents pour la structuration de plate-formes a été proposée dans d'autres architectures, bien que ces mécanismes sont limités aux problèmes de migration et ne possèdent pas ce trait distinctif de prise en compte de groupes et rôles simultanés pour un agent donné. En plus de ce modèle d'organisation, MadKit est basé sur trois principes :

• Architecture à micro-noyau
• Agentification systématique des services
• Découplage applicatif entre noyau, agents et application d'accueil.

Concrètement, MadKit est un ensemble des packages Java qui implémentent le noyau agent, diverses bibliothèques de base de messages, d'agents et de sondes. Le choix de Java a été fait très tôt pour des raisons de portabilité, mais également pour la richesse des bibliothèques de bases, les possibilités de sérialisation d'objets et de présence de réflexivité, même sommaire.

FIG. 2 - L'Architecture Générale du MadKit

Le principe essentiel de MADKIT est d'utiliser partout où cela est possible la plateforme pour sa propre gestion et exécution. Tous les services hors ceux assurés par le micro-noyau sont implémentés par des agents à part entière. Ceci vient à la fois d'un souci d'unicité de modèle, mais également de mise à l'épreuve des SMA comme modèle de programmation. Cela le rapproche également fortement des approches meta en architectures objets à ceci près que nous plaçons la relation au meta entre agents applications et "systèmes" (communication, ordonnancement, surveillance...). MadKit n'est pas une plate-forme agent dans le sens classique, centrée autour d'un modèle particulier d'agent ou d'interaction. La taille réduite et les fonctionnalités du noyau de base, la neutralité des types agents, associée à ce principe de services agentifiés et de découplage par rapport aux applications "hôtes" permet en fait d'obtenir toute une gamme d'environnements d'exécutions aux finalités parfois complètement opposées.

Le "micro-noyau" de MADKIT est un environnement d'exécution d'agents de taille réduite (moins de 40 Ko). Le terme "micro-noyau" est utilisé ici intentionnellement comme référence au modèle des systèmes d'exploitation à micro-noyau.

Le noyau ne prend en charge que les fonctions suivantes :

• Gestion des groupes et rôles locaux Comme l'interopérabilité et les mécanismes d'extension de MadKit se basent sur le modèle agent-groupe-rôle, il est essentiel que cette information organisationnelle soit gérée au plus bas niveau afin que tous les agents, quels que soient leurs modèles individuels, y aient accès. Le noyau a la responsabilité de maintenir une information correcte sur les membres des groupes et les rôles tenus. Il vérifie également si les requêtes faites sur le système de groupes et rôles sont acceptables (c'est à dire en évaluant ou délégant les fonctions de rôles).
• Gestion du cycle de vie des agents Le noyau gère également le lancement (et éventuellement l'arrêt) des agents et maintient les tables de références sur les objets d'implémentation. Il est également le gestionnaire des informations administratives sur les agents (possesseur, modalités de créations, ...) et donne un identifiant garanti unique à chaque agent. Cet identifiant, l'AgentAddress, est forgé à partir de l'adresse du noyau MadKit et l'identification de l'agent sur le noyau ; il peut être rapproché de la notion de GUID de FIPA. La forme de cet identifiant peut également être redéfinie pour faciliter l'intégration avec d'autres plateformes agent.
• Passage de message local Le noyau a la responsabilité de l'aiguillage et de la distributions de messages entre agents locaux (s'exécutant sur le noyau). Le passage de message au plus bas niveau revient à de simples échanges de références pour pouvoir facilement implémenter différentes sémantiques de passage de message à un niveau supérieur.

Le noyau lui-même est en fait encapsulé dans un agent particulier, le KernelAgent qui est créé automatiquement à l'amorçage de la plate-forme. Il agit comme représentant du noyau dans le monde agent : toutes les demande de surveillance ou de contrôle sont alors écrites comme une interaction inter-agent et préservent l'unicité du modèle

Le noyau lui-même est extensible par des "hooks", des points d'interceptions sur ses opérations. Un agent autorisé (par exemple en ayant rempli les conditions d'accès au groupe "système") a la possibilité de demander un accès à l'un de ces hook. La demande se fait par une interaction agent avec le KernelAgent mentionné plus haut.
Ce hook sont un mécanisme de publication/abonnement qui permettent soit la surveillance, soit l'interception des opérations. Quasiment toutes les fonctionnalités de base du noyau (lancement d'un agent, accès et modifications à la structure organisationnelle, passage de message) sont concernées. Cela permet donc d'écrire facilement des agents d'analyse d'un SMA en fonctionnement, ou bien des agents étendant les fonctionnalités de base de la plate-forme.
Le nombre réduit de fonctionnalités bien définies favorise la modification du comportement des opérations de base tout en préservant au maximum leur sémantique. Pour toute opération noyau, il existe deux types de hooks :

• Les hooks de surveillance Un nombre quelconque d'agents peut s'abonner un tel hook. Dans ce cas, toute invocation de l'opération concernée provoquera l'envoi d'un message d'information comprenant le contexte de l'action par le KernelAgent vers les abonnés. Par exemple, on peut ainsi faire tracer par un agent les messages échangés dans un SMA en espionnant l'opération de passage de message.
• Les hooks d'interception Dans ce cas, un seul agent peut utiliser un hook d'interception sur une opération du noyau, selon un pattern de délégation. L'agent reçoit alors le contexte qui aurait dû être celui de l'opération, laquelle n'ayant donc pas lieu : l'agent peut alors définir un nouveau comportement. Pour continuer sur l'exemple de l'opération de passage de message, les agents qui permettent à MadKit de fonctionner en architecture distribuée interceptent ces invocation pour pouvoir router les messages non-locaux via un protocole réseau.

L'autre mécanisme d'extension du noyau consiste à invoquer manuellement des opérations de base. Dans ce cas, ce sont des agents habilités qui enverront une demande au KernelAgent pour que le noyau effectue une opération. Par exemple, un agent de communication réinjectera par ce biais les messages venus d'une machine distante dans le noyau local.

La classe de base d'un agent MadKit (AbstractAgent), définit quelques fonctionnalités de base pouvant être nécessaires dans les modèles classiques.

Les fonctions associées à tout agent sont :

• Cycle de vie L'agent dispose de quatre états (création, activation, exécution, et destruction), et a la possibilité de démarrer d'autres agents sur le noyau local (et les désactiver par la suite). Par contre, aucun mécanisme concret d'exécution n'est défini à ce niveau.
• Communication La communication est implémentée sous forme de passage de message asynchrone, soit d'agent à agent identifiés par leur AgentAddress ou leur groupe et rôle, soit sous la forme d'une diffusion à tous les teneurs d'un rôle dans un groupe donné.
• Organisation Tout agent dispose de primitives permettant d'observer son organisation locale (connaître les groupes et rôles courants) et d'y agir (prise de rôle, entrée et retraits de groupes).
• Outils La classe de base des agents permet également de manipuler une éventuelle interface graphique associée à l'agent, les flots d'entrée/sortie, etc.

Les messages sont définis par héritage à partir d'une classe de base qui ne définit que la notion d'émetteur et destinataires. Certain messages de base sont néanmoins fournis (encapsulation d'une chaîne ou d'un objet arbitraire, messages KQML et FIPAACL, messages XML), mais restent extensibles pour s'adapter à tout protocole d'interaction.

Pour faciliter les implémentations de modèles classique d'agents autonomes, cette classe de base est déclinée vers une implémentation associant un thread d'exécution à un agent.
Néanmoins, pour certains types de systèmes, en particulier les SMA réactifs, il est nécessaire de gérer un grand nombre d'agents (jusqu'à centaines de milliers) de granularité assez fine, et de contrôler leur ordonnancement. Cela est quasi-impossible si l'on se repose sur un mécanisme de thread à cause de la surcharge induite. Dans ce cas, on utilise ces agents "synchrones" via des agents externes qui vont définir leur politique d'exécution synchrone. Des agents d'observation peuvent être ajoutés pour avoir une vue globale sur certaines propriétés, à l'instar des plateformes classique de simulation comme CORMAS ou Swarm.

FIG. 4 - Fonctionnement des agents asynchrones

Ce modèle permet l'utilisation de plusieurs ordonnanceurs simultanés en structurant un système simulé par le mécanisme de groupe et rôle. L'intérêt de cette implémentation est que les agents exécutés dans ces systèmes synchrones ont exactement les mêmes fonctionnalités (passage de message, vue organisationnelle, ...) que les agents threadés, et peuvent donc être associés facilement en systèmes hybrides. De plus, la gestion du mécanisme de simulation ou d'observation repose encore une fois sur l'approche en groupe et rôle (on va par exemple associer une sonde à une certaine propriété présente dans les tenants d'un rôle donné sur un certain groupe).

4.1 Modèles d'agents

La définition d'un agent étant plutôt minimaliste, différentes bibliothèque implémentant des architectures d'agents classiques ont été construites en complément de cette architecture. On peut par exemple citer :

• Une bibliothèque permettant d'implémenter les agents en Scheme
• Une implémentation d'agents faisant une liaison avec le moteur de règles CLIPS de JESS. Les propriétés des agents MadKit (par exemple l'organisation) sont traduites automatiquement sous forme d'assertions dans la base.
• Différentes bibliothèques pour des SMA réactifs, comme par exemple un "TURTLE KIT" qui clone une partie des fonctionnalités de l'environnement StarLogo.
• Des outils de constructions graphique d'agents, permettant de simuler et d'exécuter en place les designs dans la plateforme.
• L'implémentation d'un modèle d'acteurs.

L'utilisation d'un de ces modèles n'est nullement exclusif : il est courant d'exécuter simultanément sur la même plate-forme MadKit des agents Scheme, réactifs, systèmes, BDI ...

A l'opposé de plateformes plus monolithiques, MadKit utilise donc des agents pour implémenter au niveau meta des services comme le passage de message distribué, la migration d'agent, la sécurité d'organisations d'agents et divers aspects de gestion du système ; et ce éventuellement à l'aide des mécanismes d'extension du noyau.
Comme ces services sont mis en oeuvre par des agents, et décrits par la structure organisationnelle, les interactions entre ces agents systèmes, le noyau, et les agents de l'applications sont décrits dans le modèle agent-groupe-role. Ceci implique qu'un agent offrant une fonctionnalité donnée peut être remplacé par un autre de façon transparente (et éventuellement durant le fonctionnement d'une application), à partir du moment où les groupes, rôles et interactions sont respectées.
Baser les services sur des agents décrits en terme de rôles a également l'effet de faciliter une montée en puissance. Un agent tenant plusieurs rôles peut, au fur et à mesure que les besoins de l'application grandissent, déléguer dynamiquement à de nouveaux agents certains de ses rôles pour réduire sa charge.
De plus, la structuration en groupe agissant souvent en "masquage" et délégation d'un SMA complexe, un rôle ne correspond pas forcément à une mise en oeuvre par un et un seul agent. Par exemple, un agent fournissant un rôle de communication système peut être un simple représentant d'un groupe d'agents spécialisés prenant en charge chacun un protocole.
Avoir découplé les services du noyau permet aussi de ne pas alourdir les applications: deux plateformes exécutant un SMA localement ou en distribué ne diffèrent que par le lancement ou non des agents de communication (figure 5).

FIG. 5 - Agents de communication distribuée

Le noyau de la plateforme ne fournit aucune interface graphique pour l'utilisateur. Il est par contre possible de lui associer une application hôte qui la mettra en oeuvre. De plus, chaque agent peut définir un objet graphique pour sa représentation, d'un simple bouton à une application classique encapsulée. L'hôte aura alors la charge, au lancement d'un agent, de décider de la mise en place de l'objet graphique défini par l'agent (dans des fenêtres séparées, combiné avec l'interface d'un autre agents, etc..) et de les gérer au niveau global. Associé au principe d'agentification des services, cela permet de modulariser complètement la plateforme. Par exemple, les variétés suivantes de MadKit ont été déja mise en oeuvre :

• La G-Box, un environnement graphique complet de développement et de test de systèmes multi-agents. Elle permet de contrôler le cycle de vie des agents, charger des SMA dynamiquement, et de manipuler graphiquement les accointances ou bien les tables de groupes et de rôles.
• Un simple "booter" pour démarrer uniquement une liste d'agents donnés, qui peut être utilisé pour la distribution finale d'une application agent ou le mise en place d'agents (facilitateurs, annuaires, interprètes) sur un serveur.
• Une applet qui empaquète le noyau agent et un SMA applicatif, pour l'exécuter dans un navigateur distant.
• Une application qui embarquerait un noyau MadKit est des agents applicatifs pour prendre en charge les aspects dynamiques ou coopératifs, indistinguable d'une application "classique"
• Une version de MadKit utilisant le même noyau que la plate-forme complète, et capable de tourner sur des assistants personnels de type Palm.

MadKit (Multi-agents Developpement Kit), est une plate-forme multi-agent basée sur un modèle organisationnel, Elle est implémenté en java et permet d'intégrer au sein d'un même outil une grande variété d'architectures d'agents et de modèles de comunication.
MadKit repose sur le modèle conceptuel Aalaadin de Jacques Ferber. Elle est très modulaire, mais n'est pas optimisée spécialement pour la simulation. Par contre, le fait qu'elle soit implémentée en Java lui offre des méthodes " clé-en-main " pour utiliser les protocoles réseaux. De plus, les outils de communication sont déjà implémentés et gèrent les envois de messages distants (en utilisant le protocole TCP/IP). Les agents Madkit sont des Threads Java, ils sont donc indépendants les uns des autres et évoluent de manière asynchrone. Le scheduler est donc nécessaire pour ordonner une simulation dans ce type de plate-forme.

• http://www.madkit.org
• H. Robert Frost. Java Agent Template. JAT Web page : http ://cdr.stanford.edu/ABE, 1997.
• Ernest J. Friedman-Hill. Jess, The Java Expert System Shell. Distributed Computing Systems, Sandia National Laboratories, Livermore, CA, 2000.
• Joachim Baumann and Nikolaos Radouniklis. Agent groups in mobile agent systems. In IFIP WG 6.1, International Conference on Distributed Applications and Interoperable Systems (DAIS 97), 1997.
• Per Bothner. Functional scripting languages for the jvm. In 3rd Annual European Conference on Java and Object Orientation, Arhus, Denmark, 1999.
• F. Bousquet, I. Bakam, H. Proton, and C. Le Page. Cormas : Commonpool resources and multi-agents systems. Lecture Notes in Computer Science, 1416 :826/837, 1998.
• M. H. Coen. SodaBot : A software agent environment and construction system. Master's thesis, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, Cambridge, MA, May 1994.
• Jacques Ferber and Olivier Gutknecht. A meta-model for the analysis and design of organizations in multi-agent systems. In Third International Conference on Multi-Agent Systems (ICMAS '98) Proceedings, pages 128/135. IEEE Computer Society, 1998.
• Olivier Gutknecht and Jacques Ferber. Vers une méthodologie organisationnelle pour les systèmes multi-agents. In Marie-Pierre Gleizes, editor, Actes des Journées Francophones en Intelligence Artificielle Distribuée et Systèmes Multi- Agents 1998. Hermés, Nov 1999.
• Richard Rashid, Robert Baron, Alessandro Forin, David Golub, Michael Jones, Daniel Julin, Douglas Orr, and Richard Sanzi. Mach : A foundation for Open Systems. In Proceedings of the 34th Computer Society Ithe Second Workshop on Workstation Operating Systems(WWOS2), September 1989.