3.4.3
Langage de communication entre agents
Le ACL (Agent Communication Language) a été
créé par ARPA pour assurer l'interopérabilité entre
des agents autonomes et distribués. Le ACL a trois composants : un
vocabulaire, un langage de communication entre agent appelé KQML
(Knowledge and Query Manipulation Language) et un langage spécifiant le
contenu appelé KIF (Knowledge Interchange Format). Un message de ACL est
alors un message KQML contenant une directive de communication et un contenu
sémantique dans KIF, exprimé en termes de vocabulaire.
KQML fournit la couche linguistique pour rendre la
communication efficace en considérant le contexte des messages. Il a
été conçu comme format de message et comme protocole qui
permet l'identification, le raccordement et l'échange de l'information
entre des programmes. Selon [Finin et al. 95], KQML est
caractérisé par trois caractéristiques importantes :
1.
Les messages KQML sont opaques au contenu qu'ils transportent,
ce qui implique que les messages KQML ne communiquent qu'avec des sentences en
certain langage, mais aussi une attitude ou à une intention sur le
contenu.
2.
Des primitifs s'appellent performatives indiquent les actions ou
les opérations valides.
3.
Un environnement dans lequel les agents communiquent avec KQML
peut être enrichi avec un genre spécial d'agents appelés
les facilitateurs.
3.4.3.1
Le langage KQML
Le langage KQML (Knowledge Query Manipulation Language) a
été conçu comme format de message pour supporter la
communication entre agents. Les caractéristiques principales de KQML
sont les suivantes :
·
Les messages KQML sont opaques au contenu qu'ils portent. Les
messages KQML ne communiquent pas simplement des phrases en un certain langage,
mais communiquent plutôt une attitude au sujet du contenu (affirmation,
requête, réponse, etc.).
·
Les primitifs du langage s'appellent performatives (ces termes
vient directement de la théorie d'acte de langage). Les performatifs
définissent les actions (opérations) permises utilisées
par des agents communiquant entre eux.
·
KQML suppose qu'au niveau d'agent, la communication point
à point.
·
Un environnement dans lequel les agents communiquent avec KQML
peut être enrichi avec un genre spécial d'agents appelés
les facilitateurs, qui fournissent aux fonctions additionnelles d'agents la
gestion de réseau, telle que l'association des adresses physiques en
noms symboliques, registration des agents, etc.
KQML utilise un ensemble de types de messages standards. Un
exemple est comme suit :
(ask-one
:content (PRICE IBM ?price)
:receiver stock-server
:language LPROLOG
:ontology myOntology )
Dans la terminologie de KQML, "ask-one" est un performatif.
Les paramètres de performatif sont présentés par des
mots-clés tels que "sender", "language", etc. Le message ci-dessus
représente une question au sujet du prix d'un stock partagé
d'IBM. Ontology assumé par la question est l'identification par
"myOntology", le récepteur du message est "stock-server" et le langage
utilisé est "LPROLOG".
Les types de messages KQML sont de diverses natures :
·
Simples requêtes et assertions, tel que : ask, tell, ...
·
Instructions de routage de l'information, tel que forward,
broadcast, ...
·
Commandes persistantes, tel que subscribe, monitor, ...
·
Commandes permettent aux agents consommateurs de demander
à des agents intermédiaires de trouver les agents fournisseurs
pertinents, tel que advertise, recommend, ...
3.4.4
Protocole d'interaction entre agents
Un système multi-agents peut être
considéré comme société artificielle virtuelle,
dans laquelle les agents peuvent coopérer ou coordonner pour accomplir
des tâches. L'interaction entre agent exige un ensemble de messages
convenus, de règles pour des actions basées sur la
réception de divers messages, et d'acceptations des voies de
transmission [Chen et al 03]. Ces contraintes, règles et modèles
peuvent être soustraits et formalisés comme AIP (Agent
Interaction Protocol), qui font base de la négociation et la
coopération d'agents. En utilisant les protocoles, les comportements
autonomes des agents peuvent être de façon ou d'autre
prévisibles.
L'AIP sont des modèles représentant les messages
de communication et les contraintes correspondantes sur le contenu de tels
messages. Ils décrivent un ordre permis des messages et du contenu de
message entre les agents [Odell et al 00]. L'AIP peut également
être considéré en tant que modèles
réutilisables de conception de logiciel décrivant des
problèmes se produisant fréquemment dans les systèmes
multi-agents [Bauer et al 00]. Les rôles et les détails de
messages dans un AIP peuvent être modifiés pour s'adapter
à différents scénarios pour résoudre des
problèmes [Inverno et al 98].
3.4.5
Transport de messages
La communication entre agents est nécessaire aussi bien
pour échanger les données entre les agents que les connaissances.
Pour cela, plusieurs moyens existent : au niveau le plus bas, il existe des
sockets qui permettent aux différents agents codés en
Java de communiquer entre eux ; il existe aussi d'autres technologies (en Java
notamment). On peut citer l'invocation de méthodes distantes (RMI pour
Remote Method Invocation) et la technologie CORBA (Common Request
Broker Architecture).
Plusieurs travaux concernent la mise en oeuvre
d'infrastructures de communication qui dispensent le programmeur
d'implémenter lui-même la communication entre les agents. Avec ce
type d'outils, le fonctionnement typique consiste à fournir une adresse
à chaque agent. Cette adresse lui permettra d'émettre et de
recevoir des messages de la part des autres agents. L'avantage est la
possibilité d'avoir des communications asynchrones et d'être
dispensé de la nécessité de localiser un agent avant de
lui envoyer un message. JATLite est une infrastructure de ce type, elle permet
aux agents de communiquer via Internet.
3.4.5.1
Sockets, RMI et CORBA
3.4.5.1.1
Sockets
Une socket est une abstraction de programmation
représentant les extrémités d'une connexion entre deux
ordinateurs. Pour chaque connexion donnée, il existe une socket
sur chaque machine, on peut imaginer un câble virtuel reliant les
deux ordinateurs, chaque extrémité étant enfichée
dans une socket. En Java, on crée un objet Socket pour
établir une connexion vers une autre machine, puis on crée un
InputStream et un OutputStream à partir de ce
Socket, afin de traiter la connexion en tant qu'objet flux
d'entrée/sortie.
3.4.5.1.2
RMI
L'invocation de méthodes distantes se base sur le
raisonnement selon lequel la meilleure manière d'exécuter des
instructions à travers un réseau sur d'autres ordinateurs est de
considérer qu'un objet est présent sur une autre machine et qu'on
lui envoie un message et l'on obtient le résultat comme si cet objet
était instancié sur la machine locale. L'invocation de
méthodes distantes exige de créer une interface distante
(remote interface) sur la machine serveur ; ainsi,
l'implémentation sous-jacente est masquée aux différents
clients. Les étapes suivantes de la création des objets RMI sont
l'implémentation de l'interface distante, la mise en place du registre,
la création des stubs et des skeletons qui assurent
les opérations de connexion réseau et permettent de donner
l'illusion que l'objet distant est situé sur la machine locale.
L'utilisation de l'objet distant consiste simplement pour le programme client
à rechercher et à rapatrier depuis le serveur, l'interface
distante.
3.4.5.1.3
CORBA
Lorsque les applications distribuées deviennent plus
importantes et exigent des fonctionnalités telles que
l'intégration de bases de données existantes ou l'accès
aux services d'un objet serveur sans se soucier de sa localisation physique, on
a besoin d'effectuer des appels à des procédures distantes ou RPC
(Remote Procedure Call) et il peut être nécessaire
d'avoir une indépendance par rapport au langage. Dans ces cas, il est
nécessaire de recourir à une technologie d'intégration
comme CORBA. Il s'agit d'une spécification que les fabricants peuvent
suivre afin d'implémenter des produits supportant une intégration
CORBA. La norme CORBA fait partie du travail réalisé par l'OMG
(Object Management Group) pour définir des standards
d'interopérabilité des objets distribués et
indépendants du langage. Elle fournit la possibilité de faire des
appels à des procédures distantes dans des objets Java et
non-Java, d'interfacer des systèmes existants sans se soucier de leur
emplacement. La spécification de l'interopérabilité objet
est généralement désignée comme l'Object
Manager Architecture (OMA). L'OMA définit deux composants : le
Core Object Model et l'OMA Reference Architecture. CORBA est
un raffinement du Core Object Model dans ce sens qu'il met en place
les concepts de base d'objet, d'interface, d'opération, etc. L'OMA
ReferenceArchitecture définit les services et les mécanismes
qui permettent aux objets d'inter-opérer, il contient l'Object
Request Broker (ORB), les services CORBA et les outils communs. L'ORB est
le bus de communication par lequel les objets peuvent réclamer des
services auprès des autres objets, sans rien connaître de leur
localisation physique. La norme CORBA n'a pas pour but d'expliquer comment
implémenter les ORB, mais permet une compatibilité entre les
différents ORB des fournisseurs. Ainsi, l'OMG définit un ensemble
de services qui sont accessibles par l'intermédiaire d'interfaces
standard. Afin d'assurer l'indépendance vis-à-vis du langage,
CORBA dispose d'un langage de définition d'interface, IDL (Interface
Definition Language), qui précise les types de données, les
attributs, les opérations, les interfaces, etc. Le compilateur IDL
génère le code stub et le code skeleton
utilisés pour réunir les arguments des méthodes et
réaliser les appels distants. En résumé, on pourrait dire
que CORBA est le support de RPC, qui permet à des objets locaux
d'appeler des méthodes d'objets distants. Cette fonctionnalité
est intégrée à Java à travers les RMI ; toutefois,
là où le RMI rend possible les RPC entre des objets Java, CORBA
le fait entre des objets implémentés dans n'importe quel langage.
3.4.5.2
Plateformes agents Conformes à KQML
Il est difficile d'implémenter et déboguer des
systèmes multi-agents à partir du zéro. Cependant, il y a
un certain nombres des réalisations des infrastructures d'agents
basées sur KQML actuellement disponibles. Dans le suivant nous
présentons brièvement quelques unes d'elles.
Java Agent Template, Lite (JATLite),
développé à l'université de Stanford, est un
package des programmes Java qui permettent à des utilisateurs de
créer des agents logiciels qui communiquent à travers l'Internet.
JATLite facilite particulièrement la construction des agents qui
envoient et reçoivent des messages en utilisant le langage de
communication KQML.
L'architecture de JATLite, comme représentée sur
la Figure 2.1, est organisée comme hiérarchie des couches de plus
en plus spécialisées, de sorte que les réalisateurs
puissent choisir la couche appropriée pour commencer à
développer leurs systèmes.
·
La couche abstraite fournit un ensemble de classes abstraites
nécessaires à l'implémentation de JATLite.
·
La couche de base fournit des communications TCP/IP et donne
accès à la couche abstraite.
·
La couche KQML fournit le stockage et l'analyse des messages
KQML. Des extensions au KQML standard proposées par l'Université
de Stanford [Pietrie, 03] ont été implémentées afin
de permettre un protocole standard pour l'inscription, la connexion, la
déconnexion, etc.
·
La couche de routage offre aux agents l'inscription, le routage
et la mise en file des messages.
·
La couche de protocoles supporte différents protocoles et
services Internet comme SMTP, FTP, POP3, HTTP.
Magenta, développé à
l'université de Stanford, est un ensemble d'API (Application Processing
Interface) pour le langage de communication entre d'agents. Il facilite la
communication entre des agents situés dans un environnement de calcul
hétérogène. Bien que les utilisateurs de l'API puissent
communiquer de pair à pair, l'API est particulièrement utile pour
l'interaction anonyme d'agents.
JKQML (Java-based Knowledge Query
Manipulation Language), développée à IBM, est un framework
et API pour construire des programmes basés Java communicant par KQML
à travers l'Internet. JKQML permet l'échange d'information et de
services entre les systèmes logiciels.
| 
