RPUBLIQUE ALGRIENNE DMOCRATIQUE ET POPULAIREMINISTRE DE LENSEIGNEMENT

SUPRIEUR ET DE LA RECHERCHE SCIENTIFIQUE UNIVERSIT DE LA SCIENCE ET DE LA

TECHNOLOGIE DORANMOHAMED BOUDIAF FACULT DES MATHMATIQUES ET
INFORMATIQUE

Client/serveur vs agent
mobile

Prsent par :
Mahiaoui oussama
Khalfa amine

Introduction :
L'volution des rseaux grande chelle a permis la naissance d'un grand nombre de
nouvelles applications qui se dveloppent autour de ce type de rseau : commerce
lectronique, recherche d'information sur le web, plate-forme pour calcul rparti, etc.
Ces applications sont formes par des entits rparties et la bonne fonctionnalit ncessite la
communication et les changes entre ces entits. Aujourd'hui, le modle "client/serveur" o
les changes se font par des appels distants travers le rseau est le modle le plus utilis.
Dans ce modle, seul le client reprsente une application au sens propre du terme et le rle du
serveur est de rpondre aux demandes des clients. Le serveur construit ses rponses
indpendamment du client, ainsi une partie des donnes envoyes est inutile augmentant ainsi
le trafic sur le rseau. De plus modle exige une connexion permanente entre le client et le
serveur, ce qui n'est pas le cas des terminaux mobiles qui sont exposs la perte de la
connexion. Dans cet article nous proposons une nouvelle approche qui utilise les agents
mobiles. Ces agents sont des entits qui se dplacent d'une machine une autre sur le rseau,
sans perdre leurs codes ni leurs tats. Ainsi, en envoyant les agents l o les tches se font, les
messages changs deviennent locaux et librent d'autant la charge du rseau.
Une des applications les plus importantes dans le domaine des agents mobiles est la recherche
d'informations sur le Web. Dans ces applications (recherche des htels, rservation d'un billet
d'avion, etc...), des agents se dplacent sur diffrents sites pour rechercher des informations
pour leurs clients. De nombreux travaux ont t labors afin d'introduire la technologie
d'agents mobiles et les concepts lis cette dernire pour la recherche d'information dans des
environnements dynamiques. Le concept d'agent mobile apparat dans ce contexte comme une
solution facilitant la mise en uvre d'applications rparties.

Larchitecture Client /serveur :

Dfinition :
Larchitecture client /serveur est un modle de fonctionnement de logiciel qui peut se raliser sur tout
type darchitecture matrielle partir du moment o ces architectures peuvent tre interconnectes.
On parle de fonctionnement logiciel dans la mesure o cette architecture est base
sur l'utilisation de deux types de logiciels, savoir un logiciel serveur et un logiciel client
s'excutant normalement sur 2 machines diffrentes.
L'lment important dans cette architecture est l'utilisation de mcanismes de communication entre
les 2 applications.

FIGURE 1

: EXEMPLE DARCHITECTURE C/S

Architecture rseau :
Architecture deux niveaux :
L'architecture deux niveaux (aussi appele architecture 2-tier, tier signifiant range en anglais)
caractrise les systmes clients/serveurs pour lesquels le client demande une ressource et le serveur la
lui fournit directement, en utilisant ses propres ressources. Cela signifie que le serveur ne fait pas
appel une autre application afin de fournir une partie du service.

FIGURE 2

: ARCHITECTURE A DEUX NIVEAU

Architecture 3 niveaux :
Dans l'architecture 3 niveaux (appele architecture 3-tier), il existe un niveau intermdiaire, c'est-dire que l'on a gnralement une architecture partage entre :
a. Un client, c'est--dire l'ordinateur demandeur de ressources, quipe d'une interface utilisateur
(gnralement un navigateur web) charge de la prsentation ;
b. Le serveur d'application (appel galement middleware), charg de fournir la ressource mais
faisant appel un autre serveur
c. Le serveur de donnes, fournissant au serveur d'application les donnes dont il a besoin.

FIGURE 3

: ARCHITECTURE A TROIS NIVEAU

Avantage :
Le modle client/serveur est particulirement recommand pour des rseaux ncessitant un grand
niveau de fiabilit, ses principaux atouts sont :

des ressources centralises : tant donn que le serveur est au centre du rseau, il peut grer des
ressources communes tous les utilisateurs, comme par exemple une base de donnes centralise,
afin d'viter les problmes de redondance et de contradiction
une meilleure scurit : car le nombre de points d'entre permettant l'accs aux donnes est moins
important
une administration au niveau serveur : les clients ayant peu d'importance dans ce modle, ils ont
moins besoin d'tre administrs
un rseau volutif : grce cette architecture il est possible de supprimer ou rajouter des clients
sans perturber le fonctionnement du rseau et sans modification majeure

