Du point de vue du système et de ses pairs, un agent est une entité atomique. Cependant, du point de vue génie logiciel, je propose une architecture composite d’agent pour une séparation des préoccupations. Afin de réduire la complexité liée à la conception d’un agent capable d’effectuer à la fois des délégations et des consommations de tâches, j’adopte une approche modulaire. Dans les chapitres précédents était appelé agent ce qui est en fait un agent composite, c’est-à-dire
une entité qui regroupe les trois agents composants (cf. figure7.4) décrits dans la suite de cette
7.3. Organisation interne d’un agent 107 1 // D e f i n i t i o n des m e s s a g e s 2 o b j e c t P i c h e n e t t e 3 o b j e c t A v e r t i s s e m e n t 4 o b j e c t H u l k S m a s h 5 o b j e c t C a l m e 6 7 // D e f i n i t i o n de l ’ a g e n t B r u c e 8 c l a s s B r u c e e x t e n d s A c t o r { 9 10 // N i v e a u de p a t i e n c e de l ’ a g e n t 11 var p a t i e n c e : Int = 3 12 13 // E t a t i n i t i a l de l ’ a g e n t 14 def r e c e i v e : R e c e i v e = t h i s. b a n n e r 15 16 // E t a t B a n n e r 17 def b a n n e r : R e c e i v e = { 18 19 c a s e P i c h e n e t t e if t h i s. p a t i e n c e > 0 = > 20 // A c t i o n d e c l e n c h e e a la r e c e p t i o n d ’ un m e s s a g e P i c h e n e t t e 21 // et d a n s le cas ou la v a r i a b l e p a t i e n c e est non n u l l e 22 t h i s. p a t i e n c e -= 1 23 24 c a s e P i c h e n e t t e if p a t i e n c e = = 0 = > 25 // A c t i o n s d e c l e n c h e e s a la r e c e p t i o n d ’ un m e s s a g e P i c h e n e t t e 26 // et d a n s le cas ou la v a r i a b l e p a t i e n c e est n u l l e 27 s e n d e r ! A v e r t i s s e m e n t 28 // C h a n g e m e n t d ’ e t a t B a n n e r - > H u l k 29 c o n t e x t b e c o m e t h i s. h u l k 30 31 } 32 33 // E t a t H u l k 34 def h u l k : R e c e i v e = { 35 36 c a s e P i c h e n e t t e = > 37 // A c t i o n d e c l e n c h e e a la r e c e p t i o n d ’ un m e s s a g e P i c h e n e t t e 38 s e n d e r ! H u l k S m a s h 39 s e l f ! C a l m e 40 41 c a s e C a l m e if s e n d e r = = s e l f = > 42 // A c t i o n d e c l e n c h e e a la r e c e p t i o n d ’ un m e s s a g e C a l m e que l ’ a g e n t s ’ est 43 // e n v o y e a lui m e m e 44 t h i s. p a t i e n c e = 3 45 c o n t e x t b e c o m e t h i s. b a n n e r 46 47 } 48 49 }
Figure 7.3 : Extrait de code Akka traduisant le comportement illustré par la figure7.2
composés de leurs propres agents composants.
Similairement à l’architecture V3A de [Morge et al. 2008], cette architecture composite permet
une séparation claire des préoccupations. Un agent composant possède son propre comportement et son propre rôle dans les actions globales de l’agent composite. On peut assimiler ces agents aux facettes de l’architecture V3A. Cependant, contrairement aux facettes, les agents composants ne partagent pas de données et communiquent de façon asynchrone. De plus, les agents composants n’ont pas à régler de conflits de part la définition de leurs comportements individuels.
108 Chapitre 7. Architecture composite d’agent
Une telle approche permet de spécifier de manière intelligible les différents rôles et comporte- ments d’un même agent. Elle facilite également la co-occurence des délégations et des consomma- tions de tâches. Cette section expose une architecture au sein de laquelle les actions de plusieurs agents composants, chacun avec son propre rôle et son propre comportement, produisent le com-
portement global de l’agent. La section 7.3.1 présente le manager , le broker et le worker , les
trois agents composants d’un agent d’une instance MASTA. Ensuite, la section7.3.2décrit com-
ment ces agents composants communiquent et interagissent pour faire émerger le comportement global d’un agent.
7.3.1 Agents composants
Un agent composite est composé de trois agents composants, tous dotés de leur propre file de messages et qui agissent simultanément :
1. le worker est l’agent composant chargé d’exécuter les tâches localement (cf. chapitre 4) ;
2. le broker est l’agent composant chargé d’initier des enchères en tant qu’initiateur ou de
répondre à celles initiées par les pairs en tant qu’enchérisseur (cf. chapitre 5) ;
3. le manager est l’agent composant chargé de la gestion du lot de tâches. C’est lui qui implémente la stratégie de sélection de tâches et qui distribue les tâches à exécuter au
worker et les tâches à déléguer au broker . Il s’occupe également de la mise à jour de la
base de croyances (cf. chapitre 6).
Aucun des agents composants ne communique directement avec les autres agents du système. L’agent composite sert d’interface pour ses agents composants. Par exemple, lorsque le broker souhaite initier un cfp, il produit le message, l’envoie à son agent qui transfert le message à l’ensemble de ses pairs. Ce sont ensuite les autres agents du système qui reçoivent le cfp et le transmettent à leur propre broker . Le broker et le worker sont deux agents indépendants, ils ne communiquent pas. En revanche, le manager orchestre la distribution des tâches au broker et
au worker . La figure 7.4illustre la structure composite d’un agent ainsi que les différentes voies
de communication qui existent entre les différentes entités d’un même agent.
7.3.2 Protocoles d’interaction des agents composants
Les agents composants sont créés localement par l’agent composite. Un agent et ses trois agents composants partagent donc tous la même localité. À l’inverse des communications entre agents distants, les communications entre les trois agents composants d’un même agent sont similaires à des appels de méthodes et ne sont donc pas sujettes à la perte ou au retard de messages. De ce fait, il n’est pas nécessaire d’ajouter un mécanisme de timeout comme celui présenté dans le
chapitre 5.
Afin qu’un agent exhibe un comportement cohérent, les trois agents composants doivent se coordonner. Cette section décrit le protocole d’interaction qui permet au manager , au broker et au worker de communiquer et de se synchroniser pour consommer des tâches en continu tout en participant (en tant qu’initiateur ou enchérisseur) aux délégations socialement rationnelles qui profitent à l’ensemble du système.
7.3. Organisation interne d’un agent 109
Figure 7.4 : Structure interne d’un agent. Les quadrilatères de couleur représentent les tâches (gérées par le manager , consommées par le worker , négociées par le broker ). Le manager administre la base de croyances (BdC). Le broker peut tenir deux rôles mutuellement exclusifs : enchérisseur ou initiateur. Les flèches pleines représentent des communications entre les agents composants. Les flèches en pointillés représentent des communications entre l’agent et ses pairs.
comportements j’indique, entre parenthèses et à la suite de sa description, le nom du message qui le déclenche.
Consommer des tâches
Comme illustré dans la figure 7.5, les consommations de tâches impliquent le manager et le
worker . L’objectif des agents étant d’exécuter l’ensemble des tâches au plus tôt, le manager
priorise ses interactions avec le worker : dès que le worker produit le résultat d’une tâche, le
manager en est informé (done) et founit une nouvelle tâche à consommer (perform). Manager Worker
1 perform(τ ) 2 done
110 Chapitre 7. Architecture composite d’agent
Initier des délégations de tâches
Les délégations de tâches impliquent le manager et le broker . Le manager ne fournit une tâche à déléguer au broker qu’à partir du moment où le worker est occupé.
Comme illustré dans la figure 7.6, c’est le manager qui demande au broker d’initier une enchère
(submit). Si le broker n’est pas engagé comme enchérisseur, il initie un cfp. Sinon, il rejette l’initiative du manager (abort).
Plusieurs scénarios sont possibles pour conclure une enchère. Quand toutes les réponses ont été reçues ou que le timeout survient, le broker évalue les réponses. Si aucune proposition n’a été
reçue, le broker en informe le manager (deny) et met fin à l’enchère (cf. chapitre 5). Sinon, le
broker sélectionne la meilleure proposition et rejette les autres. Il informe alors le manager qu’il
est prêt à déléguer la tâche (ready). Le manager répond au broker en lui indiquant si la tâche est toujours disponible (approve) ou si elle a été donnée au worker durant l’enchère (cancel). Si la tâche n’est plus disponible car elle a été donnée au worker entre-temps, la proposition qui a été retenue est finalement rejetée (reject). Sinon, la tâche est envoyée à l’enchérisseur qui a remporté l’enchère (accept) et une confirmation est attendue. Il est possible que la tâche choisie par le manager pour être déléguée donne lieu à un cfp décliné par tous les pairs de l’agent, ce qui exprime une imprécision de la base de croyances au moment du choix de la tâche à déléguer. Dans ce cas, le broker en informe le manager (declinedByAll). Néanmoins, le manager peut de nouveau chercher une tâche à déléguer car la base de croyances a été mise à jour à chaque réponse d’un pair au broker (informPeerWorkload). Si aucune tâche ne peut être déléguée, le
manager passe en état de pause.
Comme illustré dans la figure7.7, chaque réponse à un cfp, que ce soit une proposition (propose)
ou une déclinaison (decline), est prise en compte pour mettre à jour la base de croyances de l’agent (informPeerWorkload).
Participer aux enchères
La participation aux enchères demande l’implication des trois agents composants. Comme pré-
senté dans la figure 7.8, lorsque le broker reçoit un cfp et qu’il n’est pas initiateur, il demande
la charge de travail courante de l’agent au manager (queryWorkload) afin de déterminer s’il peut faire une proposition. Ensuite, le manager demande au worker une estimation du coût que représente la fin de l’exécution de la tâche courante (queryRemainingWork) pour donner au
broker l’estimation la plus précise possible de la charge de travail de l’agent (informWorkload).
Comme le montre la figure7.9, une fois que le broker a reçu l’information sur la charge courante,
il peut utiliser sa surcharge virtuelle et déterminer si la délégation est socialement rationnelle. En fonction de la situation, le broker fait une proposition (propose), stocke le cfp pour le considérer
plus tard (cf. chapitre 5) ou le décline (decline). Lorsque la phase d’appel à propositions est
terminée, soit (a) le broker remporte l’enchère, transfert la tâche au manager (request) et confirme le succès du transfert à l’initiateur (confirm), soit (b) le broker ne remporte pas l’enchère. Lorsque le broker n’est plus impliqué dans aucune enchère, il est libre et informe le