Les protocoles d`interaction dans des systèmes multi agents

DEA
Module
Mots Clés
Sujet
Préparé par
Dirigé par
:
:
:
:
:
:
RACOR option RFCI
IMR (Initiation à la Méthodologie et à la Recherche)
SMA, protocoles d’interaction, FIPA
Les protocoles d’interaction dans les SMA
Houssam FAKIH ([email protected], UTT)
Zahia GUESSOUM ([email protected], LIP6)
Les protocoles d’interaction dans des systèmes multi agents
L’interaction entre les agents est
plus qu’un simple échange de messages
[Barbuceanu, 1995] : un des aspects
d’interaction montre une conversation basé
sur un échange partagé et conventionné de
messages.
•
•
Les conversations entre agents dans
les SMA sont souvent structurées selon des
schémas typiques appelés protocoles
d’interaction.
Les protocoles d’interaction peuvent
être modélisés en utilisant différents
formalismes tels que :
• les graphes état transition
• les graphes de raisonnement
• les réseaux de pétri
• les langages formels
• les langages de description de
protocoles
Les
protocoles
d’interaction
permettent de décrire explicitement les
enchaînements conversationnels lors des
communications entre les agents. Ils
représentent un schéma commun de
conversation utilisé pour exécuter une
tâche, une stratégie de haut niveau
gouvernant les interactions entre les agents
tout en permettant de faciliter leur
dialogue. Un protocole précise qui peut
dire quoi à qui et les réactions possibles à
ce qui est dit.
Les
protocoles
d’interaction
permettent de définir une séquence causale
des messages communiqués entre les
agents et décrivent comment les agents
doivent réagir aux messages reçus durant
les interactions.
Les aspects de ces protocoles
d’interaction diffèrent selon le type des
agents. (Agents concurrents ou agents à
des buts communs)
Il existe différents types
protocoles d’interaction, on cite :
• Les protocoles de coordination,
de
Les protocoles de coopération,
Les protocoles de négociation, ainsi
que
• les
mécanismes
du
commerce
électronique.
La définition d’une architecture
logicielle
générique
permettant
l’interopérabilité entre les agents dans des
environnements ouverts et dynamiques
semble intéressante pour l’exploitation des
protocoles d’interaction. Plusieurs groupes
de recherche ont déjà défini leurs propres
modèles. On cite les modèles de FIPA,
General Magic, KAoS, OMG, ZEUS le
modèle des laboratoires de British
Telecom, et le modèle de l’université de
Calgary.
Les protocoles de coordination
Dans des environnements à ressources
limitées, la coordination se traduit par un
comportement individuel visant à servir ses
propres intérêts tout en essayant de
satisfaire le but global du système.
[Jenings, 1993] caractérise la coordination
par deux aspects étroitement liés, à savoir
les engagements et les conventions :
Les engagements fournissent la
structure nécessaire pour des interactions
prévisibles. Pendant que les situations
changent, les agents doivent évaluer si les
engagements existants sont encore valides.
Les conventions fournissent des
moyens pour contrôler les engagements
dans des circonstances changeantes.
Les protocoles de négociation
Un des exemples de protocole pour la
coordination est celui du réseau contractuel
(contract-net) [smith, 1980]. L’intérêt d’un
tel protocole est qu’il réalise la
coordination de tâches parmi les agents en
assurant l’allocation la plus optimale
possible.
Les mécanismes
électronique
Les protocoles de coopération
Les protocoles de coopération consistent à
décomposer un problème en tâches puis à
les distribuer [Durfee et Montogomery,
1990]. Cette approche a l’avantage de
réduire la complexité d’un problème. Mais
il risque d’avoir des interactions entre les
tâches et par conséquent des conflits entre
les agents.
Il existe plusieurs mécanismes pour
distribuer les tâches. On cite les
mécanismes d’élection où les tâches sont
attribuées à des agents suite à un accord ou
un vote, les réseaux contractuels où des
tâches sont attribués aux agents suite à des
cycles
d’appels
d’offres
ou
de
propositions.
La planification multi agents attribue aux
agents planificateurs la responsabilité de la
distribution des tâches et la structure
organisationnelle où les agents ont des
responsabilités
pour
des
tâches
particulières.
Les protocoles de négociation sont utilisés
dans le cas où les agents ont des buts
différents. Les dispositifs principaux de la
négociation sont : le langage utilisé, le
protocole suivi dans le principe de
négociation et la procédure de décision que
chaque agent utilise pour déterminer ses
positions, ses concessions et ses critères
pour l’accord.
du
commerce
Les
mécanismes
du
commerce
électronique exigent de l’organisation et un
nombre important de communications. Ils
présentent l’avantage d’être simple,
équitable, distribué et très utile dans le cas
où il s’agit de décider une action ou une
solution parmi plusieurs proposées.
Une autre approche consiste à utiliser de
mécanismes de vente appelés aussi les
ventes aux enchères.
Une vente aux enchères est un mécanisme
économique permettant de déterminer le
prix d’un article. Elle exige une
méthodologie prédéfinie, où se réunissent
un ou plusieurs contractants qui souhaitent
acheter l’article. Habituellement l’article
est vendu d’une façon publique au plus
offrant.
Les protocoles de FIPA
FIPA spécifie un environnement
d’existence et de fonctionnement des
agents ainsi qu’une infrastructure physique
de déploiement des agents [FIPA, 1997a].
FIPA définie une plate-forme des agents
qui représente l’infrastructure dans laquelle
les agents peuvent être déployés, un
système de gestion des agents décrit tel les
agents peuvent gérer la création, la
suppression, la suspension, la reprise,
l’authentification et la migration des autres
agents tout en assurant un service des
pages blanches ainsi qu’un service des
pages jaunes.
On
présente
ci-dessous
protocoles d’interaction de FIPA.
les
Le protocole FIPA-request :
Il permet à un agent d’inviter d’autres
agents à exécuter une certaine action.
L’agent récepteur peut refuser ou accepter
la tâche. S’il l’accepte, il doit exécuter
l’action et informer l’agent qui l’a
demandée.
Le protocole FIPA-query :
Dans ce protocole, l’agent cherche à
connaître un objet correspondant à une
description ou interroger un autre agent sur
la proposition ou l’état sur l’exécution
d’une autre action. La demande d’être
informé est une requête qui se traduit par
deux
actes
possibles :
Query-if
(questionner si une proposition est vraie)
et Query-ref (demander la liste des objets
correspondant à une référence ou à une
description). L’un ou l’autre acte peut être
utilisé pour lancer ce protocole. Le
récepteur projettera de renvoyer la réponse
à la requête par l’acte Inform.
Le protocole FIPA-request-when :
Ce protocole est utilisé par les agents
voulant demander à d’autres agents
d’exécuter une certaine action à l’avenir
une fois la condition préalable donnée
devient vraie. Si l’agent destinataire
accepte la demande, il attend l ‘état vrai de
la condition préalable pour exécuter
l’action puis il informera l’agent
expéditeur de demande que l’action a été
exécuté. L’agent destinataire peut refuser
l’exécution de la demande dans le cas où il
serait occupé par des tâches plus
prioritaires une fois que la condition
préalable soit vraie.
Le protocole FIPA-contract-net :
L’agent prend ici le rôle du manager. Le
manager souhaite faire accomplir une
certaine tâche par un ou plusieurs autres
agents, et optimaliser une fonction qui
caractérise la tâche. Cette caractéristique
est généralement exprimée comme coût,
spécifique au domaine.
L’agent sollicite des propositions d’autres
agents en émettant un appel d’offres
décrivant la tâche et les conditions
nécessaires à son exécution. Les agents
recevant l’appel peuvent fournir des
propositions pour accomplir la tâche. La
proposition de l’agent contractant contient
les conditions préalables pour l’exécution
de la tâche (prix par exemple). Une fois
que le manager reçoit des réponses de tous
les contractants, il évalue les propositions
et fait son choix sur un, plusieurs ou aucun
agent pouvant accomplir la tâche. Les
agents ou l’agent choisis seront notifiés par
un message d’acceptation. On suppose que
le contractant s’engage à accomplir la
tâche dès qu’il reçoit le message
d’acceptation.
Un
message
d’accomplissement de tâche sera envoyé
au manager une fois que le contractant l’ait
terminé. Notons que le protocole exige du
manager de savoir le moment où il a reçu
toutes les réponses. Une date limite de
réception des offres sera précisée et toutes
les réponses reçues après cette date seront
automatiquement rejetées en se justifiant
par le fait que la proposition était tardive.
Le protocole FIPA-Iterated-contractnet :
C’est une extension du protocole
précédent. Il diffère de la version de base
en permettant plusieurs itérations. Une fois
que l’agent manager reçoit les propositions
des contractants, il peut accepter une ou
plusieurs offres, rejeter d’autres ou peut
réitérer le processus en émettant une
nouvelle offre ‘révisée’. L’objectif est de
permettre au manager d’obtenir de
meilleures offres des contractants en
modifiant l’appel et en demandant de
nouvelles
offres
(d’une
manière
équivalente mais révisée). Le processus
termine quand le manager refuse toutes les
propositions, n’émet pas de nouveaux
appels en acceptant la meilleure offre de
l’itération antérieure ou tout simplement
lorsque les contractants refusent de faire
des offres.
d’autres domaines, d’autres règles peuvent
éventuellement s’appliquer.
Le modèle du General Magic
Le protocole FIPA-Auction-English :
Dans l’enchère anglaise, le manager
cherche à trouver le prix du marché d’une
marchandise en proposant initialement un
prix au-dessous de celui de la valeur de la
marchande supposée, et en augmentant
alors graduellement le prix. Chaque fois
que le prix est annoncé, le manager attend
des acheteurs pour signaler leur accord sur
le prix proposé. Dès qu’un acheteur
indique qu’il accepte le prix, le manager
émet un nouvel appel d’offres avec un prix
légèrement supérieur. L’enchère continue
jusqu’à ce qu’aucun acheteur ne soit
disposé à payer le prix proposé, auquel cas
l’enchère termine. Si le dernier prix qui a
été reçu par un acheteur excède un prix de
réserve (connu en privé par le manager), la
marchandise est vendue à cet acheteur pour
le prix convenu. Sinon la vente est annulée.
Le protocole FIPA-Auction-English :
Dans l’enchère hollandaise, les tentatives
du manager de trouver le prix de vente
d’une marchandise se concrétisent en
commençant par un prix beaucoup plus
haut que la valeur prévue, puis en réduisant
progressivement le prix jusqu’à ce qu’un
des acheteurs accepte le prix. Le manager a
habituellement un prix de réserve au
dessous duquel il ne vend pas. Si l’enchère
ramène le prix de la marchandise au prix
de réserve sans qu’il ait d’acheteurs,
l’enchère se termine. Dans cette enchère, la
marchandise peut être vendue en plusieurs
parties,
quelques marchés obligent
d’acheter la marchandise toute entière.
Dans le cas des agents, il est tout à fait
possible que deux offres identiques ou plus
soient reçus par le manager pour la même
marchandise. Il n’est pas considéré dans la
spécification de FIPA un mécanisme
particulier pour résoudre ce conflit. Dans le
cas général, les agents devraient appliquer
‘du premier venu, premier servi’. Dans
Ce modèle présente les concepts
des systèmes multi agents comme une
place de marché électronique où les
fournisseurs et les consommateurs des
services se trouvent et accomplissent leur
travail. Quelques places du marché sont
modélisées comme un réseau des
ordinateurs représentant un ensemble de
places qui offrent des services aux agents
mobiles [White, 1997]. Ce modèle
introduit la notion de place dans un
environnement distribué et il est
explicitement destiné à supporter la
mobilité des agents.
Le modèle de KAoS
Ce modèle était conçu dans le but
d’assurer une architecture ouverte et
distribuée des agents logiciels [Bradshaw
et al, 1997]. Une des caractéristiques
importantes de cette architecture est qu’elle
développe les actions de conversation
comme un protocole représentant les
interactions dynamiques des agents. Le
modèle KAoS introduit la notion du
domaine pour un agent et la notion de
domaine pour les managers. Le domaine
pour un agent représente les limites de
l’activité de l’agent. Le domaine des
managers permet de contrôler l’entrée et la
sortie des autres agents dans son domaine.
KAoS définit également les notions des
proxies et des médiateurs qui permettent
l’intercommunication entre des agents
KAoS et des agents non KAoS. KAoS
définit encore une structure d’agent
incluant les mécanismes pour gérer les
faits, les croyances, les désirs, les
intentions et les capacités des agents.
Le modèle de l’OMG
Le modèle de l’OMG représente un
environnement d’agents consistant en des
composant (les agents) et des localités (les
agences) [Virdhagriswaram et al, 1995] où
les agents et les agences peuvent interagir
avec d’autres agents et agences en utilisant
des politiques prédéfinies d’interaction.
Dans ce modèle, on classe les
agents suivant leurs capacités (par
exemple, leurs capacités de déduire des
faits, de planifier,..), le type supporté des
interactions avec les autres agents (par
exemple les données, la sémantique des
demandes,..), la mobilité (par exemple, la
mobilité statique, la mobilité avec ou sans
état,..).
Les
agences,
d’autre
part,
permettent de supporter entre autre
l’exécution concurrente des agents, la
sécurité et la mobilité des agents. Les
agents dans le modèle OMG peuvent
communiquer
suivant
plusieurs
cardinalités, à savoir, 1-1, 1-n et n-n.
La trousse à outils de BT Labs
ZEUS
Développée aux laboratoires de
British Telecom. Elle implémente une
application rapide de développement des
systèmes multi agents dans un domaine
orienté vers des tâches [Nwana et al,
1999]. Elle consiste en un ensemble des
trois composants :
• une librairie des composants d’agents,
• un outil de développement des agents,
et
• une suite des utilités pour les agents.
La librairie des composants d’agents
fournit un certain niveau de fonctionnalité
des agents tel la communication, le
raisonnement, et la planification.
L’outil de développement des agents
supporte la création interactive des agents
en visualisant leurs attributs.
La suite des utilités pour les agents
consiste en un agent fournissant le service
des pages blanches, un autre fournissant le
service des pages jaunes, et un autre agent
pour déboguer les agents ZEUS.
L’outil ZEUS comprend une architecture
pour des agents génériques ainsi qu’un
interface
graphique
représentant
l’environnement
et
permettant
le
développement des systèmes multi agents.
Le modèle de l’université de Calgary
L’objectif principal de ce modèle
est de définir une architecture logicielle
ouverte
fournissant
une
structure
permettant aux agents la possibilité de
contacter ou d’être contacté par d’autres
agents [Flores et al, 1999]. Afin de
permettre aux agents de se communiquer,
les agents ont besoin de 4 conditions qui
devraient être valides dans le sens direct et
le sens réversible. Les agents ont besoin
alors (C1) d’être inscrit comme des
participants actives dans l’architecture,
(C2) d’annoncer leurs services (s’ils
veulent être contactés), (C3) de demander
aux autres agents leurs services annoncés
(s’ils veulent les contacter) et (C4) d’être
capable de communiquer simultanément
avec plusieurs agents.
Les notions de la surface et de
coordinateur local de surface sont alors
définies. Le premier aspect comporte deux
notions : la limite de surface représentant
une fonction de ressources informatiques
disponibles pour l’agent, et la résidence
d’agent représentant la résidence dans une
surface une fois que l’agent réussit à
s’inscrire chez le coordinateur local de
surface.
Le coordinateur local de surface est un
agent qui alloue aux autres agents des
surfaces de résidence.
Les protocoles définis sont :
Registration Protocol : permet de
s’inscrire ou de se désinscrire d’une
surface.
YP Locations : pour faire des demandes
concernant les agents pages jaunes connus.
Advertisement : pour annoncer ou retirer
une annonce pour un service.
Search : pour demander un service
annoncé.
Cooperation Domain Subscription :
pour joindre ou se retirer d’un domaine de
coopération.
Cooperation Domain Invitation : pour
inviter un agent à joindre un domaine de
coopération.
Cool
(COOrdination
Language)
[Barbuceanu, 1995] : un exemple de
protocole d’interaction
COOL est un langage de description des
protocoles de coordination. Il utilise
KQML comme langage de communication
entre les agents.
On distingue plusieurs niveaux dans les
interactions entre les agents :
• Le premier niveau concerne le
contenu de l’interaction. Ce niveau
est abordé par les ontologies KIF
[Genesereth et Fikes, 1992].
• Le deuxième niveau spécifie les
intentions des agents. Ce niveau est
abordé par le langage KQML.
• Le troisième niveau spécifie les
conventions de l’interaction. Ce
niveau est abordé par un langage de
coordination COOL.
• Le quatrième niveau concerne la
modélisation de l’interaction. Ce
niveau est abordé par les automates
d’états finis.
On représente par les automates d’états
finis :
• Les états : ce sont les états
possibles du déroulement d’une
conversation (état accord, état
refusé)
• Les transitions : ce sont les
messages ou les performatifs
possibles.
On définit des règles de conversation
permettent de spécifier la réaction d’un
agent, c'est-à-dire l’action à réaliser, dans
un état donné. On représente alors :
• Les règles de conversation :
déterminent comment un agent doit
répondre aux différents messages
reçus, ce qu’il doit faire et quand.
• Les règles de reprise d’erreurs :
déterminent les réactions en cas
d’erreur.
• Les règles de poursuite :
déterminent l’enchaînement des
conversations.
Des classes de conservation permettent de
définir un plan de dialogue spécifiant les
états, les règles de conversation, et les
règles de reprise d’erreurs spécifiques à
chaque type de conversation.
Une instance de cette classe sera créée dès
qu’un agent débute ou entre dans une réelle
conversation. Un identificateur sera
également crée pour l’y associer.
Une conversation peut être interrompue à
tout moment s’il manque l’agent le temps,
l’information ou s’il doit corriger une
erreur. L’agent peut interrompre une
conversation pour en terminer une autre.
On note qu’un agent peut avoir plusieurs
classes de conversations dépendamment
des agents avec lesquels il sera possible de
se communiquer.
Le schéma ci-dessus présente un exemple
de protocole de négociation. La notation
<Message reçu>/<Message émis> est
utilisé pour modéliser les transitions entre
les différents états. L’état 1 représente
l’état initial et les états 5, 6 et 7
représentent les états finaux.
La conversation commence lorsqu’un
agent reçoit un message, on est alors dans
l’état 1. S’il s’agit d’une demande, l’agent
sera dans l’état 2. Il peut accepter (état 3),
rejeter (état 2) ou proposer une autre
demande révisée (état 4). S’il accepte la
demande, on est dans l’état 3. S’il satisfait
à la demande, on est dans l’état 6, sinon on
est dans l’état 7.
1
6
/satisfy
propose /
7
2
/accept
/fail
/reject
3
/counter
5
counter/
reject/
accept/accept
4
Exemple de protocole de négociation
Conclusion
Les
protocoles
d’interaction
permettent de contrôler les différentes
formes existantes d’interaction entre les
agents ; toutefois, il n’existe pas à l’heure
actuelle d’outils pour aider à la conception
et à la validation de ces protocoles.
Le projet de téléenseignement
Baghera [Huget, 2000] introduit une plate
forme pour l’ingénierie des protocoles.
Cette plate forme est composée
essentiellement de deux outils. L’un
intervient dans la phase de conception et
l’autre dans la phase de validation.
D’autre part, les perspectives de
recherche sur les interactions portera sur la
réutilisabilité
des
schémas
de
communication d’agents [Deugo et al.,
2001], de bibliothèques d’interactions
[FIPA, 2001] ou de modules de
communication [Shehory et al., 00]. Plus
précisément sur la définition dynamique
des interactions [Berger, 2001], une
définition qui n’est pas présent dans les
approches citées.
Bibliographie
[Barbuceanu, 1995]
Barbuceanu M., Fox M.S. COOL : a
language for describing coordination in
multi-agent systems. ICMAS, p. 17-24,
1995.
[Berger, 2001]
Berger L., Mise en œuvre des interactions
en environnements distribués, compilés et
fortement typés : Le modèle MICADO.
2001.
[Bradshaw et al., 1997]
Bradshaw J.M., Dutfield S., Benoit P. et
Woolley J.D. KAoS : Toward An Industrial
Strength Open Agent Architecture.
Software Agents, Bradshaw, J.M. (Ed.),
AAAI Press, Menlo Park, CA, p. 375-418,
1997.
[Deugo et al., 2001]
Deugo D., Weiss M., Kendall E., Reusable
Patterns for agent Coordiantion. Omicini
A, Zambonelli F., Klusch M., Tolksdorf
R., Eds., Coordination of Internet Agents :
Models, technologies, and Applications,
chapitre 14, p. 347-368, Springer-Verlag,
March 2001.
[Durfee et Montogomery, 1990]
Durfee E.H. et montogomery T.A. A
Hierarchical protocol for Coordinating
MultiAgent Behaviours. In Proc. AAAI-90,
1990.
[Genesereth et Fikes, 1992]
Genesereth M.R. et Fikes R.E. Knowledge
Interchange Format. Version 3, Reference
Manual, Computer Science Dept., Stanford
University, Technical report Logic-92-1.
1992.
[Ferber, 1995]
Ferber J. Les systèmes multi agents : Vers
une intelligence collective. InterEditions.
1995.
[FIPA, 1997a]
Foundation for Intelligent Physical Agent.
Part 1 : Agent Management. Version 1.2.
1997.
[FIPA, 2000]
Foundation for Intelligent Physical Agent.
FIPA Interaction Protocol Library
Specification.http://www.fipa.org/specs/fip
a00025/, 2000.
[FIPA, 2000]
Foundation for Intelligent Physical Agent.
FIPA Request Interaction Protocol Library
Specification.http://www.fipa.org/specs/fip
a00026/, 2000.
[FIPA, 2000]
Foundation for Intelligent Physical Agent.
FIPA Query Interaction Protocol Library
Specification.http://www.fipa.org/specs/fip
a00027/, 2000.
[FIPA, 2000]
Foundation for Intelligent Physical Agent.
FIPA
Request
When
Interaction
Protocol
Library
Specification.
http://www.fipa.org/specs/fipa00028/,
2000.
[FIPA, 2000]
Foundation for Intelligent Physical Agent.
FIPA Contract Net Interaction Protocol
Library Specification.
http://www.fipa.org/specs/fipa00029/,
2000.
[FIPA, 2000]
Foundation for Intelligent Physical Agent.
FIPA Iterated Contract Net Interaction
Protocol Library Specification.
http://www.fipa.org/specs/fipa00030/,
2000.
[FIPA, 2000]
Foundation for Intelligent Physical Agent.
FIPA English Auction Interaction Protocol
Library specification.
http://www.fipa.org/specs/fipa00031/,
2000.
[FIPA, 2000]
Foundation for Intelligent Physical Agent.
FIPA Dutch Auction Interaction Protocol
Library specification.
http://www.fipa.org/specs/fipa00032/,
2000.
[FIPA, 2001]
Foundation for Intelligent Physical Agent.
FIPA
Communicative
Act
Library
Specification.
http://www.fipa.org/specs/fipa00037/,
2001.
[Flores, 1999]
Flores, R.A. et Wijngaards, N. J.E.
Primitive Interaction Protocols for Agents
in a Dynamic Environment. in B.R.
Gaines, R.C. Kremer & M. Musen (Eds.),
Proceedings of the 12th Workshop on
Knowledge Acquisition, Modelling and
Management (KAW '99), Banff, Canada,
October 16-21, Volume 1, p. 3-2-1:3-2-20,
1999.
[Huget et al, 2000]
Huget M.P., Koning J.L., Bergia L. Une
plate forme pour l’ingénierie des
protocoles d’interaction. Application au
projet de télé-enseignement Baghera. 1ère
soumission à JFIADSMA, juillet 2000.
[Jenings, 1993]
Jenings
J.R.
Commitments
and
Conventions :
The
foundation
of
coordination in multi-agent systems. The
knowledge Engineering review, 2(3) :
pages 223-250, 1993.
[Mazouzi, 2001]
Mazouzi H. Ingénierie des protocoles
d’interaction : des systèmes distribués aux
systèmes multi agents. 2001.
[Nwana et al., 1999]
Nawan H., Ndumu D., Lee L. et Colis J.
ZEUS : a tool-kit for building distributed
Multi-Agent Systems. Applied Artificial
Intelligence Journal, Volume 13 (1), p.
129-186, 1999.
[Shehory et al., 2000]
Shehory O., Sycara K., The Retsina
Communicator, Autonomous Agents 2000,
Poster Session 2000.
[Smith, 1980]
Smith R.G. The Contract Net Protocol :
High Level Communication and Control in
a Distributed Problem Solver. IEEE trans.
On Computers, Vol. 29 (12), Pages 11041113, 1980.
[Virdhagriswaram et al., 1995]
Virdhagriswaram S., Osisek D., et
O’Connor P.
Standardizing
Agent
Technology. ACM Standard View, Volume
3, Number 3, p. 96-101, 1995.
[White, 1997]
White J.E. Mobile Agents. Software
Agents. Bradshaw, J.M. (Ed.), AAAI
Press, Menlo Park, CA, p. 437-472, 1997.