Variations d’usage

Le noyau de la plate-forme ne fournit aucune interface graphique pour l’utilisateur. Il est par contre possible de lui associer une application hôte qui la mettra en œuvre. 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 agent, etc..) et de les gérer au niveau global.

Associé au principe d’agentification des services, cela permet de modulariser complète- ment la plate-forme, de l’infrastructure d’exécution d’agent à l’outil d’aide au développe- ment. Parcourons donc quelques déclinaisons possibles de la plate-forme.

Un outil de développement

Le plus souvent, l’utilisation de la plate-forme se fait par la G-BOX, un environnement facilitant le test et le développement de systèmes multi-agents. Cet environnement (appli- cation graphique hôte et agents spécialisés) permet de contrôler le cycle de vie des agents, charger de nouveaux “packs” d’agents ou d’architectures, de manipuler graphiquement les accointances (via les tables de groupes et de rôle) à fin de prototypage ou de correction d’er- reur. L’interface graphique permet de garder trace et d’organiser son espace de travail même avec un nombre d’agent important. la catégoriser en trois zones :

La barre d’agents qui identifie les modèles d’agents (Java ou Scheme), ainsi que leurs re- groupements en bibliothèques, et permet à l’utilisateur de lancer directement diverses instances. Des bibliothèques supplémentaires peuvent être rajoutées dynamiquement et apparaissent dans cet espace.

FIG. 6.13 – Déclinaison en environnement de développement

classe principale de l’agent, en découvrant par réflexivité les valeurs manipulables dans le code. Les propriétés peuvent être soit des types primitifs du langage d’im- plémentation, soit des propriétés “agent” au sens MADKIT : accointances, identifica- tion de groupes et rôles, et qui sont alors manipulés en tant que tels (par exemple en présentant la liste des agents tenant des rôles dans un groupes si l’on veut modifier arbitrairement une accointance).

L’espace de travail qui met en forme les interfaces graphiques isolées des différents agents. Une structuration en différents niveaux permet de masquer temporairement à la vue des portions de l’application multi-agents en exécution.

Des scripts de lancement d’applications agents peuvent être également enregistrés, en précisant l’ordre des instanciations et les propriétés à rétablir dans le système multi-agent en démarrage. Notons finalement que certaines parties de la G-BOXsont elle-mêmes conçues sous forme d’agents. En particulier, le module responsable de la mise en forme graphique des interfaces des agents applicatifs est lui-même un agent, communiquant avec le méca- nisme d’instanciation.

Une micro plate-forme

Si l’on peut avoir un noyau et un système multi-agent fonctionant dans quelques dizaines de Ko, cela ouvre la voie à l’utilisation d’agents sur des plate-formes restreintes. Par exemple, la catégorie de machines rangées sous le termes d’assistants électroniques ou “PC de poche”. Pour valider cette idée, nous avons développé une version de MADKITutilisant le même noyau que la plate-forme complète et capable de tourner sur des assistants personnels de type Palm6. Un système multi-agents applicatif réduit (gestionnaire de rendez-vous) a été implémenté de façon classique (dans la G-BOX) puis mis en place avec un agent de commu- nication spécifique (utilisant le port infra-rouge). Le prototype complet fonctionne malgré les limitations fortes en puissance de calcul et occupation mémoire (moins de 64 Ko disponible pour l’application). On a vu que notre désir de garder le noyau le plus minimaliste possible a une conséquence pratique assez directe : la taille de ce module est très réduite et permet d’embarquer une (petite) application agent. De plus, le fait de ne garder trace que d’agents abstraits dans le noyau et de ne pas du tout se soucier d’interface graphique ou de réseau, limite au maximum les contraintes d’implémentations (par exemple, le système graphique est complètement spécifique à la plate-forme Palm).

FIG. 6.14 – Déclinaison pour plate-forme embarquée

On voit là aussi l’intérêt d’avoir découplé en agentifié les mécanismes de distribution,

6_{Notre expérimentation a utilisé la machine virtuelle Spotless des SunLabs puis la machine virtuelle KVM de}

Sun. La plate-forme d’exécution était un ordinateur de poche Palm Pilot doté de 4 Mo de mémoire vive et d’un processeur de type 68000 cadencé à 16 Mhz.

migration et synchronisation de groupe. Il est connu que les applications agent sur des ma- chines à resources limitées et connexions intermittentes forcent à concevoir de façon diffé- rente la gestion des messages ou du code mobile. Dans MADKIT, cela correspond à la ré- écriture d’un communicateur spécialisé, mais qui garde le même schéma d’interaction avec l’agent noyau. La technologie de communication étant généralement assez exotique (liai- son par infrarouge, synchronisation sur une base), cela reste abstrait au niveau de l’agent Communicateur. Quand à l’agent applicatif, il n’a pas nécessairement à être repensé.

Un serveur agent

Une autre approche est de dépouiller au maximum la plate-forme, pour ne conserver que l’aspect environnement d’exécution.

Par exemple, pendant plusieurs semaines, un micro-noyau a été testé sur une machine serveur, sans aucune interface, avec simplement divers agents de communication (CORBA, sockets IP et courrier électronique), un agent de synchronisation de groupe et un agent “Di- rectory Facilitator” [FIPA, 1997b]. Cette plate-forme a servi de point de contact connu pour d’autres noyaux et de “routeur” de messages entre plate-formes situés dans un contexte “CORBA” et plate-formes utilisant des communicateurs par sockets.

Dans cet usage, l’amorçage de la plate-forme propose de démarrer uniquement une liste d’agents donnés, qui peut être utilisé pour la distribution finale d’une application agent ou la mise en place d’agents (facilitateurs, annuaires, interprètes) sur un serveur.

Des applications spécifiques

Nous disposons d’un noyau autonome, avec des agents capables de confier la mise en forme de leur interface graphique à un module externe connu du noyau. Cela implique qu’il est assez facile d’intégrer la plate-forme d’exécution au sein d’une application classique : la faible taille et les contraintes réduites du noyau minimisent les implications sur l’application hôte, et les agents individuels peuvent être intégrés au reste de l’application.

En poussant cette logique un peu plus loin, on peut également concevoir des applications complètement agent ayant l’apparence et le comportement d’une application classique. Il suffit d’avoir un agent qui soit le chef d’orchestre de l’interface des autres agents et qui présente un aspect unifié et habituel (menus, fenêtres, documents, ...). C’est par exemple le cas du produit WEXque nous présenterons dans les applications.

Une application qui embarquerait un noyau MADKIT et des agents applicatifs pour prendre en charge les aspects dynamiques ou coopératifs, serait difficilement distinguable d’une application “classique”.

Sur ce principe, nous avons également réalisé une variation consistant à empaqueter le noyau agent et le système multi-agent applicatif dans une applet, pour l’exécuter finalement

dans un navigateur distant. La taille limitée du noyau et la possibilité d’ajuster service et application rend cela réaliste.