Notons bien que l'agent stationnaire s'exécute seulement
sur la machine où il est créé. Si jamais il a besoin
d'informations supplémentaires inexistantes localement ou d'interagir
avec
d'autres agents dans différents systèmes, alors
il utilise typiquement le mécanisme RPC (Remote Procedure Calling) qui
est une méthode appliquée dans le modèle client
serveur.
Par contre, Un agent mobile est un processus autonome
contenant du code et des données, capables de se déplacer d'une
machine à une autre afin de réaliser une tâche
précise. Ce code représente l'ensemble des instructions du
programme, et les données sont constituées soit du
véritable contexte d'exécution du programme, soit de variables
émulant ce contexte. Un contexte d'exécution est composé
de la pile de récursivité, du tas et des registres. Ce contexte
évolue au cours de la vie de l'agent.
Le choix d'employer des agents stationnaires ou mobiles dans
un système, dépend non seulement de la nature technique et
conceptuelle de l'agent mais aussi du contexte où il est prévu
d'être employé.
Dans le cas d'un système à agents
stationnaires, on se pose qu'un agent veut accéder à une base de
données distante, dans ce cas l'interaction avec la base se fait
à travers le réseau comme il est indiqué dans la figure
1.1.
Utilisateur A
Site A
Agent A
Site B
BD
Figure 1.1 : Interaction à travers le réseau.
Autrement, dans le cas des agents mobiles, supposons que
l'utilisateur A veuille récupérer des informations sur un certain
sujet. En interagissant avec son agent personnel, la requête est
formellement spécifiée. Ceci est illustré par la
figure1.2.
Site A
Utilisateur A
Agent A
Site B
BD
Figure 1.2 Migration (phase 1).
Puis, comme le montre la figure 1.3, l'agent migre du site A au
site B sur laquelle se trouve une base de données contenant les
informations recherchées.
Site A
Site B
Utilisateur A
Agent A
Agent A
BD
Figure 1.3 Migration (phase 2).
Ensuite, La figure1.4 montre l'agent interagissant avec la base
de données du site distant pour récupérer les
données recherchées.
Figure 1.4 Migration (phase 3).
Utilisateur A
Site A
Agent A
Site B
BD
Puis, une fois l'agent satisfait, il retourne vers le site
d'origine. Ceci est illustré par la figure1.5.
Utilisateur A
Site A
Agent A
Agent A
Site B
BD
Figure 1.5 Migration (phase 4).
Finalement, comme le montre la figure1.6, l'agent rapporte -
d'une manière interactive - les résultats à son
utilisateur.
Site A
Utilisateur A
Agent A
Site B
BD
Figure 1.6 Migration (phase 5).
Dans le plus part des applications, les systèmes
à agents mobiles semblent être plus efficaces que les
systèmes classiques à agents stationnaires, car dans un
système informatique, les interactions intra-site sont moins
coûteuses que les interactions inter-sites, mais ceci n'est pas toujours
vrai, car on peut avoir une négociation entre agents statiques et
même entre agents mobiles dans un système et aussi lorsque il
s'agit du coût de migration, etc.
Prenons un exemple explicatif sur les deux approches à
agents mobiles et à agents statiques.
Dans la première phase de l'approche « agents
mobiles » de cet exemple, l'utilisateur et l'agent établissent la
requête. Supposons qu'elle ait une taille de r octets. Puis l'agent migre
vers le site B. Supposons que la taille de l'agent soit fixe à a octets.
L'agent interagit avec la base de données dont la taille est de b
octets. Finalement, l'agent rentre pour communiquer la solution composée
de s octets. Donc, la quantité totale de données
transférées entre les sites différents est (a + r) + (a +
s) octets. Notons qu'il n'est pas toujours nécessaire qu'un agent
retourne chez son utilisateur et que - souvent - il suffit qu'il envoie le
résultat. Toutefois, en général, on suppose que l'agent
rentre.
Par contre dans l'approche classique de cet exemple,
utilisant un agent statique, la quantité totale de données
transférées peut monter jusqu'à r + b octets. En effet,
dans le pire des cas, on demande le transfert de la base complète et on
la traite localement.
Comparons les deux approches, en supposant que r est
négligeable. Le graphique 1 (Figure 1.7) montre le nombre d'octets
transférés, dans les deux approches, pour b = 100000, a = 5000
et s / b entre 0et 1. Le graphique 2 visualise la même
relation, mais pour a = 25000 (Figure 1.8).
Figure 1.7 Graphique1 : Agents statiques vs. agents mobiles (a =
5000)
Figure 1.8 Graphique 2 : Agents statiques vs. agents mobiles (a =
25000).
Donc, et comme le montrent les deux graphiques, l'application
des agents mobiles n'est pas toujours avantageuse. Surtout lorsque les tailles
des agents et des solutions (relatives à la base de données) sont
grandes, l'approche classique est préférable. Cependant, en
général, la taille des agents et le ratio s / b sont modestes, et
la mobilité prometteuse.
Par contre, ce raisonnement n'est valide que si la
requête ne peut pas être formulée d'une
telle manière qu'elle peut être traitée
directement pas le système de gestion de la base de données. Dans
ce cas, il suffit d'envoyer la requête et de recevoir la solution sans
impliquer des agents. Cette solution est toujours la plus économique car
seulement r + s octets doivent être transférés. Donc, cette
application très étudiée des agents mobiles n'apporte
aucun avantage si les requêtes peuvent être normalisées pour
les bases de données impliquées. Ceci est sans doute une des
raisons principales pour laquelle les agents mobiles ne sont pas encore
utilisés à une échelle importante ainsi que les agents
statiques sont encore employés par les développeurs dans ce
domaine.
Toutefois, dans un monde informatique de plus en plus
sophistiqué et personnalisé, nous pouvons nous attendre à
une croissance importante de requête non standard. De plus, il est
possible que certains utilisateurs préféreront envoyer leurs
agents personnels plutôt que faire confiance au système de gestion
distant, en estimant - par exemple - que leurs agents sont plus fiables.
Pour cette raison, les chercheurs sont dirigés vers le
développement des applications en intervenant des agents
coopératifs stationnaires et mobiles, dont leurs tâches sont
définies après avoir calculé les performances en fonction
des besoins de l'application.