Inconvnient :
L'architecture client/serveur a tout de mme quelques lacunes parmi lesquelles :

un cot lev d la technicit du serveur

un maillon faible : le serveur est le seul maillon faible du rseau client/serveur, tant donn que
tout le rseau est architectur autour de lui ! Heureusement, le serveur a une grande tolrance aux
pannes (notamment grce au systme RAID).

Exemple en client/serveur :
Grace la gnration dinternet, tout le monde a connait le modle client/serveur vous
demander une page HTML est le serveur vous lenvoie. Le serveur peut aussi calculer votre
page .Pour comparer les prix de plusieurs magasins, vous devez trouver les sites, vous
rendre sur chacun deux, effectuer vos recherches et noter ce que vous y trouvez. Une telle
dmarche prend un temps que beaucoup jugeront trop lev. Une solution consiste ajouter
un intermdiaire : un mta moteur de recherche qui gre le commerce lectronique Il va
interroger pour vous chaque magasin. Il en connait les langages dinterrogation et les
critres proposs. Aprs quelques instants de recherche, vous aurez la liste des dix modles
les moins chers.
Cette solution prsente encore dimportantes contraintes. La machine cliente doit tre
connecte pendant toute la recherche, elle se charge de tous les calculs et le trafic sur le
rseau est maximal : la requte est envoye chaque fois et les serveurs renvoient tous leur
page complte de rsultats.
Si lon dplace le meta moteur sur un site Web, le client se trouve alors dans une situation
beaucoup plus intressantes : la requte est envoye une seule fois et un
Nombre restreint de rsultats est renvoye. Mais finalement, nous ne faisons que dplacer le
problme. Le serveur du site qui fera les recherches rencontrera les mmes contraintes. Un
autre type darchitecture est donc envisager. Nous allons voir comment les agents mobiles
Peuvent rpondre ce type de problme.

FIGURE 4

: EXEMPLE CLIENT/SERVEUR

Les agents mobiles :

Le concept d'agent est issu du monde de L'I.A Concept largement tudi dans la
littrature et Il existe de nombreuses dfinitions ;
]

Dfinition [Russel et norving ,2003] :

Un agent est une entit qui peut tre vue comme percevant son environnement travers des
capteurs et qui agit sur cet environnement au travers des capteurs.

iDfinition [Boussard 2008] :

