Xml - Java Tomcat Guide - Page Frontière du Site d`Arnaud Valeix

Février, mars, avril, mai 2002 – Stage informatique
Création d’une librairie de Balises
pour l’insertion d’agents JADE
dans des pages Jsp
Olivier Fourdrinoy
Maîtrise d’informatique, Faculté Jean Perrin, Université d’Artois, Lens.
2
Introduction
Plus j’apprends de choses en informatique et moins j’ai l’impression d’en
savoir. Ce domaine est à mes yeux un dédale gigantesque où chaque porte
s’ouvre sur un couloir comportant lui même une quantité astronomique de
portes. Le but de ce rapport n’est donc pas de faire l’inventaire de tout ce que
j’ai vu ou aperçu derrière la porte de ce stage mais simplement de donner des
clés qui en faciliteront l’ouverture.
Alors pour reprendre l’idée d’une très célèbre collection du monde de
l’informatique, ce rapport a pour but secret d’intéresser à la fois les profanes
et les initiés avec une approche d’abord légère puis plus approfondie des
domaines étudiés.
La première partie de ce rapport - la plus importante - sera consacrée aux différents
domaines, outils ou autres langages étudiés.
Dans la seconde partie, je traiterai du projet lui-même, en partant de l’idée de départ
jusqu’à son état final avec une évocation des évolutions souhaitables ou souhaitées.
Enfin, la troisième partie, approche plus subjective du stage, essaiera de dégager
l’expérience acquise, de revenir sur les erreurs ou sur les réussites, en somme il
s’agira d’une relecture de la méthode de travail.
Bonne lecture, en espérant que vous en saurez d’avantage sur les agents ou
les Jsp (ou les deux) après avoir lu ce rapport.
3
Sommaire
Introduction
Les Outils et Langages
Les agents
Le projet Jade
Les Java Server Pages
Les taglibs
Le projet
Le sujet
La structure de la bibliothèque de balises
Un exemple d’utilisation
Expériences acquises lors du stage
Un projet basé sur différentes technologies
Les exemples plutôt que la théorie
Annexes
Le code
Le glossaire
4
Les Outils et Langages
Les agents
« Les agents pour les nuls »
Je vais ici essayer d'expliquer ce qu'est un agent. Pour cela, permettez moi de vous
parler de ma famille :
J'ai un petit cousin qui a un tamagoshi (vous savez ces petites "bêtes" électroniques
qui nous envahissent depuis un petit moment). Eh bien, le tamagoshi, animal
autonome fort sympathique, quand il a faim il sonne : Il envoie un message à mon
cousin pour lui dire qu'il a faim. Mon cousin appuie alors sur le bouton Petit Lo (il a
gagné son tamagoshi en mangeant des Petits Lo) pour lui donner à manger : Il
donne en réponse au message du tamagoshi des Petits Lo.
Mais comme tout le monde le sait, les Petits Lo ça donne soif ! C'est pourquoi
quelques secondes plus tard, le tamagoshi sonne car il a soif. Là, mon cousin a le
choix : Eau ou jus d'orange. Il appuie sur le bouton jus d'orange et là le tamagoshi se
met à sonner encore plus fort : Il refuse le jus d'orange. Mon cousin lui donne alors
de l'eau et le tamagoshi la boit. L'animal n'a plus sonné pendant au moins une heure
car, c'est bien connu, après avoir mangé et bu les tamagoshi font la sieste.
Et nos agents dans tout ça ! Et bien, si l'on compare notre tamagoshi à un agent, et
que l'on reprend les mots en gras, on retient qu'un agent est :
-
une entité autonome mais fortement dépendante des autres (c'est le
tamagoshi)
-
un agent communique à l'aide de messages (des bips pour le tamagoshi, des
boutons pour mon cousin)
-
un agent est autonome, il peut refuser de faire ce qu'on lui dit de faire (ici, il
refuse de boire du jus d'orange).
5
Comment communiquent les agents ?
Mon cousin a gagné son tamagoshi en mangeant des Petits Lo, et comme il
en mange beaucoup, il en a gagné beaucoup : une trentaine !
Bine sur il ne peut pas s’en occuper tout seul, alors ma cousine l'aide. Ainsi
quand un tamagoshi sonne, il ne sait pas qui va s'occuper de lui : mon cousin
ou ma cousine.
C'est important : le tamagoshi qui a besoin de quelque chose envoie un
message à son entourage et il attend que quelqu'un s'occupe de lui. Il ne sait
pas, a priori, qui va répondre à son message : mon cousin ou ma cousine ou
peut être personne... Par contre lorsque mon cousin ou ma cousine répondent
à un tamagoshi, ils répondent uniquement au tamagoshi qui a sonné, c'est à
dire qu'ils envoient un message au bon tamagoshi.
Comme les tamagoshis, les agents communiquent en envoyant des
messages. Ils peuvent envoyer principalement des messages de deux types:
-
un message à plusieurs autres agents (mon cousin ou ma cousine), par
exemple pour signaler ou demander quelque chose.
-
un message à un seul agent, par exemple pour répondre à une question.
Les agents vivent en communauté !
En réfléchissant un peu, mon cousin eu l'idée de ne plus avoir des
tamagoshis électroniques mais informatiques ! Il a en effet trouvé sur Internet
un programme qui fait fonctionner des tamagoshi virtuels dans un parc. Ce qui
est nouveau, c’est que l'on peut soit s'occuper des tamagoshis soit les mettre
à la garderie. Quand ils sont à la garderie, tous les tamagoshis, se
débrouillent pour survivre et répondre à leurs besoins ! Voilà ce qu’explique
l'aide de ce petit programme :
"Dans la garderie, il y a des tamagoshis qui s'occupent des autres ! Ainsi nous avons rajouté :
- un tamagoshi qui fait des bisous (il ne fait que ça) aux tamagoshis qui sont tristes,
- un tamagoshi qui donne à manger à n'importe quel tamagoshi qui a faim,
- un tamagoshi qui donne à boire aux tamagoshi qui ont soif
- et pour finir, un tamagoshi somnifère qui donne un somnifère aux tamagoshis fatigués.
Ainsi la communauté de tamagoshi arrive à auto satisfaire, et vous pouvez travailler sur votre ordinateur
sans être dérangé."
6
Nous venons d'aborder trois notions importantes pour les agents :
-
la notion de communauté. En effet, jusqu'à maintenant, nous avons parlé
d'agent mais sans préciser où ils étaient. Et bien voilà, les agents sont
dans une communauté appelée le Système Multi Agents (SMA). Les
agents à l'intérieur d'un SMA arrivent à auto satisfaire, c'est à dire qu'ils
arrivent à survivre et donc à atteindre leur but (pour les tamagoshis le but
est de survivre le plus longtemps possible).
-
Les agents ont un but et tous les agents présents dans le SMA vont
collaborer pour essayer d'atteindre ce but.
-
Enfin, les agents peuvent être spécialisés : un agent ne sait pas faire
beaucoup de chose mais ce qu'il sait faire, il le fait vite et bien et le met en
commun avec les autres agents.
Et en plus ils peuvent se déplacer... En fait le logiciel était tellement bien que
ses tamagoshis ne lui servaient plus à rien. Il les a donc donnés à un copain
qui adorait les tamagoshis. Ce copain, avait déjà quelques tamagoshis, il s'est
donc retrouvé avec plein de tamagoshis : Les tamagoshi de mon cousin
avaient changé de communauté.
Les agents peuvent se déplacer !
Pour des tamagoshis cela peut paraître anodin : il suffit de les prendre et de
les transporter. Mais pour les agents ceci peut-être plus évolué :
-
Les agents se déplacent car on leur dit de se déplacer. (Comme pour les
tamagoshis) ceci n'est pas très évolué.
-
Les agents demandent à se déplacer. Là, c'est plus intéressant car c'est
l'agent lui-même qui demande à se déplacer et à changer de Système
Multi Agent.
Une définition des agents et Système Multi Agent (SMA)
Pour résumer voici la définition d'un agent:
-
un agent est une entité autonome située dans un environnement,
-
un agent communique avec son environnement,
-
un agent peut communiquer avec son environnement à l'aide de
messages, dans ce cas, on peut distinguer deux grands types de
messages :
o les messages envoyés à plusieurs agents
o les messages envoyés à un seul agent,
-
un agent peut refuser de faire ce qu'on lui dit de faire,
-
les agents vivent dans des communautés appelées Systèmes Multi Agent
(SMA).
7
-
Ils collaborent au sein de ce SMA pour atteindre un objectif commun,
-
enfin, les agents peuvent se déplacer volontairement ou pas et voyager
ainsi d'un Système Multi Agent à un autre.
Les problèmes liés aux Systèmes Multi Agent
Quand mon cousin avait 30 tamagoshi et qu'il s'en occupait avec ma
cousine... Cependant, ma cousine n'est pas fan de tamagoshi, elle en a eu
vite marre et dès qu'un tamagoshi sonnait, elle appuyait sur le bouton dormir,
comme ça elle était tranquille pour un petit moment. Le problème, c'est que
les tamagoshis ne vivaient pas longtemps car ils ne pouvaient plus ni manger,
ni boire.
Là je sens qui en a qui vont me dire : "Oui mais... le tamagoshi a le droit de
refuser de dormir, on l'a vu tout à l'heure". Je suis d'accord, mais les
tamagoshi sont bien élevés et quand on leur dit de dormir, ils dorment même
s'ils n'ont pas sommeil...
Un autre problème avec les 30 tamagoshis, c'est qu'il y en a un qui ne
marchait pas bien : il n'arrêtait pas de sonner et refusait de dormir ! Résultat,
on s'occupait tellement de lui que parfois d'autres tamagoshis mouraient en
attendant...
Nous avons ici bien cerné le problème lié aux SMA : tout le monde doit jouer
le jeu, tout le monde doit coopérer pour atteindre le même objectif.
Si certains agents coopèrent (les tamagoshis qui dorment) et d'autres pas (ma
cousine qui les fait dormir tout le temps) l'objectif du SMA (faire vivre les
tamagoshis le plus longtemps possible) ne peut être atteint.
Si certains agents monopolisent des ressources sans raison (le tamagoshi qui
ne marche pas bien) l'objectif du SMA ne pas, non plus, être atteint.
Les agents doivent donc coopérer et respecter certaines règles de bonne
conduite pour que le SMA puisse atteindre son objectif.
8
En espérant que cette explication aura éclairé les lecteurs profanes de ce
rapport, voici maintenant une approche plus « informatisée » du monde des
agents :
Définition des agents
AGENT : c'est une entité physique ou virtuelle
-
qui est capable d'agir dans un environnement,
-
qui communique avec son environnement,
-
qui est mue par un ensemble de tendances (sous la forme d'objectifs
individuels ou d'une fonction de satisfaction, voire de survie, qu'elle
cherche à optimiser),
-
qui possède des ressources (temps CPU, mémoire...) propres,
-
qui est capable de percevoir (mais de manière limitée) son environnement,
-
qui ne dispose que d'une représentation partielle de cet environnement (et
éventuellement aucune),
-
qui possède des compétences et offre des services,
-
qui peut éventuellement se reproduire,
-
dont le comportement tend à satisfaire ses objectifs en tenant compte des
ressources et des compétences dont elle dispose, et en fonction de sa
perception, de ses représentations et des communications qu'elle reçoit.
Définition des Systèmes Multi Agents
SMA : Système Multi-Agents : c'est un système composé des éléments suivants :
-
un environnement E, disposant d'une métrique en général,
-
un ensemble d'objets O, auxquels on peut associer une position dans E à
un moment donné. Ces objets (hormis les agents) sont passifs : les agents
peuvent les percevoir, les créer, les détruire et les modifier.
-
un ensemble A d'agents, lesquels représentent les entités actives du
système,
-
un ensemble de relations R qui unissent les objets (et agents) entre eux,
-
un ensemble d'opérateurs Op permettant aux agents de A de percevoir,
produire, consommer, transformer et manipuler des objets de O, des
opérateurs chargés de représenter l'application de ces opérations et la
réaction du monde à cette tentative de modification, que l'on appellera les
lois de l'univers.
9
Diversité des Systèmes Multi Agents
Voici quelques exemples pour mieux comprendre ce qu'est un SMA et toute la
diversité qui peut être engendrée par de tels systèmes :
Une fourmilière
L'environnement : la fourmilière et l'espace alentour occupé par les fourmis
Les objets : les végétaux, la terre, l'eau,... toute chose inerte
Les agents : les fourmis, les araignées... toute chose vivante.
Un écosystème
Cet écosystème peut-être : une prairie, un bois, un groupe de proies
(cervidés), un groupe de prédateurs(loups. Le principe est le même que pour
la fourmilière. On peut, avec un tel système étudier l'écosystème, déterminer
si des espèces vont disparaître ou de quelles façons vont évoluer les
différentes populations.
Un groupe de robots partant à la recherche de minerai
Chaque robot pouvant soit chercher du minerai sur un terrain encore inconnu
et/ou extraire du minerai et/ou le transporter...
On constate qu'il y a plusieurs niveaux d'organisation :
micro-social
On s'intéresse aux différentes formes de liaison et d'interaction entre un petit
nombre d'agents (ex des robots chercheurs de minerai),
groupe
L'organisation est plus complète. On étudie les différenciations des rôles et
des activités des agents, l'émergence de structures organisatrices entre
agents... (ex de l'écosystème),
sociétés globales (population)
On étudie la dynamique d'un grand nombre d'agents, la structure générale du
système et son évolution (ex des fourmis).
10
Les agents peuvent être classés en trois catégories relatives à leur réactivité :
cognitifs
Ils peuvent anticiper, prévoir le futur, mémoriser des choses ... ils
réfléchissent.
réactifs
Ils réagissent directement à l'environnement perçu, par pulsion (ex : les
fourmis).
hybrides
un mélange des deux.
Il y a donc une infinité de système multi-agents différents. En plus de cette
différence entre les agents, de leur niveau d'organisation, s'ajoutent les
moyens de communication (d'agent à agent, d'agent à agent passant par le
SMA, par l'environnement (les signaux)...), les problèmes d'interaction et de
coopération qui peuvent être réglés de différentes manières, et les actions et
comportement qui sont propres à chaque agent.
Il est utile de remarquer qu'un SMA est un agent. Ainsi, les fourmilières sont
des agents qui peuvent interagir entre eux (prise de territoire, attaques...), les
actions additionnées des fourmis donnant une action globale qui sera celle de
la fourmilière.
Mais on classe également les agents par rapport à leur mobilité
Agents fixes
C'est le système le plus immédiat (facile) à implémenter. Un SMA avec des
agents non mobile présente tous les intérêts d'un SMA classique :
-
exécution des divers agents en parallèle (en général sous forme de
threads) et donc indépendance d'exécution des différents agents,
-
communication grâce à un protocole et un système de communication (en
réseau si c'est le cas),
-
libre arbitre des agents : ils décident de répondre ou non aux sollicitations
(messages) extérieures,
-
les agents peuvent êtres de n'importe quel type : réactif, cognitif, etc.
Ce cadre de travail permet d'implémenter beaucoup d'applications utilisant les
agents. On peut alors faire de la programmation "orienté agent" (pour ceux qui
pensent que les agents sont l'évolution logique des objets et donc que la
programmation orientée agent sera l'équivalent de la programmation orienté
objet). On peut aussi travailler en réseau, c'est à dire, que les agents sont
répartis à plusieurs endroits du réseau mais ne se déplacent pas.
11
Note : Il peut aussi être possible dans ce cadre d'architecture de tuer un agent
et d'en créer un autre à un autre endroit qui continue ce que le premier avait
commencé. Cela fournis une forme artificielle de mobilité.
Agents mobiles
Lors de l'utilisation d'agents mobiles toutes les caractéristiques des agents
fixes sont conservées. L'utilisation des agents mobiles présente en outre,
plusieurs avantages :
-
répartition de la charge de calcul : un agent mobile peut en effet se
déplacer sur un ordinateur plus puissant pour effectuer un calcul
complexe. De même il peut quitter une machine qui est saturé pour aller
sur une autre.
-
réduction du trafic réseau : un agent qui a besoin de traiter une grande
quantité de données situées sur un autre ordinateur (base de données par
exemple) peut se déplacer sur l'ordinateur possédant les données et
revenir avec le résultat. Cela permet d'éviter de faire transiter les données
sur le réseau.
Les agents mobiles présentent des intérêts évidents, mais sont cependant
plus complexes à gérer. Par exemple :
-
il faut faire suivre les messages lorsque l'agent se déplace.
-
pour qu'un agent puisse se déplacer, il faut bien entendu que des sites
d'accueil existent.
-
l'utilisation de plusieurs langages de programmation peut poser des
problèmes pour la mobilité des agents.
Format d'échange des données
Dans un système hétérogène où collaborent des agents écrits dans différents
langages, la nécessité de définir un protocole de communication est évidente.
Ce protocole doit cependant aussi bien définir le fond que la forme des
échanges, ainsi lorsqu'un objet reçoit une information, il doit savoir de quoi il
s'agit et éventuellement comment la traiter.
La définition d'un protocole (ou langage) de communication permet, en outre,
de faire coopérer facilement plusieurs versions d'un même logiciel : Une fois
le protocole définit, une partie du logiciel peut évoluer sans que les autres
parties n'aient à évoluer de leur côté.
Ceci suppose que dés le départ, le protocole de communication choisi soit le
plus complet possible, mais aussi et surtout extensible. C'est en effet grâce à
cela que l'évolution et l'interopérabilité des différentes briques du logiciel peut
être garantie.
12
Format XML (description de la forme)
XML permet de décrire des structures de données aussi bien que de
représenter des données. Ceci permet donc au langage XML d'être un bon
candidat pour l'échange de données entre les différents agents du système.
Plusieurs solutions se présentent tout de même pour l'échange de données
avec XML : Les données que l'on échange n'ont pas une structure fixe (a
priori), il faut donc :
-
soit décrire la structure des données dans le document XML puis
construire un objet qui puisse accueillir ces informations,
-
soit définir une bibliothèque d'objet qui sont susceptibles d'êtres échangés,
et se référer à cette bibliothèque lorsque l'on échange des informations.
Les deux solutions semblent envisageable et présentent chacune leurs
avantages et leurs inconvénients.
Il faut noter que l'utilisation langages différents entraîne d'autres problèmes,
notamment sur les types de base : un entier n'a pas la même plage de valeur
dans tous les langages, etc.
Format ACL / KIF / KQML (description du fond)
KQML (Knowledge Query Modeling Langage) est un langage qui permet de
définir un moyen de communication uniforme entre les divers acteurs du
système multi-agents. Ce langage, contrairement à XML décrit la forme dont
les données sont échangées (du pseudo-lisp) mais aussi le fond, c'est à dire
les informations à mettre dans le message.
Même si l'on utilise XML pour la forme, pour le contenu du message il peut
être intéressant de regarder ce qui a été fait avec KQML : Le nom de
l'expéditeur, du destinataire, le sujet du message, l'intention du message et/ou
le type du message, la priorité du message, la date d'émission, la durée de
validité (dans le cas d'une application où la notion de temps est importante) le
type de contenu de message, le contenu du message, etc.
13
Gestion du temps
La gestion du temps est importante. En effet, quelle valeur donner à une
information émise il y a 2 jours ? (surtout si cette information est vite périmée :
prévision météo par exemple).
Ainsi la gestion du temps et le "nettoyage" des messages ayant expirés est
nécessaire pour économiser du temps CPU et éviter de fournir des
informations erronées.
Cette gestion peut sembler un peu "lourde" à mettre en oeuvre, mais dans le
cas d'une application répartie, donc sur plusieurs (>2) sites en réseau, la
notion de temps est très importante. En effet, si sur une machine, on peut
considérer que l'échange de données inter processus est instantané, sur un
réseau, même de deux machines, cet échange d'information peut s'avérer
lent.
Note : Comme nous le verrons plus tard, l'implémentation d'un SMA en
réseau peut s'assimiler à la programmation d'une structure réseau logicielle
au-dessus de la structure réseau matérielle. Or dans la structure réseau
matérielle, les paquets transportés sont dotés d'un TTL (time to live) donc
d'une date de péremption. Il semble donc logique d'avoir une notion
comparable dans la structure logicielle traitant le réseau.
Communication entre les agents
Communication asynchrone
Réponse non donnée immédiatement. On demande et on n'attend pas la
réponse, on fait autre chose en attendant.
Communication synchrone
La communication synchrone est celle que l'on a le plus l'habitude de
manipuler : c'est, par exemple, un appel de méthode. Un objet demande
quelque chose à un autre objet et attend la réponse avant de poursuivre son
exécution.
Communication directe (monocast)
On discute directement d'un agent avec un autre agent : les deux agents sont
en communication directe. En fonction des implémentations, les deux objets
se "connaissent" directement via leurs références, connaissent un proxy de
l'objet ou ne connaissent que le nom de l'objet et utilisent les services d'un
facteur pour délivrer le message. Les diverses implémentations dépendant du
niveau d'indépendance que l'on veut donner aux agents.
14
Communication en groupe de diffusion (multicast)
Inscription à une liste de diffusion et réception de tous les messages qui y
sont associés (utilisation des sockets multicast).
La différence entre la communication directe et les listes de diffusion, est
exactement la même que celle qui existe entre le mail et les mailing-list. (On
peut noter que les listes de diffusion s'apparentent à la technologie push.)
Dans le cas où plusieurs listes existent, il est possible de les structurer sous
forme d'une liste ou d'une arborescence. Cette dernière possibilité est
beaucoup plus souple. De même un objet partagé peut gérer la liste des
sujets et en ajouter à la demande d'un utilisateur.
Un cas particulier de la communication multicast est la communication
broadcast. La communication broadcast consiste à envoyer un message à
tous les agents du SMA. Ceci permet, par exemple, à un agent d'indiquer sa
présence aux autres agents. Ce type de communication s'implémente très
facilement si l'on dispose d'une couche de communication multicast.
Note : Les sockets multicast sont basées sur le protocole UDP. Ce protocole
se situe un niveau en dessous les sockets TCP/IP et ne garantie pas la
réception des données envoyées. Il se peut donc que certains messages
envoyés via les multicast sockets n'arrivent jamais.
Transport des messages
Le transport des messages est un point important dans les SMA : les agents
"dialoguent" uniquement par échange de message, donc les performances du
transport de messages influencent directement les performances du SMA.
Le transport des messages peut se faire de diverses manières :
-
à l'aide d'objets CORBA ou des sockets pour la couche de transport des
données.
-
D'autres systèmes propriétaires permettent aussi de transport des
messages : PRC en C/C++, RMI en Java, COM/DCOM sous Windows...,
-
par appel de méthode directe sur l'agent ou appel de méthodes sur un
objet proxy de l'agent (celui-ci permettant aux autres objets/agents de ne
jamais connaître directement l'agent),
-
par utilisation d'un MOM (Message Oriented Middleware) qui agit comme
un facteur et distribue les messages aux agents intéressés.
Nous venons d'évoquer les méthodes de transport susceptibles d'êtres
utilisées pour la communication directe entre deux agents, pour la
communication multicast, on peut rajouter d'autres points :
15
-
la gestion des différents sujets des listes de diffusion,
-
la diffusion des messages d'un point de vue matériel : on peut utiliser la
couche de transport de messages directs ou utiliser des protocoles
multicast, comme les multicast socket.
Il faut aussi noter que dans le cas d'une implémentation réseau, il faut définir
un "réseau virtuel" logiciel au-dessus de la couche réseau matérielle. En effet
il faut pouvoir donner une adresse (équivalent à de l'adresse IP pour les
machines) à tous les agents présents dans le système. Il faut aussi pouvoir
router les messages afin que n'importe quel agent puisse dialoguer avec
n'importe quel(s) autre(s) agent(s). Plusieurs solutions sont envisageables
pour résoudre ce problème :
-
un objet distribué unique qui attribue les adresses (objet CORBA par
exemple) et qui gère le routage des messages,
-
une architecture du type réseau Ethernet (il me semble), c'est à dire avec
des routeurs (gateway) à différents niveaux. Par exemple un routeur par
SMA puis un routeur pour un groupe de SMA. Cette architecture peut être
auto-configurable (en se basant en partie sur les adresses IP des
machines par exemple) ou être configurée par des fichiers d'initialisations
par exemple.
Architecture du SMA
L'architecture du SMA sera liée à la façon dont seront implémentées les
communications.
On parle ici de SMA en tant que système multi-agents global, c'est à dire,
l'infrastructure qui permet aux agents de fonctionner. Il faudrait peut-être
parler de SEMA pour Système d'Exploitation Multi-Agents. En effet, le
système doit gérer aussi bien l'ensemble des transactions sur le réseau que la
gestion des messages ou l'accès aux données.
Nous utilisons donc abusivement le terme SMA pour désigner les lieux (ou
sites) ou s'exécutent les agents, ainsi que l'ensemble des opérations gérées
par ces lieux d'exécution.
16
Organisation centralisée
Dans une conception centralisée, un agent connaît tous les autres agents.
Ainsi lorsque l'on a besoin d'une compétence particulière ou d'un agent
particulier on s'en réfère à cet agent pour connaître le/les agents concernés.
On peut noter que ces deux fonctionnalités font partie de CORBA. Ainsi, si
tous les agents sont des objets CORBA, il n'y a plus grand chose à faire.
L'avantage de la méthode est sa simplicité de mise en oeuvre. Cependant, un
seul objet gérant toutes les adresses, il peut devenir un goulet d'étranglement
et grever de façon significative les performances du système. De même, si
l'objet gérant le système d'adressage plante, le système plante avec.
Organisation libre (non centralisée)
Aucun agent ne connaît tous les agents. Localement, un agent peut connaître
les agents avec il est susceptible de traiter, mais personne n'a, a priori, de
vision globale.
Personne ne connaît personne a priori et c'est en dialoguant que l'on trouve
les autres. On peut par exemple s'inscrire sur un groupe de diffusion qui nous
intéresse pour entrer en contact avec d'autres agents.
Cette méthode présente l'avantage d'être plus "distribué" que la méthode
centralisée. En cas de défaillance d'une partie du système, le reste peut
continuer à fonctionner. Cependant la recherche d'un agent donnée ou d'une
catégorie d'agent ayant des compétences particulières est moins directe. De
même l'attribution d'adresses unique à chaque agent est moins directe que
dans la méthode centralisée.
Gestion du temps
Le problème de la gestion du temps a déjà été abordé dans le cadre des
messages, il s'agit maintenant de la gestion du temps pour les agents
proprement dits : Un agent est généralement implémenté sous forme d'un
thread, celui-ci étant géré par le langage de programmation ou le plus souvent
par le système d'exploitation. On est donc dépendant de la gestion des
threads du système d'exploitation.
Le système d'exploitation ayant généralement un système mutli-thread
préemptif, la gestion des priorités de threads se fait dans une file d'attente et
non pas sur le temps d'exécution des différents threads. Il peut donc être
intéressant dans certains cas d'implémenter une gestion des threads qui lie la
priorité directement avec le temps d'exécution, ceci dans l'optique de pouvoir
17
gérer des priorités de façon beaucoup plus fine que ce qui est normalement
permis avec la gestion préemptive du système d'exploitation.
Utilisation des agents
Maintenant que nous savons ce qu'est un agent, un SMA et quels sont les
pièges à éviter, voyons quelques exemples d’utilisation des agents et
systèmes multi-agents dans les deux cadres de leur déploiement : la machine
simple et le réseau.
Les utilisations sans réseau
Ce sont les utilisations les plus courantes actuellement. Les différentes
utilisations sont :
-
Les assistants ( le tristement célèbre Trombine d’office )
-
Les jeux (les agents permettent de faire fonctionner les avatars )
-
la robotique ( la tondeuse ou la balayeuse automatique ).
Les utilisations avec réseau
Ce sont les plus prometteuses pour l'avenir. En effet le développement rapide
d'Internet a entraîné le développement des agents mobiles, c'est à dire, des
agents qui peuvent se déplacer sur le réseau. Les différentes utilisations
possibles sont :
-
la recherche d'information
-
la surveillance
-
la distribution d'information
-
le commerce électronique
-
le calcul parallèle : une application beaucoup plus informatique des agents
est le calcul. Un calcul complexe peut s'exécuter facilement sur plusieurs
machines en utilisant des agents.
-
les jeux
18
Les Outils et Langages (2)
« en quelques mots »
Jade est un logiciel libre distribué par TILab en Open Source avec une
licence LGPL. Jade a pour but de simplifier le développement des
systèmes multi-agents tout en fournissant un ensemble complet de
services et d'agents conformes aux spécifications FIPA.
La plate-forme d'agent de Jade inclut tous les composants obligatoires qui
contrôlent un SMA. Ces composants sont l’ACC, l’AMS et le DF. Toute la
communication entre agents est exécutée par messages FIPA ACL.
La plate-forme d'agent peut être répartie sur plusieurs serveurs. Une seule
application Java, et donc une seule machine virtuelle de Java (JVM), est
exécutée sur chaque serveur. Chaque JVM est un conteneur d'agents qui
fournit un environnement complet pour l'exécution d'agent et permet à
plusieurs agents de s'exécuter en parallèle sur le même serveur.
L'architecture de communication offre la transmission de messages flexibles
et efficaces. JADE crée et contrôle une file d'attente des messages entrants
pour chaque agent. Le modèle global de communication FIPA a été mis en
application. Ses composants ont été distingués clairement et ont été
entièrement intégrés: protocoles d'interaction, ACL, langues, schémas de
codage, protocoles de transport...
Le mécanisme de transport fonctionne comme un caméléon. Il s'adapte à
chaque situation, en choisissant de manière transparente le meilleur protocole
disponible. Java RMI*, http, et IIOP sont actuellement employés, mais la
plupart des protocoles d'interaction définis par FIPA sont déjà disponibles et
peuvent être instanciés.
Concrètement, un thread est lancé pour chaque agent, mais ces derniers
doivent souvent exécuter des tâches parallèles. Avec la solution du
multithreading offerte directement par Java, Jade supporte également la
gestion des comportements coopératifs. Le run-time inclut également
quelques fonctions complexes prêtes l’emploi pour les tâches les plus
communes dans la programmation agent, comme des protocoles d'interaction
de FIPA. Jade offre entre autre un certain JessBehaviour qui permet la pleine
19
intégration dans JESS, où Jade fournit le GUI de l'agent et garantit la
conformité de FIPA, alors que JESS ( qui est un outil de raisonnement à base
de règles) est le moteur qui exécute tout le raisonnement nécessaire. On a
donc la possibilité de créer des agents intelligents en délégant le
raisonnement à d’autres outils.
La plate-forme d'agent fournit une interface graphique utilisateur (GUI) pour la
gestion à distance des agents RMA (Remote Management Agent), surveillant
le statut des agents, permettant par exemple d’arrêter et de remettre en
marche des agents. Le GUI permet également de créer et de lancer un agent
sur un serveur à distance, à condition qu’un conteneur d'agent fonctionne
déjà. Le GUI permet de commander d'autres plates-formes d'agent à
distance.
Un GUI du DF ( directory facilitator )peut être lancé du menu outils du RMA.
Le DF est un composant qui fait office d’annuaire. C’est un service de « pages
jaunes » qui permet de mettre en relations les agents avec leurs
compétences. Un agent peut enregistrer ses compétences dans le DF ou
interroger le DF pour connaître les compétences proposées par les autres
agents. Le GUI permet d’associer ces DF afin de créer plusieurs niveaux de
domaines. Le GUI peut accéder de la même manière à n’importe quel DF
même situé sur une plate forme distante d’agents non Jade.
20
Il existe dans Jade un certain nombre d'outils graphiques qui soutiennent la
phase de correction, habituellement très complexe dans les systèmes
répartis.
L'agent Dummy est un outil simple et très utile pour visualiser des échanges
de messages entre agents. L'agent Dummy facilite la validation d'un agent
avant l'intégration dans le SMA et facilite le debugage au cas où un agent
échouerait. L'interface graphique fournit un support pour éditer, composer et
envoyer des messages ACL aux agents. Elle permet également de recevoir et
de regarder des messages des agents, et, par la suite, de sauver ou charger
des messages sur le disque dur.
L'agent Sniffer permet de suivre des messages échangés dans une plateforme d'agent Jade. Quand l'utilisateur décide de « renifler » un agent, ou un
groupe d’agents, chaque message dirigé vers ou venant de cet agent, ou du
groupe, est dépisté et montré dans la fenêtre de Sniffer. L'utilisateur peut
alors regarder, sauvegarder, charger chaque message pour une analyse
postérieure.
21
L'agent Introspector permet de surveiller et de commander le cycle de vie d'un
agent courant ainsi que ses messages échangés (provenant de la file
d'attente des messages envoyés et reçus).
Jade est une marque déposée enregistrée par CSELT et résulte
principalement d'une activité de recherches. Il a avec succès passé les tests
d'interopérabilité de FIPA à Séoul en janvier 1999 et à Londres avril 2001 et a
été intensivement employé dans le cadre de plusieurs projets.
Le développement de Jade continue toujours. D'autres améliorations,
perfectionnements, et réalisations ont été déjà projetés, la plupart d'entre eux
en collaboration avec les utilisateurs intéressés de la communauté de Jade.
Ce stage s’intègre pleinement dans ce projet.
22
Les Outils et Langages (3)
En résumé ...
... les Java Server Pages permettent de faire des pages web dynamiques
en Java.
Voilà une description très générale qui pourrait d’ailleurs convenir à des pages
php ou asp ...
Les applications sont très nombreuses et très utiles. Cela sert par exemple à
personnaliser une page web en fonction de l’utilisateur. On peut lui dire
« bonjour Francis, il est 8h12, tu es en retard en cette matinée ensoleillée »
lorsqu’il arrive sur la page web.
La page peut donc reconnaître l’utilisateur, trouver l’heure, constater que cette
heure est au matin et qu’elle est supérieure à l’heure habituelle d’arrivée de
Francis et enfin consulter la météo du jour sur un serveur distant. Mais si une
autre personne se connecte à un autre moment, il va de soit que le contenu
de la page sera différent.
Les sources de la page telles que peut les récupérer l’utilisateur ( via son
explorateur Internet ) seront en simple html ( le langage le plus répandu des
pages web ) alors que le programmeur aura produit un mélange de html et de
java en respectant une syntaxe adaptée. C’est le serveur qui interprète le
code du programmeur pour le transformer en html. Ici on a utilisé le serveur
Tomcat.
23
Voici un tout petit exemple qui vous donnera un aperçu de cette technologie :
Bonjour.Jsp
<html>
<body bgcolor= « white »>
<% java.util.Date clock = new java.util.Date() ; %>
<% if (clock.getHours() < 12) { %>
<h1> Bonjour !</h1>
<% else if (clock.getHours() < 18) { %>
<h1> Bon après-midi !</h1>
<% else { %>
<h1> Bonsoir !</h1>
<% } %>
bienvenue sur mon rapport de stage !
</body>
</html>
Ce petit bout de code très simple contient deux types de lignes.
Concrètement, les lignes en gras = Jsp et lignes normales = html. Lorsque l’on
lance cette page sur un serveur adapté, aux alentours de 15h00 par exemple,
on obtient ceci :
Bon après midi !
bienvenue sur mon rapport de stage !
Et si l’on regarde le code source, on obtient :
<html>
<body bgcolor= « white »>
<h1> Bon après-midi !</h1>
bienvenue sur mon rapport de stage !
</body>
</html>
En interprétant le code Jsp, le serveur a donc, en fonction de l’heure, choisi le
terme « bon après-midi » et enlever tout le code Jsp.
De plus Jsp permet de développer des « balises » personnalisées ce qui
permet une séparation fonctionnelle entre les programmeurs et les créateurs
de pages. La balise étant cette ligne de code contenu entre les signes « < » et
« > ».
Par exemple, le créateur veut insérer un carré au milieu de sa page mais il ne
sait pas comment programmer cette insertion. Le développeur crée une balise
<carré taille= 8 position= « milieu »/> et le créateur n’a plus qu’à l’utiliser très
simplement. Tout le code de cette balise est placé sur le serveur et reste
transparent pour le créateur.
C’est sur cette application des Jsp que s’est déroulé mon stage.
Approfondissons un peu
24
Java Server Pages. Moteur de publication dynamique de documents
web, créé par Sun. Les documents contiennent du HTML et du Java, ce
dernier étant interprété par le serveur.
Voici une définition un peu plus technico-technique des Java Server Pages.
Tout d’abord, voyons le serveur utilisé pour ce stage :
Le serveur tomcat
Tomcat (4.0) est une implémentation de référence des spécifications des
servlets et des Jsp de SUN (Servlet API 2.3 et Jsp 1.2). Ce serveur est issu
du projet Jakarta de l'Apache Software Fundation.
Il peut tourner tout seul, bien que ses performances pour l'envoi de pages
HTML brutes ne soient pas à la hauteur des serveurs tels qu'Apache ou en
complément d'un serveur web traditionnel (IIS, Apache...).
Son installation requiert la présence du JDK 1.3 sur la machine. On trouvera
une installation de tomcat sur http://jakarta.apache.org/.../jakarta-tomcat-4.0.3.zip
Il faudra également
l’environnement.
effectuer
quelques
réglages
au
niveau
de
pour lancer tomcat:
/usr/local/apache/jakarta-tomcat-4.0.3/bin/startup.sh
Vous devriez pouvoir vous connecter à: http://localhost:8080/index.html
Vous devriez voir s'afficher une page Web.
Par défaut, Tomcat s'installe sur le port 8080 au lieu du 80 habituellement.
Mais cela ne gêne pas grand monde, pour l'instant !
les fichiers de configuration d'un serveur tomcat :
web.xml
Configuration des contextes d'applications web
server.xml Configuration initiale du serveur
25
Les Jsp plus en détails
Les Jsp proposent un langage de script puissant (un langage interprété)
exécuté du côté du serveur au même titre que les scripts PHP,ASP,... Les
scripts écrits en JavaScript ou les applets Java s'exécutent du coté client via
le navigateur.
Les Jsp sont intégrables au sein d'une page Web en HTML à l'aide de balises
spéciales permettant au serveur Web de savoir que le code compris à
l'intérieur de ces balises doit être interprété afin de renvoyer du code HTML au
navigateur du client.
Le fonctionnement des Java Server Pages
Une page utilisant les Java Server Pages est exécutée au moment de la
requête par un moteur de Jsp, fonctionnant généralement avec un serveur
Web ou un serveur applicatif. Le modèle des Jsp étant dérivé de celui des
servlets (en effet les Jsp sont un moyen d'écrire des servlets), celle-ci est
donc une classe Java dérivant de la classe HttpServlet, et utilisant les
méthodes doGet() et doPost() permettant de renvoyer une réponse par le
protocole HTTP.
Lorsqu'un utilisateur appelle une page Jsp, le serveur Web appelle le moteur
de Jsp qui crée un code source Java à partir du script Jsp, compile la classe
afin de fournir un fichier compilé (d'extension .class), c'est-à-dire qu'il
constitue en fait une servlet à partir du script Jsp...
En réalité ce processus est un peu plus perfectionné: le moteur de Jsp vérifie
si la date du fichier.Jsp correspond à celle du fichier.class. Le moteur de Jsp
ne transforme et compile uniquement la classe qu’au cas où le script Jsp a été
mis à jour. Ainsi, le fait que la compilation ne se fasse que lors de la mise à
jour du script Jsp, fait de cette technologies une des plus rapides pour créer
des pages dynamiques.
En effet, la plupart des technologies de pages actives (ASP, PHP, ...)
reposent sur un code interprété, ce qui requiert beaucoup de ressources pour
fournir la réponse HTTP. Les Jsp étant compilées (en fait il s'agit d'un
bytecode) elles sont beaucoup plus rapides à l'exécution. Actuellement seuls
les scripts FastCGI (utilisant du code compilé écrit en langage C) sont plus
rapides car ils ne nécessitent pas l'intervention d'une machine virtuelle pour
exécuter l'application.
26
Caractéristiques des Java Server Pages
Les Jsp permettent donc d'écrire facilement des servlets, en incluant dans des
balises spécifiques le code Jsp au sein du fichier HTML. De plus, les Jsp étant
basées sur Java côté serveur possèdent toutes les caractéristiques faisant la
force de Java:
-
les Jsp sont multithreadées
-
les Jsp sont portables
-
les Jsp sont orientées objet
-
les Jsp sont sûres
A noter que les Jsp intègrent la notion de « session », ce qui permet de
simuler un mode connecté.
Implantation du code Jsp au sein de la page HTML
Un fichier Jsp est un fichier portant l'extension.Jsp, contenant du code HTML
ainsi que des balises spécifiques. Les balises <Servlet> permettent d'intégrer
une servlet. Les balises de syntaxe Jsp seront décrites par la suite.
Séparation entre données et logique applicative
Grâce à l'utilisation de balises, Jsp permet d'intégrer facilement du code Java
au sein du code HTML. L'intérêt principal de ce mécanisme par rapport aux
servlet provient de la séparation entre données (codage HTML de la logique
applicative fournie par Java. Jsp doit ainsi être utilisé pour accéder à des
composants réutilisables (servlets, JavaBeans, EJB (Enterprise JavaBeans)).
Les éléments d'une page Jsp
Une page Jsp peut contenir en plus du code HTML cinq types d'éléments :
les commentaires
Avec Jsp il est possible d’insérer deux types de commentaires :
visible dans le code source HTML du client avec la syntaxe suivante :
<!-- commentaire [<%= expression %>] -->
visible uniquement dans le code Jsp grâce à la syntaxe suivante :
<%-- commentaire -->
27
les directives
Les directives Jsp fournissent les informations globales relatives à la page.
Ce sont des instructions insérées dans des tags HTML spéciaux. La syntaxe
des directives Jsp est la suivante :
<%@ directive { attribut="valeur"} %>
page propose des informations relatives à la page Jsp. ex :
<%@ page language="java" import="package.*,contentType=" text/html "%>
include permet d'inclure des fichiers dans la page HTML
<%@ include file="relativeURL" %>
taglib définit une librairie de balises pouvant être utilisée dans la page
<%@ taglib uri="URIToTagLibrary" prefix="tagPrefix" %>
Cette directive permet de créer de nouveaux tags de la forme :
<tagPrefix:name attribute="value" ... %> ... </tagPrefix:name%>
C’est d’ailleurs ce qui a été fait pour le projet.
les déclarations
Une déclaration est un bloc permettant de définir des méthodes et des
variables de classe à utiliser dans toute la page. La syntaxe d'une déclaration
est la suivante : <%! declaration %>
Voici un exemple de déclaration :
<%! String Chaine = "bonjour"; Int Numero = 10; public void jspInit() { // instructions; }
%>
les scriptlets
Une scriptlet Jsp est un bloc de code Java compris entre les balises suivantes
<% /* scriptlet */ %>
Le code Java présent entre les balises devient le corps de la méthode
_JspService() lors de la génération de la servlet. La scriptlet a implicitement
accès à de nombreux objets.
les expressions
Les expressions Jsp permettent d'insérer simplement des chaînes de
caractères générées dynamiquement dans la page HTML. La syntaxe d'une
expression Jsp est la suivante : <%= Expression >
L'expression suivante permet par exemple de retourner une chaîne contenant
l'adresse IP du client : <%= request.getRemoteAddr(); >
Il s'agit ainsi d'un raccourci pour la scriptlet suivante :
<% out.println(request.getRemoteAddr()); >
28
Les Outils et Langages (4)
Les balises ou <taglib> :
Très simplement …
Rappelons simplement l’exemple du carré vu précédemment. Toto, un
créateur de pages web souhaite insérer des carrés de couleurs et de
tailles variables dans sa page. Cependant, il ignore tout de la
programmation avancée et ne connaît aucune commande html ( un
langage très simple pour écrire des pages web ) susceptible de lui
fournir un tel dessin. Il demande donc à son collègue programmeur de
créer une balise avec les paramètres de taille de position et de couleur.
<toto:carré size= « 8 » color= « blue » pos= « middle »/>
Cette balise très simple d’utilisation fait appel en réalité à tout un attirail de
fonctions et de fichiers et ce de manière totalement transparente pour le
créateur. Les balises permettent une séparation entre la représentation des
données et leur format réel.
Créer une bibliothèque de balises
L’objectif du stage proposé par monsieur Leberre était donc de créer une
bibliothèque de balises destinée à l’implantation d’agent Jade dans des pages
JSP. C’est dans la seconde partie de ce rapport que je développerai donc ce
travail, avec les méthodes employées, les difficultés rencontrées et bien
entendu le résultat.
29
Le projet
Le sujet
Développement d'une bibliothèque de balises JSP pour JADE.
Responsable : Daniel Le Berre
Résumé
JADE est une plate forme de développement multi-agents entièrement écrite
en Java. Elle permet de faire communiquer des agents situés sur des
machines du simple Palm Pilot au gros serveur.
Pour plus d'infos sur JADE, voir
http://sharon.cselt.it/projects/jade/
Java Server Pages est un environnement de développement de contenu
dynamique pour le web (comme php) basé sur Java. Afin de limiter l'utilisation
de code Java dans les pages web, il est possible de définir des bibliothèques
de balises (taglibs).
http://java.sun.com/products/jsp/
http://jakarta.apache.org/taglibs/
De plus en plus d'utilisateurs de JADE incorporent des agents dans leurs sites
web écrits en JSP. D'où l'idée de créer une bibliothèque de balises pour
manipuler des agents JADE.
http://cafe.newcastle.edu.au/daniel/JADEJSP.html
Ce stage s'adresse à un étudiant de maîtrise. Il demandera un investissement
de l'étudiant dans l'apprentissage de Java Server Pages, de la création de
bibliothèques de balises JSP, et de quelques notions de programmation
orientée agent à l'aide de JADE. Attention : toute la documentation disponible
est en anglais, tout comme le groupe de discussion du projet JADE dans
lequel sont discutés les problèmes techniques et les contributions. Le travail
de ce stage devrait être intégré dans la plate-forme JADE.
30
Le projet (2)
la bibliothèque de balises
La construction d’une bibliothèque de balises se déroule en plusieurs étapes
et nécessite l’implantation sur notre serveur (ici Tomcat) de plusieurs fichiers.
Nous prendrons tout au long de ce chapitre un exemple tiré du stage. Il s’agit
en l’occurrence de la balise <jade :container ……> qui permet de créer un
container nécessaire à la création d’agent jade.
Les fichiers utilisés pour la création des balises sont de deux types. Les
classes de gestion de balises et le fichier de description des balises. Les
balises peuvent ensuite être utilisés dans des Jsp.
Le fichier de description de tags
Le fichier de description des balises ( ou tld ou tag library descriptor) est un
fichier en langage XML. Il est placé sur le serveur au même endroit que les
fichiers statiques et porte l’extension .tld. Le format de ce fichier est par
exemple le suivant :
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE taglib
PUBLIC "-//Sun Microsystems, Inc.//DTD Jsp Tag Library 1.1//EN"
"http://java.sun.com/j2ee/dtds/web-Jsptaglibrary_1_1.dtd">
<taglib>
<tlibversion>1.0</tlibversion>
<Jspversion>1.1</Jspversion>
<shortname>jade</shortname>
<uri></uri>
<tag>
<name>container</name>
<tagclass>ContainerTag</tagclass>
<bodycontent>EMPTY</bodycontent>
<attribute>
<name>host</name>
<required>true</required>
<rtexprvalue>true</rtexprvalue>
</attribute>
….
</tag>
</taglib>
31
On déclare dans ce fichier toutes les balises de la bibliothèque et leur
paramètres. Ici la bibliothèque jade possède une balise container dont la
classe associée est ContainerTag.class et donc l’unique paramètre est host.
A noté les informations également portées dans ce fichier. La balise ne
contient pas de corps ( bodycontent is empty ). On ne peut donc pas apporter
des informations entre deux balises <jade:container> et <\jade:container>.
L’argument « host » est obligatoire (required = true). On peut très bien avoir
des paramètres facultatif (auquel cas required sera égal à false).
Les classes de gestion de balises
Les classes utilitaires pour la gestion de balises font partie du paquetage
javax.servlet.Jsp.tagext. Elles doivent hériter soit de TagSupport
(implantant l'interface Tag), soit de BodyTagSupport (implantant BodyTag).
La classe de la balise doit au moins redéfinir la méthode doStartTag().
L'attribut pageContext hérité de la classe TagSupport permet de récupérer
un flot vers la page vers la méthode getOut(). Il permet également de
récupérer la requête getRequest(), la réponse getResponse(), le contexte
getServletContext() et la session getSession().
Voici un exemple un peu élagué du code java de la balise container:
package ….
import …..
Le package contenant notre classe
Tous les packages importés
public class ContainerTag extends TagSupport {
String id;
String host="my_host";
int port=”my_port”;
Object beanObject;
boolean init = false;
String params;
public void set…. Tous les paramètres ont leur modificateur
public int doStartTag() throws JspException {
beanObject = pageContext.getAttribute(id, pageContext.APPLICATION_SCOPE);
if (beanObject != null) {
if (!Class.forName("jade.wrapper.AgentContainer").isInstance(beanObject))
throw new JspException("ClassCastException: " + id );
} return SKIP_BODY;
}
synchronized((ServletContext)pageContext.findAttribute(pageContext.APPLICATION))
{
beanObject = createBean();
System.out.println(" saving container for id "+id+" "+beanObject);
pageContext.setAttribute(id,
beanObject,PageContext.APPLICATION_SCOPE);
setInit(true);
} return SKIP_BODY;
}
private Object createBean() throws JspException {
System.out.println("container jade created");
jade.core.Runtime rt = jade.core.Runtime.instance();
Profile p = new ProfileImpl(host,port,null);
return rt.createAgentContainer(p);
} }
32
Si la balise n'a pas de contenu, elle doit retourner la valeur SKIP_BODY.
Pour utiliser cette « bibliothèque de balises » dans un document Jsp il suffit
préciser l'URL où charger le fichier tld et préciser le préfixe à utiliser pour les
balises.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<%@ taglib uri="jade.tld" prefix="jade" %>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<title> Exemple de Tag</title>
</head>
<jade:container id=”monconteneur” host="localhost" >
<body>
<h1>Exemple</h1>
it works
</body>
</html>
Ajouter un corps à la balise
Pour traiter le corps de la balise il faut tout d'abord que la méthode
doStartTag() retourne EVAL_BODY_INCLUDE. Il est ensuite possible de
redéfinir la méthode doEndTag() qui pourra effectuer des manipulations
après la fin du contenu. Si cette méthode retourne EVAL_PAGE, le reste de la
page est évalué, si elle retourne SKIP_PAGE, elle ne traite pas le reste de la
page.
C’est ce que fait notre balise <jade:sendObject ….. > </jade:sendObject>
puisque celle-ci envoie à l’agent passé en paramètre le texte placé entre les
deux balises.
Le
fichier
tld
doit
préciser
le
contenu
de
la
balise :
<bodycontent>Jsp</bodycontent>
Manipuler le corps de la balise
Afin de manipuler le corps de la balise il faut hériter de la classe
BodyTagSupport. Cette classe ajoute les méthodes doAfterBody() et
getBodyContent(). La méthode doAfterBody() doit être redéfinie afin de
manipuler le corps de la balise. Si cette méthode retourne SKIP_BODY, le
corps ne peut plus être manipulé ou si elle retourne EVAL_BODY_TAG le
corps est à nouveau évalué. La méthode getBodyContent() retourne un objet
de la classe BodyContent qui représente le corps de la balise. Sur cet objet,
les méthodes getEnclosingWriter(), getReader(), getString() et clearBody()
sont définies. La méthode getEnclosingWriter() retourne l'objet JspWriter
associé à la page. La méthode getReader() retourne un objet Reader sur le
corps de la balise. La méthode getString() retourne le corps de la balise sous
la forme d'une chaîne de caractères. La méthode clearBody() vide le contenu
33
de l'objet de en vue d'une nouvelle évaluation. Le fichier tld ne diffère pas du
précédent.
34
Les balises crées
Les balises crées dans le cadre de ce stage sont au nombre de trois :
-
-
Tout d’abord et c’est primordial pour la création d’agent Jade, la balise
<jade :container …>. Cette balise permet la création d’un conteneur et
présente les paramètres suivants :
§
Id = identifiant du conteneur
§
Host = hôte du conteneur ( ex « localhost »)
§
Port = le port utilisé par le conteneur ( ex « 1099 »)
Vient ensuite la seconde balise indispensable à la création d’un agent, la
balise <jade :useAgent … > qui permet de créer un agent et qui présente
les paramètres suivants :
§
Id = identifiant de l’agent
§
Classname = nom de la classe java décrivant l’agent
§
Container = conteneur où évoluera l’agent
§
Scope = portée de cet agent ( session, application … )
Cet agent étant réutilisable dans le code Jsp de la page, la classe de
gestion de cette balise est accompagnée d’une autre classe appelée
classeTEI ( pour Tag Extra Info ) qui permet « d’exporter » l’objet ainsi
créé à l’intérieur de la page et de pouvoir le manipuler dans le code Jsp.
-
Enfin, certainement moins vitale que ses deux consœurs mais très utile, la
balise <jade :sendObject> qui permet d’envoyer un objet à un agent. Elle
possède deux paramètres et utilise le code contenu entre ses deux
balises :
§
Id = identifiant du destinataire
§
Blocking = le message est-il bloquant ou non ?
Tous ces balises sont donc décrites dans des classes java qui ont été
compilées et placées dans un fichier.jar. Celui-ci est alors placé dans le
répertoire /lib de tomcat. Le répertoire /webapps/ROOT/WEB-INF/
contenant le fichier jade.tld contient la description de ces balises. Enfin
les pages Jsp utilisant ces balises sont placées dans le répertoire
/webapps/ROOT/ de tomcat. Pour se donner une idée de l’apport fournit
par ces balises, voyez plutôt l’exemple suivant.
35
Le projet (3)
Un exemple d’utilisation
une page Jsp classique
<%@ page import="jade.core.*" %>
<jsp:useBean id="oldsnooper" class="examples.jsp.Snooper" scope="application">
<% try {
// Does not work for the moment
// JADE 1.4 String [] args = {"-platform", "buffer:examples.jsp.Buffer"};
String [] args = {"-container"};
jade.Boot.main(args);
System.out.println("Jade Inited()");
System.out.println("Start");
oldsnooper.doStart("oldsnooper");
} catch (Exception ex) {
out.println(ex);
}
%>
</jsp:useBean>
<% oldsnooper.snoop(request.getRemoteHost()+" "+(new java.util.Date())+"
"+request.getRequestURI()); %>
<HTML>
<BODY>
It works !!!!
</BODY>
</HTML>
Cette page Jsp contient du code java inséré dans des scriplets ce qui pour un
non initié au langage de Sun peut paraître assez barbare. De plus la syntaxe y
est quelque peu complexe et doit être réécrite à chaque utilisation d’un agent.
Cette page crée donc un container, y insère un agent, et lui envoie le nom de
l’hôte ainsi que la date et l’heure de l’envoi.
De plus tout fonctionne correctement lorsque l’on considère uniquement un
agent de portée « application ». On rencontre divers problèmes lorsque l’on
veut en créer un de portée « session », « page » ou « requête ».
36
son équivalent avec nos balises
<%@ taglib uri="/WEB-INF/jade.tld" prefix="jade" %>
<jade:container id="moncontainer" host="heron" port="1099"/>
<jade:useAgent id="snooper" classname="examples.jsp.Snooper" container="moncontainer"
scope="application"/>
<jade:sendObject id="snooper" blocking="false">
<%= request.getRemoteHost()+" "+(new java.util.Date())+" "+request.getRequestURI()+"
METHOD2" %>
</jade:sendObject>
<HTML>
<BODY>
It works !!!!<br>
Messages sent.
<br>
<%=snooper%>
</BODY>
</HTML>
La différence est à mon sens flagrante. D’une part, le code est beaucoup plus
léger et plus compréhensible. Nul besoin d’être un programmeur averti pour
insérer le conteneur. Il suffit juste de lui donner un nom, un hôte et un port,
éléments qui tiennent plus de la technique que de la programmation. Il faut
simplement connaître la classe de l’agent pour le créer. Enfin, l’envoi de
messages est trivialisé d’autant que le paramètre blocking est facultatif. Il
suffit juste de donner le nom de l’agent ( à condition bien entendu qu’il soit
dans le conteneur ) et de passer le message entre les deux balises de
sendObject.
Malheureusement, nous ne sommes pas parvenu à faire passer des objets
dans sendObject mais uniquement des chaînes de caractères. Mail nul doute
que par la suite, cette balise sera améliorée afin de répondre à la demande
initiale.
37
Expériences acquises lors du stage
Un projet basé sur différentes technologies
Ce projet a présenté quelques difficultés notamment au niveau de la
grande variété de technologies employées. Par technologie, j’entends
les différents langages utilisés ( java, html, XML, Jsp ), mais également
les différents supports logiciels ( netbeans dans un premier temps,
tomcat , jade).
La multiplicité des langages et des supports
Ce projet a nécessité l’utilisation de plusieurs langages ce qui présente la
grande difficulté de brouiller les piste lors d’éventuel débugage. La quantité de
paramètres susceptibles d’être modifiés est du coup très importante. Or s’il
existe une multitude de spécialistes en java, en XML, en html ( mais ça ce
n’est pas trop grave ) en jsp, mais il y a pas ou très peu en ce qui concerne le
mélange de tout ça, à savoir, les taglibs (à part peut être aujourd’hui un
certain monsieur Le Berre et son stagiaire).
Il est donc ardu de trouver une solution à certains problèmes alors qu’on ne
sait même pas où se trouve l’erreur : configuration de tomcat, erreur dans le
code java, erreur dans le fichier tld …
Je fus d’ailleurs parfois amené à prendre des décisions hasardeuses qui
finalement aggravaient la situation. D’autant que la documentation est parfois
difficile à interpréter pour un non spécialiste, voir pour ce qui est des
documents en anglais, intraduisible.
Après ces erreurs, et surtout après ce stage, je pense qu’il est de toute façon
impossible de maîtriser totalement tous les paramètres avant de se lancer
dans un tel projet. Par contre, je pense qu’il ne faut pas avoir peur de poser
des questions à son entourage (informatique) et que même les questions les
plus simples peuvent parfois apporter des solutions insoupçonnées.
J’ai préféré au début du stage m’isoler pour mieux chercher et je ne doute
plus maintenant qu’il faut s’entourer pour mieux isoler le problème.
38
Expériences acquises lors du stage (2)
Les exemples plutôt que la théorie
Utilisation de l’existant
En se lançant dans ce projet, j’ai découvert l’existence de bibliothèques de
balises en open source dans le projet jakarta. Ces jakarta taglibs m’ont
notamment de support pour la compréhension du fonctionnement des taglibs
en général.
Le langage Jsp comprend déjà des balises toutes faites et c’est en observant
le fonctionnement de la balise <jsp :useBean …> que nous avons chercher à
développer la balise <jade :useAgent …> . Cependant le code de cette balise
n’étant pas disponible ( open source ) nous nous sommes reporté sur lle
projet Jakarta qui implémentait sa propre balise <Jlib :useBean …>. Et c’est
principalement à partir de celle-ci que fut donc développée la balise
<jade :useAgent
…>
première
brique
de
notre
bibliothèque.
Malheureusement, le code source de cette balise était « buggué » et nous a
beaucoup gêné dans notre travail.
Ensuite les deux autres balises <jade :container …> <jade :sendObject …>
s’inspirèrent de la structure de la première bien que des différences notables
furent rencontrées dans ces deux travaux.
Je pense qu’il est intéressant de noter que la première balise a pris beaucoup
plus de temps à être implémentée que la dernière. En effet, toute la
problématique de ce projet ne résidait pas dans la quantité de code à fournir
mais plutôt dans sa qualité.
Danger du préfabriqué
L’utilisation de l’existant est une démarche qui présente de grands avantages
ne serait que par l’expérience apportée par un projet réalisé. Le fait d’avoir un
exemple qui fonctionne permet de modifier petit à petit celui ci et d’analyser
ainsi le comportement de divers paramètres.
Cependant, cette méthode présente également des désagréments et
demande une certaine retenue pour ne pas tomber dans des pièges
« indébuggables ». Le problème de la version peut parfois être fatal à qui
s’aventure aveuglément. En effet il existe plusieurs qualificatifs pour les
versions de code disponibles en open source : de release à nightly, on
39
passe de la version « garantie sans failles » ou presque à la version
« garantie pleine de failles » ou presque. Ignorer ce paramètre lorsque l’on
utilise du code open source revient à prendre un maximum de risque inutiles.
Nous avons été amenés notamment pour ce qui concerne les Jakarta taglibs
à utiliser une version nightly qui s’est avérée presque fiable (mais pas
totalement malheureusement ce qui a occasionné quelques problèmes de
débuggage).
De plus lorsque l’on utilise l’existant, sauf cas exceptionnel, on se base sur
des cas légèrement différents. Certains paramètres sont volontairement
ignorés car inutiles pour le cas traité alors que nous en avons besoin pour
notre cas précis. Ou certaines mesures implicites pour le programmeur du
modèle utilisée n’apparaissent pas clairement dans la démarche et passe
ainsi à la trappe dans notre analyse. Ce fut par exemple le cas des
TEIclasses, permettant de réutiliser l’objet créé dans les balises, dans le code
Jsp de la page. Ce ne fut que tardivement que je compris l’utilité de celles-ci
alors que je les avaient aperçues depuis le début sans en saisir le
fonctionnement.
Le but de ce stage étant de créer des briques réutilisables pour l’univers de
Jade, j’espère que les utilisateurs sauront tirer profit de ces quelques balises.
Et surtout j’espère que d’autres balises seront créées afin de développer cette
bibliothèque open source.
40
Expériences acquises lors du stage(3)
Un Projet Open Source
Qui à la fac n’a jamais entendu parler de projet Open Source ? En tout
cas, qui a eu l’occasion d’aller dans les cours de Mr Le Berre ou de
certain de ses collègues ne pourra nier l’existence du concept.
L’open Source est un système de gestion de droit qui permet de partager les
sources de ses programmes avec toute sorte d’utilisateurs. L’intérêt majeur, et
c’est sans doute celui que recherche Jade, est d’avoir accès à une
communauté de programmeurs gigantesque. Ainsi, chacun peut apporter sa
pierre à l’édifice d’un projet open source sans pour autant être proche des
initiateurs du projet.
Un problème de licence
La gestion des droits d’un programme se fait par le biais du système des
licences. Dans le cadre de l’open source, la licence la plus connue est la
licence GNU/GPL, mais il existe une autre licence : la licence GNU/LGPL.
Cette licence a été introduite pour adoucir certaines conditions de la licence
GNU/GPL qui s'avéraient trop restrictives dans certains cas.
La licence GNU/LGPL permet en effet de rendre libre une bibliothèque de
logiciels sans obliger l'auteur de programmes utilisant cette bibliothèque à
rendre également libre son programme. La licence GNU/LGPL supprime
l'effet de « contamination » de la licence GNU/GPL.
Licence Publique Générale GNU Limitée
Les licences d'utilisation de la plupart des programmes sont définies pour
limiter ou supprimer toute liberté à l'utilisateur. À l'inverse, les Licences
Publiques Générales GNU (GNU General Public Licenses) sont destinées à
garantir la liberté de partager et de modifier les logiciels libres, et de s'assurer
que ces logiciels sont effectivement accessibles à tout utilisateur.
41
Cette licence, la Licence Publique Générale Limitée, s'applique à certains
programmes de la Free Software Foundation, typiquement les bibliothèques,
comme à tout autre programme dont l'auteur l'aura décidé.
Liberté des logiciels ne signifie pas nécessairement gratuité. Les Licences
Publiques Générales sont conçues pour assurer la liberté de distribuer des
copies des programmes, gratuitement ou non, de recevoir le code source ou
de pouvoir l'obtenir, de modifier les programmes ou d'en utiliser des éléments
dans de nouveaux programmes libres, en sachant que vous y êtes autorisé.
La bibliothèque de balises créée lors de ce projet est désormais sous licence
LGPL. Elle participe au projet Jade et doit être insérée dans la nouvelle
version de Jade 2.6 ( juin 2002 )…
42
Conclusion
Ce projet fut pour moi très enrichissant tant au point de vue des
connaissances informatiques, qu’au point de vue de la méthode de
travail et qu’au point de vue humain.
La première partie de ce rapport démontre clairement l’étendue des
domaines de connaissance parcourus. C’est aussi une révélation
flagrante de tout ce qui reste à parcourir. Et c’est à mon sens une
motivation supplémentaire pour poursuivre des études supérieures.
Quant aux méthodes de travail utilisées, elles furent tantôt chaotiques,
tantôt efficaces, tantôt laborieuses et tantôt dynamisantes. Je crois que
le fait de m’être parfois égaré m’a permis d’apprécier d’autant plus les
instants de trouvailles ou de réussites. En tout cas je ne travaillerai plus
de la même manière sur un tel projet.
L’aspect humain reste cependant une des principales leçons que je
retiendrais de ce stage. Sans l’apport considérable de Mr Daniel Le
Berre et par son intermédiaire de Mr Fabio Bellifemine (Jade), je pense
que je ne serai jamais parvenu à mener ce projet à termes. Aussi je les
en remercie et je suis très heureux d’avoir grâce à eux participé à mon
premier projet Open Source.
43
Annexe technique
Glossaire
ACL
Agent Communication Langage : Langage de communication qui combine
habilement KQML et KIF. KQML est pris pour la partie administrative et KIF
pour la représentation des données et/ou expressions à évaluer.
API
Application Programming Interface : Bibliothèques d'objets (dans le cas de
langages objets) qui permettent au programmeur d'utiliser directement des
objets. L'API réseau du Java permet d'ouvrir des sockets, mais aussi de gérer
les adresses IP ainsi que les URL.
CORBA
Common Object Request Brocker Architecture : Une architecture définie par
l'OMG qui permet l'implémentation d'objets distribués. Ces objets sont
accessibles par l'intermédiaire de nombreux langages grâce à la définition
d'IDL.
Framework
Ensemble d'outils (de conception, d'exécution, de dégage) qui permettent de
faire quelque chose, par exemple de mettre en œuvre d'autres programmes.
Ces outils peuvent êtres des programmes, des méthodes de travail, des
librairie, etc.
IDL
Interface Definition Language : Un langage qui permet de définir les objets
CORBA. Une Interface IDL déclare les opération, exceptions et attributs. IDL
ne permet pas d'implémenter les objets, comme son nom l'indique, il ne fait
que définir les interfaces des objets.
Java / JDK
Java, langage créé en 1995 par Sun, ce langage est orienté
objet et présente le gros avantage d'être portable. JDK (Java
Développement Kit) est le kit de développement Java fournis
par Sun pour le développement de programmes Java.
KIF
44
Knowledge Interchange Format : Langage qui permet de coder des
expressions, algorithmes ou données dans le plus pur style Lisp : 3+5 deviens
(+ 3 5)
KQML
Knowledge Query Modeling Langage, ce langage est le standard de fait pour
l'échange d'information entre les agents. (Pour s'en persuader, il suffit de
regarder la liste des produits déjà existants).
MOM
Message Oriented Middleware : Middleware orienté message, c'est un
middleware qui contrairement à CORBA ou RMI ne permet pas l'appel de
méthodes à distances, mais seulement l'échange de messages. Un MOM
peut aussi contenir des services.
ORB
Object Request Broquer : Les librairies, processus et autres infrastructures qui
permettent, dans un environnement distribué CORBA, aux objets de
communiquer entre eux. L'ORB permet aux objets qui demandent des
services d'entrer en contact avec les objets qui fournissent ces services.
OSI
Open System Interconnection : Le modèle OSI est composée de 7 niveaux.
Ces niveaux sont organisés de manière hiérarchiques. Les niveaux sont
définis de telle sorte qu'une modification dans un niveau ne nécessite pas de
modification dans les autres niveaux.
Proxy
Objet et/ou programme qui permet d'accéder à des ressources qui ne sont
pas accessibles directement, c'est donc un intermédiaire. L'utilisation d'un
proxy est en général de protéger la ressource à laquelle on veut accéder.
RMI
Remote Method Invocation est une technique qui permet à des objets Java de
se servir d'objets Java distants comme s'il s'agissait d'objet local. L'équivalent
en C/C++ est RPC (Remote Procedure Call). CORBA fournis les mêmes
fonctionnalité, mais présente l'avantage de ne pas être réduit à un seul
langage.
45
Socket
Objet qui permet de communiquer sur un réseau de type TCP/IP. La création
d'une socket nécessite un serveur sur lequel on se connecte et un client qui
se connecte à se serveur. Les deux peuvent ensuite communiquer, c'est à
dire, envoyer et recevoir des suites d'octets. La définition d'un protocole de
communication est donc indispensable.
Thread
Programme qui s'exécute à l'intérieur d'un autre programme : ceci permet à
un programme de faire plusieurs choses en même temps. Un thread est
parfois appelé tâche.
UDP
User Datagram Protocol : Protocole en dessous de TCP/IP sur le modèle OSI.
Ce protocole ne garantie pas l'arrivée des données (datagrams), ni leur ordre
d'arrivée.
FIPA
est une organisation à but non lucratif produisant des normes pour l'inter
opérabilité des agents hétérogènes de logiciel.
www.fipa.org