4 Architecture logicielle
4.4 Comportement d’un agent service
Unagent service gère le service auquel il est attaché. Il est en charge de lui trouver (si c’est possible) la meilleur connexion possible. Pour cela, il interagit et coopère avec les autres agents et utilise ses connaissances apprises sur les préférences de l’utilisateur. Il possède six états : créé, non connecté, connecté, en attente de réponse, en attente du feedback de l’utilisateur et en veille. Il fonctionne selon le cycle agent : il récupère les messages qu’il a reçus qui constituent sa perception; il analyse ces messages et décide de l’action à entreprendre selon ses connaissances et son état ; et finalement il exécute l’action choisie.
Le comportement de l’agent serviceest réalisé par trois modules correspondant aux trois phases de son cycle de vie : lemodule de perception, lemodule de décisionet lemodule d’action.
4.4.1 Module de perception
Le rôle du module de perception d’unagent service(appelons-leAi) est de récupérer les mes-sages qu’il a reçus. Pour chaque message d’annonce reçu par Ai, le module de perception vérifie si le service géré par l’agent serviceémetteur du message est compatible avec le ser-vice géré parAi. Si c’est le cas, le message est conservé dans une liste, sinon il est supprimé.
Les autres messages sont ajoutés, sans analyse, à la liste des messages. La liste des messages ainsi constituée par le module de perception forme laperceptiondeAi.
4.4.2 Module de décision
Le module de décision permet à l’agent servicede prendre une décision d’action en fonction de son état, de sa perception et éventuellement de ses connaissances. Le comportement de l’agent servicevarie en fonction de son état :
1. créé : c’est l’état initial de l’agent service(appelons-leAi) à sa création. Dans cet état, la décision prise parAi est d’exécuter l’étape “Annoncer” du protocoleARSA: il envoie un message d’annonce en diffusion, afin d’annoncer sa présence dans le moteurOCEet sa disponibilité pour la connexion.Aireste dans cet état pendant un seul cycle agent et se met dans l’étatnon connectéà la fin du cycle agent courant.
2. non connecté : cet état correspond à l’état du service géré par Ai. Dans cet état, Ai cherche à se connecter avec un autre agent service. A chaque cycle agent, Ai peut re-cevoir plusieurs messages de différents types : des messages échangés dans le cadre du protocoleARSA(message d’annonce, de réponse, de sélection ou d’acceptation de connexion), un message de mise en veille ou un message de feedback.
Deux messages sont traités en priorité parAi, indépendamment de sa perception et de ses connaissances : dans l’ordre, le message de mise en veille (envoyé par lasonde) et celui du feedback (envoyé par l’entité de liaison).
LorsqueAireçoit un message de mise en veille il passe à l’étaten veille. Lorsqu’il reçoit un message de feedback, Ai construit ou met à jour ses connaissances et passe à l’état
connecté. Ce dernier cas peut se produire lorsque l’utilisateur ajoute, à l’assemblage proposé, la connexion entre le service géré parAiet un autre service (parmi les services satellites).
Nous reviendrons sur la construction et la mise à jour des connaissances d’unagent ser-viceà la section5.2.2du chapitre5qui présente le modèle de décision et d’apprentissage d’unagent service.
En ce qui concerne les autres messages (c’est-à-dire les messages échangés dans le cadre du protocoleARSA),Aine peut traiter qu’un seul message. Il doit donc choisir un mes-sage. Pour cela, la solution que nous préconisons est de se baser sur ses connaissances.
Nous reviendrons sur ce point avec plus de détails à la section5.2.1.
Si le message choisi parAiest :
- un message d’annonce alorsAiexécute l’étape “Répondre” du protocoleARSAet ne change pas d’état (cf. section4.3.1.2) ;
- un message de réponse alorsAiexécute l’étape “Sélectionner” du protocoleARSA et passe à l’étaten attente de réponse(cf. section4.3.1.3) ;
- un message de sélection alorsAiexécute l’étape “Accepter” du protocoleARSAet passe à l’étaten attente de feedback de l’utilisateur(cf. section4.3.1.4) ;
- un message d’acceptation de connexion alors Aipasse à l’étaten attente de feed-back de l’utilisateur(cf. section4.3.1.4) ;
D’autre part, si pendant plusieurs cycles agent consécutifs (que nous avons fixé à 8) la perception de Ai reste vide, Ai envoie un nouveau message d’annonce à la recherche des opportunités de connexion.
3. en attente de réponse : Aia sélectionné un autreagent service(appelons-leAj) et attend de recevoir de Ajle message d’acceptation de la connexion. Cet état est temporaire : il durepcycles agent (p∈N+est un paramètre interne de l’agent serviceque nous avons fixé à 8).
Pendant ces pcycles agent, le comportement deAi varie en fonction de sa perception.
Si Ai reçoit un message de mise en veille envoyé par la sonde, il se met dans l’étaten veilleet il ordonne à l’agent binderqu’il a créé de déclencher son mécanisme de suicide.
Sinon, siAireçoit un message d’acceptation de connexion la part de l’agentAj, il se met dans l’étaten attente du feedback de l’utilisateur. Les autres messages sont ignorés.
Passés cespcycles agent, s’il ne reçoit pas le message d’acceptation de la part deAj,Ai se met dans l’étatnon connecté.
4. en attente du feedback de l’utilisateur : cet état décrit le fait que Ai est en attente du feedback de l’utilisateur sur la connexion dont il fait partie.
Dans cet état, le comportement deAivarie en fonction de sa perception. SiAi reçoit un message de mise en veille envoyé par la sonde: il envoie un message de déconnexion à l’agent serviceavec lequel il est connecté ; l’agent binder qui gère cette connexion dé-clenche son mécanisme de suicide ;Aise met dans l’étaten veille. Sinon, siAireçoit un message de feedback, il le traite et change d’état, plusieurs cas sont possibles selon si la connexion dontAifait partie est :
- acceptée :Aipasse à l’étatconnecté; - refusée :Aipasse à l’étatnon connecté;
- remplacée par une ou plusieurs connexions : Ai met à jour la référence de l’agent serviceavec qui il est connecté et passe ensuite à l’étatconnecté.
Les autres messages sont ignorés.
5. connecté : comme pour l’étatnon connecté, cet état correspond à l’état du service géré parAi.Aireste dans cet état jusqu’à ce qu’il reçoive :
- un message de déconnexion envoyé par l’autre agent service avec qui il est connecté ; il se met alors dans l’étatnon connecté;
- un message de mise en veille envoyé par lasonde: dans ce cas,Ai envoie un mes-sage de déconnexion à l’agent serviceavec lequel il est connecté ; l’agent binderqui gère cette connexion déclenche son mécanisme de suicide ;Aise met dans l’étaten veille;
- un message d’échec de la connexion physique envoyé par l’agent binder; il se met alors dans l’étatnon connecté.
LorsqueAiest connecté et qu’il reçoit des messages des autresagents service, différentes stratégies sont possibles :
- stratégie 1 : analyser ces messages et ne pas y répondre ;
- stratégie 2 : analyser ces messages et se déconnecter de sa connexion actuelle si l’un des messages peut aboutir à une meilleure connexion ;
- stratégie 3 : mémoriser les messages et différer leur analyse en attendant d’être dans l’étatnon connecté.
Pour la stratégie 2, de par la dynamique et l’ouverture de l’environnement ambiant,Ai peut être amené à faire beaucoup de déconnexions et de connexions. Par conséquent, les assemblages construits par OCEne seront pas stables d’une part, et d’autre part, l’utilisateur sera souvent sollicité. Pour la stratégie 3, deux problèmes peuvent survenir.
Le premier est l’obsolescence des messages mémorisés : il est possible que lesagents servicequi ont envoyé ces messages sont enveille, ou ils ne sont plus disponibles pour se connecter. Le deuxième concerne la limitation des ressources notamment la mémoire deAi. Pour toutes ces raisons et pour assurer la stabilité des assemblages construits par OCEnous avons opté pour la stratégie 1.
6. en veille : c’est l’état dans lequel Ai se met lorsque le service qu’il gère disparaît de l’environnement ambiant. Ai reçoit un message de mise en veille envoyé par lasonde; ce message est prioritaire :Ai le traite en priorité, quel que soit son état courant.
Comme pour l’étatconnecté, lorsque Ai est dans cet état, il ne traite aucun message envoyé par un autreagent service.
Lorsque le service géré parAiréapparaît dans l’environnement ambiant,Ai est réveillé parla sonde: il se met dans l’étatnon connecté.
Les conditions de passage d’un état à un autre sont résumées dans la figure4.8.
4.4.3 Module d’action
Ce module exécute l’action décidée par l’agent servicedurant la phase de décision.
4.5 Conclusion
Nous avons présenté dans ce chapitre le moteurOCE(Opportunistic Composition Engine), un système multi-agent capable de construire automatiquement et à la volée des assemblages pour un utilisateur en interaction avec un environnement ambiant et dynamique. Les as-semblages sont construits en modebottom-upselon l’approcheopportunistesans se baser sur les besoins, les préférences ou les habitudes de l’utilisateur ou des plans d’assemblage prédéfinis.
Nous avons décris dans un premier temps l’ensemble du système de composition. En-suite, nous avons présenté l’architecture d’OCEet nous avons décrit les différents éléments qui le composent. Dans un deuxième temps, nous avons décrit ARSA, un protocole de communication et de coopération inter-agents qui supporte la prise de décision locale des connexions à réaliser. Il assure la découverte et la sélection de services et la prise en compte de la nouveauté, et supporte la dynamique, l’ouverture et l’imprévisibilité de l’environne-ment ambiant. Enfin, nous nous sommes focalisé sur unagent service et nous avons décris son comportement et ses interactions avec les autres agents afin de décider localement des connexions à réaliser et ainsi du ou des assemblages à faire émerger.
Dans le chapitre suivant, nous présenterons le modèle de décision et d’apprentissage d’OCEpermettant auxagents servicede construire les connaissances dont ils ont besoin pour construire des assemblages pertinents pour l’utilisateur.