o [Bou
Un agent est une entit autonome plonge dans un environnement et capable de percevoir
et d'interagir avec celui-ci dans le but de satisfaire ses objectifs.

Modle agents mobiles

De nombreux systmes agents mobiles ont t dvelopps ces dernires annes.
Des exemples sont les systmes AgentTcl [GRA 96], Telescript [WHI 94], Aglets [LAN 97a]
[LAN98a] [VEN 97], Mole [BAU 98] ou MOA [MIL 98].
Une grande partie de ces systmes sont construits sur l'environnement Java [GOS 95],
principalement en raison de sa forte diffusion dans le monde, mais aussi de ses avantages
techniques:
masquage de l'htrognit des machines
typage fort pour la scurit.

Fonctions des agents mobiles

Un agent est compos de son code correspondant un algorithme, ainsi que d'un contexte
incluant des donnes. Ce contexte peut voluer en cours d'excution, par exemple en
collectant des donnes lorsqu'un agent ralise une recherche d'information sur un ensemble
de serveurs. Le code et le contexte de l'agent sont dplacs avec l'agent lorsque celui-ci
visite diffrents serveurs.
Lorsqu'un agent se dplace vers un serveur, il doit poursuivre son excution sur le site
destination. La plupart des systmes agents mobiles implantent une migration faible1,
c'est--dire une fonction de migration o l'agent redmarre son En particulier ceux construits
sur Java qui ne fournit pas un mcanisme de migration de processus lger.
Excution depuis le dbut. En consquence, le programmeur doit inclure dans le contexte de
l'agent des informations sur l'tat de l'excution, et lorsque l'agent redmarre sur un site, le
code de l'agent doit vrifier l'tat de l'excution et se brancher sur la partie de l'algorithme
devant tre excute sur ce site. Un systme agents fournit en gnral des primitives de
communication permettant aux agents d'interagir entre eux, mais aussi aux agents d'interagir
avec les serveurs qu'ils visitent. Ces primitives de communication prennent la forme d'envois
de messages ou d'appels de procdures ou de mthodes.

Domaine dapplication
Les agents mobiles sont utiliss pour adapter aux besoins des clients un service fourni par
un serveur. Nous supposons que l'objectif du serveur est de fournir un service gnrique
pouvant rpondre aux besoins varis de tous ses clients potentiels.
Afin de fournir un service gnrique, le serveur peut exporter une interface paramtrable,
mais la complexit de cette interface augmente avec la diversit des utilisations possibles du
service. De plus, il est difficile d'identifier les besoins potentiels de tous les clients. Une autre
approche consiste dcomposer le service en un ensemble d'oprations lmentaires, plus
simples, pouvant tre appeles indpendamment les unes des autres. Un client peut alors
combiner les appels ces oprations lmentaires afin d'obtenir le service dsir.
La deuxime approche est prfrable, car elle permet d'offrir un service gnrique sans
forcment connatre l'avance les besoins des clients. Par contre, elle ncessite des
interactions plus frquentes entre le client et le serveur. Dans le cadre d'une architecture
rpartie fonde sur le modle client/serveur, les interactions distance cotent cher et la
gnricit devient alors trs pnalisante. Une solution consiste alors co-localiser une partie
de l'application cliente et le service gnrique fourni par le serveur, afin de limiter les
interactions distance.
C'est ce principe qui a motiv les travaux autour des extensions de systmes d'exploitation
(Spin [BER 95], Exokernel [ENG 95]). Un service systme gnrique ncessite de nombreux
appels systmes qui sont coteux. Les systmes extensibles excutent une partie de
l'application dans le mme espace d'adressage que le systme d'exploitation, afin de rduire
le cot des appels au systme par cette partie de l'application. Nous nous proposons
d'appliquer cette technique en utilisant des agents mobiles dans le cadre d'applications
rparties utilisant des serveurs d'information.
En utilisant des agents mobiles, un client peut dvelopper un service spcialis en fonction
de ses besoins en s'appuyant sur le service gnrique fourni par le serveur. Le service
spcialis du client peut tre envoy sur le site du serveur sous la forme d'un agent mobile,
ce qui implique que les interactions entre le service spcialis et le service gnrique seront
des appels locaux sur la machine serveur. La figure 1 illustre ce schma.

FIGURE 1.

Le schma exprime un rapprochement entre un client et un serveur.

Cette ide de rapprocher le traitement des donnes qui se trouvent dans un site de stockage
pour gagner en performance n'est pas nouvelle. Elle a t exploite dans le domaine
des bases de donnes, dans le cas d'une requte SQL dont l'excution ncessite le
parcours d'une base de donnes de taille importante. Dans ce cas, le code du client
est dplac vers le serveur de la base de donnes, car dplacer du code entre des
machines est plus rentable que dplacer des donnes entre ces machines.

FIGURE 2.

Exemples base dagents mobiles :

Dans un modle agents mobiles, le client nexcute plus toutes les tches, il dlgue le
travail. On considre ici lagent mobile comme un ensemble code/donnes autonome et
capable de se dplacer entre les diffrents environnements dexcution des machines htes
dun rseau
Tout ce qui est fait en mode client/serveur pourra tre fait avec des agents mobiles. Une
partie des applications ne ncessiteront pas ce nouveau modle, mais certaines se
rvleront plus efficaces en lutilisant. Voici
Quelques exemples :
la collecte dinformations avec filtrage (personnalisation de recherche) ;
la surveillance (si tel vnement se produit sur le rseau, alors lagent prvient le
client) ;
la distribution dinformations (les donnes ne partent quune seule fois) ;
la ngociation (lagent part avec une offre du client

et revient avec le meilleur prix obtenu) ;

le calcul parallle (lagent peut se dupliquer sur diffrent serveurs avec les diffrentes
parties dun calcul effectuer).

FIGURE 3.

Implmentations :

Chaque implmentation des agents mobiles prsente ses spcificits, ses avantages et ses
inconvnients. Nous allons ici en citer deux, parmi les plus connus.
Telescript de General Magic est connu pour tre la premire implmentation commerciale des agents
mobiles.
Il sagit dun langage interprte que GeneralMagic a remplac par Odyssey (bas sur Java). On y
trouve,
En plus du concept dagent, les notions suivantes : places (lieux virtuels), travel (pour aller
de place en place), meetings (quand deux agents se rencontrent sur une place), connections
(quand deux agents ne sont pas sur la mme place et quils communiquent), autorits (pour
ddfinir le niveau dautorisation) et permits (possibilits dexcuter des instructions ou
daccder `a des ressources).
Le plus connu des projets du monde Java nous vient de chez IBM Japon, il sagit dAglets . Ce nom a t
cre partir des mots Agent et Applet, ce qui exprime assez clairement ce quest Aglet. Pour crer un
agent

mobile avec Aglets, il suffit dcrire une classe qui tende la classe Aglet. Cette classe
dispose de mthodes dfinir telles que onCreation, onArrival, onDisposing, etc. On a donc
affaire des objets Java (srialisables et clonables) qui ont en plus la facult de se dplacer.

Mcanismes de Java utiliss :

les principaux mcanismes de Java sont les suivants :
Mobilit et portabilit du code. Une des proprits essentielles de Java est que
le code gnr par le compilateur Java est mobile. Ceci signifie que le code peut tre
dplac entre diffrentes machines. La mobilit du code ncessite que le code soit
portable. La portabilit du code produit par Java provient du fait que le code (appel
byte code) est indpendant de toute architecture de machine et qu'il est interprt par
la JVM. Afin de permettre la mobilit du code, Java fournit la notion de chargeur de
classe2 (ClassLoader). Il est possible de dfinir des chargeurs spcifiques aux
applications. Un chargeur est appel par la JVM chaque fois que celle-ci doit traduire
un nom de classe en rfrence Java l'objet classe associ. Si la classe n'est pas dj
charge, le chargeur est responsable du chargement de la classe partir d'une source
de donnes (disque ou machine distante). Plus prcisment, le chargeur appel pour
traduire le nom dune classe incluse dans une classe C est le chargeur qui a charg la
classe C. Ainsi, en chargeant une premire classe en utilisant explicitement un
chargeur, toutes les classes accessibles depuis cette classe seront charges par ce
mme chargeur. La notion de chargeur permet donc la fois de charger des classes
depuis des sources de donnes quelconques, et de dfinir des espaces de noms de
classes diffrents (un par chargeur).
Liaison dynamique. La liaison dynamique est un aspect crucial pour l'utilisation
de code mobile. La liaison dynamique signifie ici la possibilit de ne dterminer que
lors de l'excution le code qui sera excut pour un appel de mthode. Etant donn
que Java permet le chargement dynamique des classes, une variable d'un type donn
(une interface en Java) peut contenir une rfrence Java pointant sur une instance
dont la classe a t charge dynamiquement. Java retarde la liaison du code partir
de cette variable jusqu' l'appel effectif, permettant ainsi l'excution de code charg
dynamiquement.
Srialisation. Java fournit un mcanisme de srialisation d'objets [RIG 96] permettan
d'changer les instances entre des JVM diffrentes. Ce mcanisme permet
de traduire un graphe d'objets Java en un flot d'octets qui peut tre redirig vers un
fichier ou vers une autre machine travers le rseau. Pour quune instance soit
srialisable, il faut que sa classe implante linterface Serializable. La srialisation
dune instance revient crire tous ses champs dans le flot doctets. Lorsquun de
ses champs est une rfrence un autre objet, lobjet rfrenc est aussi srialis.
Afin de spcialiser le processus de srialisation, Java permet de dfinir dans une
classe une mthode writeObject qui surcharge le mcanisme de srialisation pour les
instances de cette classe. Cette mthode doit dfinir les champs de l'objet qui doivent
tre crits et permet notamment de contrler le graphe d'objets suivant lequel la
srialisation doit se propager. La d-srialisation est le processus inverse de la
srialisation. Le graphe d'objets peut tre reconstruit partir du flot d'octets obtenu
par srialisation (la mthode permettant la surcharge est readObject).
Dans la sous-section suivante, nous dcrivons comment ces mcanismes ont t
utiliss dans la ralisation de notre plate-forme.

Avantages et inconvnients
En pratique, la mobilit d'agent permet de rapprocher client et serveur et en consquence de
rduire le nombre et le volume des interactions distantes (en les remplaants par des
interactions locales), de spcialiser des serveurs distants ou de dporter la charge de calcul

d'un site un autre. Une application construite base d'agents mobiles peut se redployer
dynamiquement suivant un plan pr-tablit ou en raction une situation particulire, afin
par exemple d'amliorer la performance ou de satisfaire la tolrance aux pannes, de rduire
le trafic sur le rseau, ou de suivre un composant matriel mobile. La mobilit du code offre
un premier niveau de flexibilit aux applications. La dcentralisation de la connaissance et
du contrle travers les agents, et la proximit physique entre les agents et les ressources
du systme renforce la ractivit et les capacits d'adaptation.
La mobilit ne se substitue pas aux capacits de communication des agents (la
communication distante reste possible) mais les complte ; afin de satisfaire aux contraintes
des rseaux de grande taille ou sans fil (latence, non permanence des liens de
communication), les agents communiquent par messages asynchrones le plus souvent.
Les agents mobiles, bien qu'ils connaissent quelques difficults, restent une architecture
approprie pour la manipulation de grands volumes de donnes notamment des donnes
multimdia.

Conclusion :
Chaque architecture a ses avantages et inconvnients, et en terme doccupation de la bande passante
limplmentation de larchitecture agent mobile et favorable.

Bibliographie :
http://sd-41336.dedibox.fr/hagimont/publications/tsi-agents-00.pdf
http://superdea1.free.fr/cours/Agent_Mobile.pdf
http://ceur-ws.org/Vol-547/19.pdf