Nous allons maintenant prendre le point de vue de l’implémenteur et présenter l’archi- tecture de la plate-forme que nous avons réalisée pour valider notre approche, MADKIT.
6.2.1 Contexte
Imaginons que nous ayons à concevoir une plate-forme multi-agents générique. La pre- mière question que nous nous poserons sera : quelles sont donc les fonctionnalités dont j’ai besoin pour faire fonctionner les agents que je veux construire ? (ce qui est a priori la partie intéressante de la tâche).
On pourrait alors rapidement établir une première liste de fonctionnalités classiques : communication par message, moteur de simulation multi-agents, modèle d’environnement, définition de protocoles d’interaction , gestion du cycle de vie , mobilité d’agent , identifica- tions uniques , observation des systèmes multi-agents en activité , agents à base de règles , exécution concurrente ou distribuée , sécurité et contrôle des systèmes multi-agents, ...
Bref, la liste est longue et décourageante. Mais, réflexion faite, un raffinement de notre question un peu naïve pourrait être : quelles sont les fonctions primitives d’une plate-forme grâce auxquelles les autres fonctionnalités courantes peuvent être ré-implémentées ?
6.2.2 Principes et choix initiaux
Nous en sommes donc arrivés au cahier des charges suivant :
Base de communication : fournir le minimum de ce que l’on peut attendre d’un système de communication asynchrone. Cela comprend pour tout agent l’envoi et la réception de messages via une boîte aux lettres, la garantie de transmission ordonnée et de déli- vrance en cas de présence du récepteur sur le système.
Gestion de l’identité et du cycle de vie : permettre d’identifier de façon unique des agents, les instancier (en tant qu’agent et non simplement objet) et les suivre jusqu’à dispari- tion.
Politique d’exécution : définir quelques politiques d’exécution de base (séquencées, paral- lèles) sur lesquelles bâtir des modèles d’exécution (influence/réaction, comportements concurrents, ...)
Structuration applicative : donner des moyens au concepteur final de faire le lien entre l’or- ganisation de son application et les détails terre-à-terre de catégorisation de ses agents. Les conséquences pratiques des trois premières contraintes sont très directes et évoquent chez l’implémenteur quelques questions intéressantes : exécution concurrente, implémenta- tion d’un schéma de nommage, mécanisme de routage de messages. Tout ceci est nécessaire, mais cela reste assez terne vis à vis d’autres systèmes. Nous allons donc préciser le dernier point :
Maintien d’une vue organisationnelle : l’ensemble des agents définis sur la plate-forme a accès aux notions de groupes et de rôles. Tout agent peut participer à un schéma orga- nisationnel qu’il peut interroger et avec lequel il peut interagir.
C’est en fait là que réside le choix radical de notre plate-forme : les informations relatives au modèle social ne seront pas mises en place au niveau de l’agent. Au lieu d’avoir des repré- sentations internes -modèles de connaissances ou d’accointances ou simples perceptions de l’environnement organisationnel-, on a une information purement extrinsèque mais accessible des groupes et des rôles.
Bien sûr, ces informations sont (relativement) sommaires : on pourrait remarquer qu’il ne s’agit que d’un étiquetage d’agents, certes, mais situé à un niveau peu courant puisque les informations sociales sont habituellement considérées comme relevant d’un très haut ni- veau de description [Castelfranchi, 1995]. Classiquement, elles relèvent de la connaissance générale de l’agent sur son environnement ou bien de choix d’architectures et de construc- tion, apparaissant “en creux” dans les implémentation par les schémas d’interactions ou les mécanismes d’identification ou de communications et perdues dans le système final2.
Notre réflexion a été la suivante :
– L’architecture individuelle d’un agent est un choix fort fait par le concepteur. C’est elle qui va définir au minimum un modèle d’action et éventuellement des modèles de rai- sonnement, perception et de symbolisation, il faut laisser ce choix, et ne pas forcément séparer agents “cognitifs” et agents “réactifs”.
– L’activité collective est le point singulier de ces modèles. Figer le modèle de structuration (et non la structure) d’une société d’agents empêche la réintégration ultérieure d’autres entités et modèles.
2On peut noter que l’utilisation de groupes d’agents pour la structuration de plate-formes a été proposée
dans d’autres outils, comme [Baumann et Radouniklis, 1997], bien que ces mécanismes soient spécifiques au domaine (migration d’agent), et reposent sur un modèle plus contraignant (sans la possibilité de groupes et rôles simultanés pour un agent donné)
– La plate-forme doit s’effacer devant ses usages. Vu la richesse des domaines applicatifs des modèles agents, il est souhaitable de définir des possibilités de modularisation de l’infrastructure plutôt qu’une plate-forme monolithique.
Ces principes d’architecture pour la plate-forme vont au-delà du simple modèle agent- groupe-rôle. Notons finalement qu’il reste tout à fait envisageable (cela a d’ailleurs été réalisé dans au moins un système à notre connaissance) d’implémenter une structuration de type agent-groupe-rôle dans une plate-forme autre que MADKIT.
6.2.3 Filiations
MADKIT n’a bien évidemment pas surgi ex nihilo. Il nous paraît donc intéressant de mentionner diverses influences ou filiations sur notre système (lesquelles ne sont d’ailleurs pas toutes dans le “monde agent”).
Java XML Scheme SEdit Mach ActTalk Paladin Mering IV MACE Telescript JNA Swarm StarLogo SOAR TurtleKit JESS MadKit Moteur Synchrone
Influence conceptuelle ou architecturale Lien d'implémentation ou intégration
Metagen
Système IA ou SMA Technologie
Système réalisé
FIG. 6.3 – L’arbre de famille de MADKIT
De MACE [Gasser et al., 1987], on retrouve bien évidemment l’idée de rôle, présente au- tant comme élément conceptuel du modèle de description que de stratégie d’implémenta- tion. MACE a cette particularité de définir des modèles de connaissances de haut niveau axés directement sur la représentation de l’organisation. Les accointances d’un agent sont dési- gnées explicitement au niveau organisationnel en termes de nom, de classe ou d’adresse,
mais également en termes de rôle, capacité, but ou plan.
JNA (Java Net Agents) [Merlat, 1999] a elle-même un héritage assez net des concepts de TeleScript[White, 1996], avec les notions de lieux d’exécution et de “tickets” pour contrôler les caractéristiques d’un agent. C’est aussi face à un certain manque de souplesse de JNA et TeleScript sur une application qu’est venue l’idée de découpler le plus possible le noyau d’une plate-forme des agents et de l’interface. On peut trouver trace des agents de contrôle (l’agent “concierge”) dans l’idée de services systématiquement agentifiés de MADKIT.
De PALADIN [Ferber, 1989] et de certaines de ses influences : on trouve ici l’accent sur la flexibilité de la plate-forme, l’idée d’une plate-forme d’implémentation par et pour des agents. MADKITse démarque de PALADINpar le choix fait de n’aborder l’agent que comme un certain niveau d’abstraction (au dessus d’un modèle objet ou fonctionnel) et non comme une intégration complète dans le modèle d’exécution lui-même3
Java et Scheme. Le choix de Java est venu très rapidement. Parmi les objectifs initiaux de MADKIT, la généricité et la souplesse étaient en tête. Bien sûr, la portabilité nous permet de nous abstraire des machines physiques. Néanmoins, d’autres détails ont fait pencher la balance, comme l’intégration des processus de sérialisation.
La présence de Scheme se justifie par l’interactivité et la souplesse de développement : il est nettement plus confortable de pouvoir prototyper un agent sur le moment que de repasser par un cycle de compilation/empaquetage/chargement.
Les systèmes d’exploitation à micro-noyaux Le nom même de “micro-noyau” agent que nous retrouverons plus tard est un clin d’œil transparent à ces architectures, qui furent une inspiration pour la structuration de la plate-forme. En appliquant leur principe fondateur [Rashid et al., 1989] ‘incorporating in micro-kernels a small number of key facilities that allow the efficient deployment of system services.” aux architectures agents, on aura une idée de la trans- position faite ici.
De MetaGen. La recherche sur les environnements de meta modélisation et meta program- mation est également une référence, avec en particulier le système MetaGen[Revault, 1996] dont des traits se retrouvent dans le mécanisme d’extension de MADKITet surtout l’éditeur multi-modèles SEdit (que nous présenterons brièvement chapitre8).