Une premi`ere question que l’on peut se poser `a ce stade est de savoir pourquoi combiner les services web avec une architecture peer-to-peer. En effet, bien que ces deux concepts traitent de syst`emes distribu´es, les services web respectent une architecture client/ser-veur tandis que les architectures P2P adressent des architectures totalement d´ecentralis´ees.
Aussi, la combinaison de ces deux technologies qui ´evoluent chaque jour permettra `a cha-cune d’h´eriter des avantages de l’autre mais ´egalement de ses inconv´enients. D`es lors, cette section donnera un aper¸cu de ce qu’une architecture P2P peut apprendre des services web, de ce que les services web peuvent tirer d’une architecture P2P mais ´egalement des diff´erents inconv´enients pouvant apparaˆıtre lors de la combinaison de ces deux technologies.
5.2.1 Les avantages
Les apports des services web ainsi que ceux d’une architecture P2P sont inh´erents aux diff´erentes qualit´es de ceux-ci. Un aper¸cu de ces apports est d´ecrit ci-dessous :
XML : comme pr´ecis´e dans le chapitre2portant sur les services web, ces derniers utilisent de mani`ere assez significative la technologie XML. Celle-ci, notamment utilis´ee pour la repr´esentation de types donn´ees neutres aux diff´erents langages de programmation par l’interm´ediaire des sch´emas XML, permettra au diff´erents noeuds d’une architec-ture P2P de s’´echanger les informations concernant la maintenance de la couche de routage, tout en permettant une divergence dans le langage de programmation uti-lis´e pour l’impl´ementation de ces peers. Cette technologie, pouvant facilement ˆetre modifi´ee via l’utilisation de modules sp´ecialis´es tels que WS-security, permettra `a l’ar-chitecture P2P d’en b´en´eficier. Ainsi, les m´ecanismes de s´ecurit´e XML permettent d’assurer un certain degr´e de s´ecurit´e `a l’int´erieur de r´eseaux P2P.
L’interop´erabilit´e : l’un des grands buts des services web est d’ˆetre le plus ouvert et interop´erable possible. Ainsi, une interface standardis´ee d´ecrite via WSDL peut ˆetre utilis´ee `a chaque noeud, permettant ainsi `a n’importe quel syst`eme capable de traiter du XML de communiquer avec une peer du r´eseau. De plus, l’utilisation des services web dans une architecture P2P permet de faire disparaˆıtre les barri`eres telles que le langage de programmation ou encore le syst`eme d’exploitation utilis´e.
La s´ecurit´e : plusieurs m´ecanismes ont ´et´e d´evelopp´es afin d’introduire un certain niveau de s´ecurit´e au niveau des services web. Les diff´erents noeuds d’un r´eseau P2P pour-ront donc b´en´eficier de m´ecanismes tels que les modules de s´ecurit´e XML ou encore d’une communication s´ecuris´ee grˆace `a HTTPS.
Le choix du protocole de transport : les services web n’´etant pas limit´es `a un seul protocole de transport, une architecture P2P construite au-dessus de ceux-ci aura donc le choix entre plusieurs protocoles tels que HTTP, SMTP, ... N´eanmoins, l’uti-lisation du protocole HTTP permettra au r´eseau P2P de s’´etendre sur Internet en fonctionnant `a travers les firewalls.
La d´ecentralisation : les services web s’appliquent `a des communications serveur/client.
N´eanmoins, une peer joue ces deux rˆoles en ´etant tantˆot le serveur dans une commu-nication avec une peer A tantˆot le client dans une communication avec une peer B. Dans ce sens, l’utilisation des services web dans une architecture peer-to-peer per-mettra donc une d´ecentralisation des services web.
UDDI distribu´e : la technologie UDDI trait´ee dans le chapitre sur les services web est initialement pr´evue pour fonctionner de mani`ere centralis´ee. N´eanmoins, la d´ecentralisation de cette technologie est un domaine actif de recherche. Ainsi, quelques exemples de travaux concernant cette d´ecentralisation `a l’aide d’une architecture P2P peuvent ˆetre trouv´es dans les r´ef´erences [35,38, 37, 47].
5.2.2 Les inconv´ enients
La combinaison de ces deux technologies n’apporte malheureusement pas que des avan-tages. En effet, un aper¸cu des inconv´enients pouvant apparaˆıtre lors de la combinaison de ces derni`eres est donn´e ci-dessous :
Utilisation de la bande passante : la technologie XML ´etant utilis´ee afin de repr´esenter les messages, celle-ci est de poids plus important, n´ecessitant ainsi plus de bande passante. De plus, la synchronisation fr´equente des diff´erentes peers ´etant un point crucial dans la maintenance de la structure de routage P2P, un tel r´eseau g´en`ere par d´efaut beaucoup de trafic. Ainsi, une conjonction de ces deux facteurs implique logiquement une augmentation de la bande passante utilis´ee.
La s´ecurit´e : bien que la s´ecurit´e soit un sujet tr`es important dans une architecture P2P, elle constitue toutefois son point faible. En effet, mˆeme si l’utilisation de la s´ecurit´e apport´ee par les services web accroˆıt le degr´e g´en´eral de s´ecurit´e, celle-ci n’a pas
encore atteint sa phase de maturit´e. De plus, la gestion des diff´erents droits d’acc`es des noeuds d’un r´eseau P2P est plus complexe que celle d’une architecture centralis´ee.
La maintenance difficile et une architecture complexe : un effet n´egatif d’une ar-chitecture d´ecentralis´ee, que ce soit avec ou sans services web, est son architecture complexe inh´erente d´ecoulant des difficult´es de s´ecurit´e ainsi que de l’utilisation de ressources distribu´ees. La maintenance de telles applications est ´egalement complexe
´etant donn´e la difficult´e d’identifier et de r´eparer la ressource d´efaillante dans le r´eseau P2P.