Rôle du meta-niveau

Extension et surveillance

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

Le noyau est extensible par des points d’interceptions (hook) sur ses opérations. Un agent autorisé (par exemple en ayant rempli les conditions d’accès au groupe “système”) a la pos- sibilité d’utiliser l’un de ces hooks. La demande se fait par une interaction agent avec le KernelAgentmentionné plus haut.

Ces points d’accroche sont un mécanisme de publication/abonnement qui permet soit la surveillance, soit la redéfinition des opérations au meta-niveau. Quasiment toutes les fonc- tionnalités de base du noyau (lancement d’un agent, accès et modifications à la structure organisationnelle, passage de message) sont concernées. Concrètement, cela permet donc d’écrire facilement des agents d’analyse d’un système multi-agents en fonctionnement (dans le style de [Hubert Proton, 1997]), ou bien des agents étendant les fonctionnalités de base de la plate-forme. Ce fonctionnement est encore partiel car l’intégralité des primitives n’est pas encore exposé au méta-niveau.

Une telle analyse de systèmes a d’ailleurs été implémentée dans la plate-forme sous forme d’un jeu d’agents spécialisés dans l’observation d’autres systèmes multi-agents. Les points examinés sont la structure sociale et sa dynamique ainsi que les interactions.

Le nombre réduit de fonctionalités du cœur de la plate-forme favorise la modification du comportement des opérations de base tout en préservant au maximum leur sémantique. Le noyau est extensible par deux types de “hooks” différents, présents sur chaque opération primitive :

Les points de surveillance. Un nombre quelconque d’agents peut s’abonner à une accroche de ce type. Toute invocation de l’opération concernée provoque l’envoi d’un message d’information comprenant le contexte de l’action par le KernelAgentvers les abon- nés. Par exemple, on peut ainsi faire tracer par un agent les interactions dans un sys- tème multi-agents en espionnant l’opération de passage de message.

Les points d’interception. Dans ce cas, un seul agent peut utiliser un point 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, inactivée : l’agent a alors latitude pour

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 distri- bué interceptent ces invocations pour pouvoir router les messages non-locaux via un protocole réseau.

L’autre mécanisme d’extension du noyau consiste à invoquer des opérations de base de- puis le meta-niveau. Dans ce cas, ce sont des agents habilités qui enverront une demande au KernelAgentpour que le noyau effectue une opération. Par exemple, un agent de commu- nication réinjectera par ce biais les messages venus d’une machine distante dans le noyau local.

Amorçage

Pour clarifier ces relations entre noyau, agent, action au méta, nous avons schématisé le démarrage d’une plate-forme MADKIT. Comme souvent, l’apparition du niveau meta de- mande une petite “tricherie” préliminaire lors de l’amorçage, comme le montre le scénario suivant (voir aussi figure6.10pour la séquence des échanges entre parties) :

1. Lancement de l’application hôte.

2. L’application hôte instancie un micro-noyau MADKIT.

3. Le noyau met en place les threads utiles à son fonctionnement propre, puis initialise les tables de groupes et de rôles.

4. Un groupe local est artificiellement créé par le noyau.

5. Un agentKernelAgentest instancié par le noyau. Le constructeur de cet agent prend en paramètre une référence sur le noyau, ce qui lui donne tout contrôle sur celui-ci. 6. LeKernelAgentest démarré par le noyau. Il est inscrit de manière classique dans les

tables d’agents actifs et ses méthodes d’initialisation puis d’action sont invoquées. 7. LeKernelAgentmet en place une table de points d’accroche, qui lui permettront de

modifier le fonctionnement du noyau (espionnage, actions sur les tables de groupes, changement de la politique de transmission de message).

8. LeKernelAgentcrée le groupe system et s’y enregistre sous le rôle kernel en tant que créateur, il y définit la politique d’acceptation. Tout entrée est validée par lui.

9. LeKernelAgentse met en attente de messages.

10. Le noyau finit son démarrage par une mise en sommeil des threads non nécessaires, place une sécurité pour relancer un agent système en cas de mort de celui-ci. A partir de ce moment, d’un point de vue externe, tout se passe comme si c’était leKernelAgent qui avait lui-même lancé le noyau, l’amorçage est terminé.

11. L’application hôte qui est la seule composante à part leKernelAgentà encore avoir éventuellement une référence directe sur le noyau peut, si désiré, enregistrer une classe implémentant une interface madkit.kernel.GraphicShell pour être prévenue par le noyau des démarrages d’agents pour la mise en place d’interfaces graphiques.

Application Hôte Micro-noyau KernelAgent Agent usuel

Instanciation Instanciation et démarrage Prise de contrôle Demande de lancement Instanciation Enregistrement de GUI Démarrage Confirmation t FIG. 6.10 – Amorçage de MADKIT