Web Services : Beyond the peer-to-peer architecture

Faculté des Sciences Département d Informatique Web Services : Beyond the peer-to-peer architecture Jérémy De Roey Mémoire présenté sous la direction du Professeur Esteban Zimányi et de Ir. François Deliège en vue de l obtention du grade de Licencié en Informatique Année académique 2006 2007 MEMBRE DE L ACADÉMIE UNIVERSITAIRE WALLONIE-BRUXELLES ET DU PÔLE UNIVERSITAIRE EUROPÉEN BRUXELLES WALLONIE

Remerciements Je tiens à adresser mes remerciements à toutes les personnes qui ont contribué à la bonne réalisation de ce mémoire : le Professeur Esteban Zimányi, mon directeur de mémoire, pour ses encouragements, ses nombreux conseils ainsi que ses relectures qui ont permis de mener à bien ce mémoire, mon co-directeur de mémoire, Ir. François Deliège, pour ses nombreux conseils et orientations lors de mon Erasmus au Danemark, les membres du jury qui prendront le temps de lire mon travail et de l évaluer, toutes les personnes de l Université Libre de Bruxelles et de l Université d Aalborg qui ont permis la réalisation ainsi que l organisation de mon Erasmus au Danemark, ma famille, ma compagne Sylvie et mes amis pour leur soutien et leurs encouragements, ainsi que ma future belle-mère pour ses relectures et corrections. ii

Table des matières 1 Introduction 1 1.1 Motivation.................................... 1 1.2 Structure du document............................. 2 2 Services web 4 2.1 Introduction................................... 4 2.2 Définition.................................... 5 2.3 La composition de services web........................ 7 2.4 Avantages et inconvénients........................... 8 2.5 Les services web dans l industrie........................ 9 2.6 Aspects techniques............................... 11 2.6.1 Scénario général de fonctionnement.................. 12 2.6.2 XML................................... 13 2.6.3 SOAP.................................. 15 2.6.4 WSDL.................................. 19 2.6.5 UDDI.................................. 20 2.6.6 WS-BPEL................................ 23 2.7 Sécurité..................................... 23 2.7.1 Sécurisation de la connexion...................... 24 2.7.2 XML Signature............................. 25 2.7.3 XML Encryption............................ 26 2.7.4 XKMS.................................. 27 2.7.5 SAML.................................. 29 iii

TABLE DES MATIÈRES 2.7.6 XACML................................. 29 2.7.7 WS-Security............................... 30 2.7.8 Autres spécifications basées sur WS-Security............. 31 3 Réseaux peer-to-peer 33 3.1 Introduction................................... 33 3.2 Historique.................................... 34 3.3 Définition, caractéristiques et objectifs.................... 35 3.4 Les différentes topologies............................ 37 3.4.1 Architecture centralisée......................... 37 3.4.2 Architecture décentralisée hybride................... 38 3.4.3 Architecture décentralisée P2P pure.................. 38 3.5 Couche de routage............................... 40 3.5.1 Protocoles de routage au sein de réseaux structurés......... 41 4 Communication de groupe 48 4.1 Introduction................................... 48 4.2 IP-Multicast................................... 50 4.3 Multicast applicatif sur une infrastructure P2P................ 51 4.3.1 Scribe.................................. 51 5 Architecture P2P sur une couche de transport service web 56 5.1 Présentation générale.............................. 56 5.2 Combinaison de services web et P2P..................... 57 5.2.1 Les avantages.............................. 58 5.2.2 Les inconvénients............................ 59 5.3 Choix des protocoles.............................. 60 5.3.1 Choix du protocole de routage P2P.................. 60 5.3.2 Choix du protocole Multicast..................... 61 5.4 Aspects techniques............................... 61 5.4.1 Couche services web.......................... 61 5.4.2 Couche de routage P2P......................... 67 iv

TABLE DES MATIÈRES 5.4.3 Couche de communication de groupe................. 70 5.5 Expérience et résultats............................. 71 5.5.1 L interface................................ 71 5.5.2 L implémentation............................ 73 5.5.3 Exemple d exécution.......................... 75 6 Conclusions 78 A Annexes 80 A.1 WSRemoteNodeI.java.............................. 80 A.2 Mapping type Java - XML schéma...................... 81 A.3 Publication de services web.......................... 83 Bibliographie 84 v

Table des figures 2.1 Composition de services web.......................... 7 2.2 Exemple d utilisation du service web Google Maps.............. 10 2.3 Couches des services web............................ 11 2.4 Modèle d interaction des services web..................... 12 2.5 Format d un message SOAP sans pièce jointe................. 17 2.6 Structure d un document WSDL........................ 19 2.7 Entrée d un annuaire UDDI.......................... 22 2.8 SAML : Authentification unique........................ 30 2.9 Sécurité : Standards basés sur WS-Security.................. 32 3.1 Napster : fonctionnement............................ 34 3.2 Architecture centralisée............................. 38 3.3 Architecture décentralisée hybride....................... 39 3.4 Architecture centralisée P2P pure....................... 39 3.5 CAN....................................... 42 3.6 Chord...................................... 43 3.7 Pastry : Routage par préfixe.......................... 44 3.8 Pastry : Table de routage............................ 46 4.1 Envoi multiple via unicast........................... 49 4.2 Scribe : inscription à un groupe........................ 53 5.1 Découpage en couches de la solution..................... 57 5.2 Parties d une peer de l application....................... 64 vi

TABLE DES FIGURES 5.3 WS : Instances et points d entrées....................... 65 5.4 Application : Fenêtre de connexion...................... 72 5.5 Application : Fenêtre principale........................ 73 vii

Chapitre 1 Introduction 1.1 Motivation Associés généralement à la piraterie, les réseaux peer-to-peer constituent un moyen aisé et performant pour le partage de ressources à grande échelle. Malheureusement, la plus grande utilisation faite de ce genre de réseaux est la distribution de logiciels, de fichiers musicaux... majoritairement illégaux menant ainsi les fournisseurs d accès à Internet à s armer contre cette utilisation frauduleuse en plaçant, notamment, des filtres sur leurs serveurs. Néanmoins, le thème des réseaux peer-to-peer ouvre ses portes à d autres types d usages comme l a bien fait remarquer la recherche dans ce domaine. En effet, de par ses diverses caractéristiques comme par exemple le fait d être décentralisé, auto-adaptatif et extensible, le concept de réseaux peer-to-peer semble être une base intéressante pour de futures applications, désireuses d éviter le modèle tant utilisé sur Internet mais limité en puissance, à savoir le modèle client/serveur. Dans un autre domaine, les services web forment une solution aux différentes interactions dynamiques entre des entités hétérogènes de par leur architecture, leur langage de programmation ou encore de par leur architecture. Cette technologie permet ainsi de construire des architectures orientées services dans lesquelles chaque entité peut, sans connaissance préalable d un service, consommer ce dernier après avoir effectué une recherche dans un annuaire et récupéré une description de celui-ci. De plus, les services web mettent en avant des atouts intéressants dont il serait utile de profiter dans un type d interaction autre que 1

1.2. STRUCTURE DU DOCUMENT celui du modèle client/serveur : le modèle décentralisé. C est la raison pour laquelle ce document se focalise, après une description de ces technologies, sur la combinaison de celles-ci dans un système ayant pour application la gestion de groupes et l envoi de messages en mode multicast/anycast à ces derniers. Ainsi, ce mémoire a pour objectifs de présenter ces diverses technologies et surtout de créer une application permettant la communication de groupes, reposant sur une architecture peer-to-peer, le tout utilisant les services web comme moyen de transport de messages. 1.2 Structure du document Pour ce faire, ce document se divise en quatre parties caractérisées chacune par un chapitre. Le chapitre 2 présente la technologie des services web en commençant par définir celle-ci de manière rigoureuse. Ensuite, ce chapitre décrit l utilisation des services web dans l industrie ainsi que les différents avantages et inconvénients pouvant mener au développement d une application l exploitant. Ceci étant fait, le chapitre présente les différents aspects techniques impliqués dans cette technologie. Finalement, différentes facettes concernant la sécurité des services web seront explicitées. Le chapitre 3 expose le sujet des réseaux peer-to-peer en commençant par un bref historique suivi d une définition ainsi que d un énoncé des différentes caractéristiques et objectifs de ceux-ci. Ensuite, après avoir présenté les différentes topologies possibles des réseaux peer-to-peer, le chapitre s attardera sur différents algorithmes de routage au sein de ces réseaux dans le cas structuré. Le chapitre 4 effectue quant à lui une présentation générale de la communication en comparant la communication de groupe au niveau applicatif avec celle effectuée par IPmulticast. Ensuite, ce chapitre décrira une technique de multicast applicatif reposant sur une architecture peer-to-peer. 2

1.2. STRUCTURE DU DOCUMENT Finalement, le chapitre 5, pierre angulaire de ce document, fournit une présentation globale de l application permettant la communication de groupe sur une architecture peerto-peer en utilisant les services web comme couche de transport. Ensuite, après évocation des différents avantages et inconvénients à combiner les technologies des services web avec une architecture peer-to-peer, une présentation sera faite des aspects techniques des différentes technologies utilisées lors de l implémentation de l application. Enfin, ce chapitre sera clôturé par l exposé de l application résultante ainsi qu un exemple d exécution ayant pour but d illustrer les différents concepts abordés. 3

Chapitre 2 Services web 2.1 Introduction Depuis la création d Internet, l utilisation de ce réseau s est diversifiée. En effet, tout commença durant les années 1950, lors de la guerre froide, lorsque le ministère américain de la Défense souhaitait disposer d un réseau capable de résister aux attaques de l ennemi ; tel n était guerre le cas car ce dernier utilisait le réseau téléphonique public considéré comme vulnérable 1. Viendra quelques années plus tard la création d une unité de recherche pour la Défense, l ARPA 2 qui donnera par la suite naissance au réseau ARPAnet. Initialement, ce réseau reliait seulement quelques universités qui l utilisaient à des fins de calculs distribués. Dû à son succès et à l apparition du protocole TCP/IP 3, bon nombre d unités de recherche, de réseaux et de machines vont s y rattacher, faisant ainsi augmenter de façon significative la taille de ce réseau. L utilisation d Internet jusqu aux années 90 aura donc concerné les chercheurs d université, le gouvernement et les industries. Par la suite, une nouvelle application va révolutionner l utilisation d Internet et dès lors attirer des millions de nouveaux utilisateurs : le WWW 4. Ce dernier ne se définit plus comme un énorme entrepôt de textes, de fichiers et d images car il a évolué vers une architecture orientée services (SOA 5 ) ; ce qui ajoute ainsi la notion de services à notre approche. Ainsi, en plus des interactions homme - machine, on va prendre en considération 1 En effet, il suffisait de détruire quelques-uns des points de commutation afin de fragmenter le réseau. 2 Advanced Research Projects Agency. 3 Il a été reconnu officiellement en 1983 comme étant le seul protocole. 4 World Wide Web. 5 Service Oriented Architecture. 4

2.2. DÉFINITION les interactions machine - machine. Depuis quelques années, un engouement particulier vers les SOA (et les services web par la même occasion) s est fait ressentir. En effet, une preuve de ceci a été apportée par l enquête menée par Evans Data Corporation [13] datant de 2006, dans laquelle le constat suivant a été fait : le pourcentage d architectures orientées services en état de fonctionnement aurait doublé par rapport à l année précédente. De plus, 24% de l échantillon interrogé se disent implémenter des SOA, ce qui correspond à une augmentation de 85% par rapport à l année précédente et 30% se disent prêts à utiliser plus de 20 services pour l année suivante, ce qui correspond à une augmentation de 58% par rapport à l année précédente. Néanmoins, 25% de cet échantillon pensent également que le frein principal de cet augmentation est le manque de standards. En effet, l un des problèmes posés par les services web concerne les standards, sujet sur lequel nous reviendrons ultérieurement dans ce chapitre. Après avoir défini de manière rigoureuse les services web, décrit leurs avantages et inconvénients et donné une vision globale sur le sujet, ce chapitre 6 s attardera sur les différentes technologies dont ils font usage. De plus, ce chapitre présentera diverses méthodes permettant de sécuriser ces derniers ainsi que les technologies qui y sont associées. 2.2 Définition Comme pour tout concept important, il est fondamental de définir de manière rigoureuse la notion de services web. En effet, nombreuses sont les personnes qui galvaudent ces termes ; la partie web est associée aux sites web et par conséquent le couple services web est associé aux services disponibles pour le public via un site web. De plus, la multitude de définitions variant avec le temps, l entité la définissant et le manque de standards encouragent cette mauvaise compréhension. Afin de remédier à ce problème, l analyse et l explication de plusieurs définitions semblent être un passage nécessaire. Tout d abord, examinons une définition comportant quelques lacunes provenant de [7] : A web service is any service that is available over the Internet, uses a standardized XML messaging system, and is not tied to any one operating system 6 Afin d élaborer ce chapitre, les références suivantes ont été utilisées : [2, 9, 10, 12, 29, 36, 43, 45, 53] 5

2.2. DÉFINITION or programming language. Cette dernière considère un service web comme étant un service disponible via Internet, utilisant XML 7 pour l encodage des messages et indépendant du système d exploitation, ainsi que du langage de programmation. Cette définition est incomplète dans le sens où celle-ci ne spécifie pas le fait que l interaction se produit entre programmes. De plus, les aspects de description du service ainsi que de découverte de ce dernier sont manquants, la notion de service étant laissée dans le vague. Une définition plus complète nous est fournie par le W3C 8 : A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols. [54] Cette définition met en avant le fonctionnement même des services web. Ainsi, celle-ci précise qu un service web doit pouvoir être défini, décrit et découvert par d autres applications, mécanisme qui est à la base d une architecture orientée service. Aussi, un prestataire de services voulant mettre un service à disposition de clients doit, après avoir défini et décrit son service, rendre ce dernier disponible 9 en le publiant par exemple dans un annuaire. Les clients intéressés pourront ensuite consulter cet annuaire et faire appel aux services dont ils ont besoin. D autres aspects importants de cette définition résident dans l identification d un service web via un URI 10 ainsi que l utilisation de XML pour l échange de messages, sujets sur lesquels nous reviendront plus tard dans ce chapitre. En résumé, un service web est une application qui : 7 Extensible Markup Language. 8 World Wide Web Consortium abrégé W3C. 9 Découvrable. 10 Uniform Resource Identifier : Il s agit d un identifiant unique pour une ressource web respectant une syntaxe WWW. RFC3986[4] pour plus d informations. 6

2.3. LA COMPOSITION DE SERVICES WEB fonctionne indépendamment du système d exploitation ou du langage de programmation, est identifiée par un URI, est accessible via un réseau, communique avec d autres applications grâce à un langage commun de représentation de données, a une interface publique qui sera utilisée par les autres applications, est inscrite dans un annuaire. 2.3 La composition de services web Ce type d architecture consiste en la réalisation d un service qui, pour atteindre son objectif, va utiliser d autres services. Afin d éclaircir cela, il convient de regarder de plus près la figure 2.1 illustrant un service web fourni par une agence de voyage. Réservation de tickets d avion Compagnie A Réservation de tickets d avion Compagnie B Client Service d une agence de voyage Réservation de voiture Réservation d hôtel B Réservation d hôtel A Fig. 2.1 Composition de services web Dans ce cas-ci, une agence de voyage met à la disposition du client un service permettant la réservation d un voyage. Ce service aura pour tâche d effectuer les réservations nécessaires 7

2.4. AVANTAGES ET INCONVÉNIENTS selon les critères donnés par le client. Il est important de remarquer le fait que l agence de voyage joue un double rôle : celui de prestataire de service envers le client et celui d utilisateur des services de réservations divers. Ce type d architecture est transparent pour le client qui n utilisera que le service mis à sa disposition par l agence de voyage. 2.4 Avantages et inconvénients Le succès des services web dans l industrie n est pas un hasard. En effet, les services web présentent bon nombre d avantages : Un déploiement facile et rapide : une entreprise utilisant des services web peut mettre à disposition des nouveaux services tout en limitant les coûts ainsi que le temps nécessaire à leur déploiement. Ainsi, une entreprise peut très aisément créer un nouveau service en combinant d autres services déjà existants. L interopérabilité : les services web peuvent être utilisés par d autres applications indépendamment du système d exploitation ou des langages de programmation dans lesquels ces derniers sont implémentés. Protocoles et standards ouverts : les services web utilisent des protocoles et des standards qui sont ouverts. Les données ainsi que les protocoles étant au format texte, ils sont plus facilement compréhensibles et lisibles par les développeurs. L utilisation du protocole HTTP : les services web utilisant le protocole HTTP 11 bénéficient d un avantage non négligeable, à savoir leur fonctionnement à travers de nombreux firewalls sans avoir à modifier les règles de filtrage. Les services web ne faisant pas partie d un monde parfait, ceux-ci présentent également quelques défauts : Faibles performances : comme nous pouvons le voir en référence [14], les services web ne constituent pas une grande avancée au niveau des performances quand ils sont comparés à CORBA 12 conséquences directes de l utilisation de XML. Problème de sécurité : et à Java-RMI 13. Ce défaut de performance est une des bien que l utilisation du protocole HTTP constitue un avantage, ce dernier peut également être considéré comme un inconvénient. En effet, 11 Hypertext Transfer Protocol. 12 Common Object Request Broker Architecture. 13 Remote Method Invocation. 8

2.5. LES SERVICES WEB DANS L INDUSTRIE puisque cette technologie permet de passer à travers les firewalls, elle permet par conséquent de passer au travers des règles de sécurité de ces derniers. Normes peu développées : certaines normes telles que la sécurité ou encore les transactions sont encore au stade de prémices. 2.5 Les services web dans l industrie L intégration et l interopérabilité étant les objectifs premiers des services web et recherchés par l industrie, il n est pas étonnant de les retrouver dans des applications de nombreuses grandes entreprises telles que Ebay, Amazon, Google, Yahoo Paypal, ViaMichelin, etc. Voici quelques exemples 14 de services web mis à la disposition des développeurs par des entreprises très présentes sur Internet : Google 15 : L entreprise Google, notamment réputée pour son moteur de recherches, met à disposition des développeurs des services web permettant d effectuer, à partir de programmes développés par ces derniers, des recherches parmi les pages référencées et de récupérer les résultats de manière structurée. Nous retrouvons également une API 16 mettant à disposition des fonctions du célèbre Google Earth 17, une API permettant la gestion d un calendrier, une autre permettant la vérification d orthographe, etc. Sur la figure 2.2, une agence immobilière a utilisé l API Google Maps afin de permettre une meilleure visualisation de la localisation des biens. Yahoo 18 : La société Yahoo met à disposition des services web permettant de consulter un compte mail à partir d une application. Tout comme Google, Yahoo offre des services de localisation ainsi que de recherche mais permet également la création de galeries de photos ainsi que la création d une boutique en ligne. 14 Liste non exhaustive. 15 http://code.google.com/ 16 Application Programming Interface. 17 http://earth.google.fr/ 18 http://developer.yahoo.com/ 9

2.5. LES SERVICES WEB DANS L INDUSTRIE Fig. 2.2 Exemple d utilisation du service web Google Maps Ebay 19 : Ebay, la très célèbre société d enchères en ligne, permet aux utilisateurs d interagir avec sa base de données via ses services web. Par l intermédiaire de ceux-ci, on pourra notamment afficher les enchères, enchérir, laisser des évaluations, consulter les profils des vendeurs, etc. Amazon 20 : La société Amazon met à la disposition des développeurs des services web permettant à ces derniers d intégrer des données d Amazon directement dans leurs applications. PayPal 21 : PayPal, solution de paiement sur Internet, permet aux développeurs d effectuer dans leurs applications des transactions bancaires, d obtenir des détails sur une transaction, etc. 19 http://developer.ebay.com/ 20 http://aws.amazon.com/ 21 https://www.paypal.com/cgi-bin/webscr?cmd=p/pdn/devcentral landing-outside 10

2.6. ASPECTS TECHNIQUES Ces dernières années, nous avons assisté à une augmentation du nombre de services web disponibles. Ainsi, une foule de services gadget ont vu le jour dans le but d attirer le grand public à la recherche d originalités pour leurs sites web. 2.6 Aspects techniques Comme illustré à la figure 2.3, la technologie des services web se décompose en plusieurs couches, chacune ayant un rôle bien particulier et reposant sur les fonctionnalités fournies par la couche inférieure. Nous pouvons d ores et déjà remarquer que le langage XML est utilisé comme standard pour ces différentes couches, permettant ainsi l interopérabilité, but premier des services web. De plus, il apparaît également sur cette figure que la couche de communication n est pas restreinte à un seul protocole ouvrant ainsi ses portes aux protocoles HTTP, SMTP 22, FTP 23, etc. permettant de ce fait aux développeurs de déployer des services web également sur un intranet. La description de cette couche n étant pas le sujet principal de ce document, nous ne nous y attarderons pas. Basés sur XML Orchestration WS BPEL Publication et découverte des services web UDDI Description des services web WSDL Messages Extensions de SOAP Fiabilité, transactions, routage,... Sécurité SOAP Couche de communication HTTP, SMTP, FTP,... Fig. 2.3 Couches des services web 22 Simple Mail Transfer Protocol. 23 File Transfer protocol. 11

2.6. ASPECTS TECHNIQUES Cette section 24 a pour but de décrire les différentes couches ainsi que les interactions entre ces dernières en illustrant chacun des concepts grâces à des exemples concrets. Faisant suite à une présentation des différents acteurs intervenant dans le scénario général de fonctionnement des services web, les différentes technologies y sont détaillées. 2.6.1 Scénario général de fonctionnement Un fournisseur de services ayant implémenté ces derniers souhaite les rendre accessibles via le réseau. Pour ce faire, il va d abord devoir décrire ces services de façon à ce que l utilisateur potentiel de ces derniers ait toutes les informations dont il aura besoin pour une bonne utilisation de ceux-ci. Ceci sera accompli grâce à la technologie WSDL 25 ; sujet qui sera développé plus loin dans cette section. Une fois la description réalisée, il va devoir la publier dans un annuaire de services de façon à ce que les clients puissent découvrir le service associé. Ces derniers pourront donc effectuer des opérations de recherche sur cet annuaire pour trouver la description du service dont ils ont besoin. Ceci étant fait, le client du service va pouvoir se connecter au fournisseur de services et invoquer le service web souhaité. Ce scénario est illustré à la figure 2.4. Découverte de services Utilisateur de services web SOAP Annuaire UDDI SOAP Publication de services Fournisseur de services web SOAP Applications Utilisation des services web Document WSDL Services web Fig. 2.4 Modèle d interaction des services web Les différentes étapes nécessaires à l accès et à l utilisation d un service web sont donc 24 Afin d élaborer cette section, les références suivantes ont été utilisées : [17, 22, 23, 15] 25 Web Services Description Language. 12

2.6. ASPECTS TECHNIQUES les suivantes : 1. Découvrir le service : le client lance une recherche sur un annuaire UDDI en spécifiant les critères. 2. Récupérer la description du service : le client reçoit en réponse à sa requête un document WSDL décrivant le service dont il a besoin. 3. Utilisation du service web : la communication entre le client et le service web se fait via le protocole SOAP. Le client appelle le service web en précisant les paramètres divers de ce dernier. 4. Récupérer la réponse Toutefois, il est important de remarquer que ce scénario peut également s étendre de manière récursive. En effet, comme nous l avons vu dans la section 2.3, un service web peut être composé d autres services de fonctionnalités diverses pouvant être localisés à l autre bout de la terre. 2.6.2 XML XML [55] est un langage permettant la représentation de données ainsi que de documents structurés sans l utilisation de balises prédéfinies. Ainsi, ce langage peut être étendu de façon à y ajouter des balises spécialisées afin de décrire au mieux chaque type de données. Cette flexibilité confère à XML la popularité dont il jouit. Historiquement, XML a été développé par le W3C en 1996, a profité des meilleurs aspects de SGML 26 et est, depuis 1998, une recommandation du W3C. XML décrit un ensemble de règles syntaxiques, de façon à placer de manière cohérente et correcte les balises à l intérieur d un tel document. Un document XML qui respecte toutes ces règles imposées est dit bien formé. L avantage de toutes ces règles est de permettre la création de parsers 27 XML qui seront utilisés afin de lire et d extraire les données d un document XML. Un exemple de document XML est donné ci-dessous : Dans le code source 2.1, les balises en orange sont appelées des éléments. Chaque entité peut avoir un ou plusieurs attributs 28 (en rouge) permettant d ajouter de l information 26 Standard Generalized Markup Language. http://www.w3.org/markup/sgml/ 27 Analyseur syntaxique en français. 28 La valeur de ceux-ci doit être encadrée par des quotes. 13

2.6. ASPECTS TECHNIQUES Code source 2.1 Exemple de document XML bien formé <collection nom= Ma collection > <livre id= 1 > <titre>marketing management</titre> <auteurs> <auteur>kotler</auteur> <auteur>dubois</auteur> </auteurs> <sujet>marketing</sujet> </livre> </collection> supplémentaire aux éléments. Les namespaces XML Les namespaces, ou espaces de noms XML, permettent de classer les éléments ainsi que les attributs en une collection, de façon à éviter les ambiguïtés de nommage telles que les collisions de noms d éléments ou d attributs. Chaque namespace est identifié par un URI et est déclaré en utilisant le mot réservé xmlns tout en respectant la syntaxe xmlns: prefix = URI dans le cas d une utilisation avec préfixe ou bien xmlns= URI. Les deux solutions sont équivalentes, si ce n est que la première définit en plus un préfixe qui devra être utilisé avant chaque élément ou attribut du namespace. Le code 2.2 utilise un namespace avec préfixe. Code source 2.2 Exemple de namespace XML (préfixé) <ns1 :livre xmlns :ns1 = http ://www.mylibrary.com > <ns1 :titre>marketing management</ns1 :titre> <ns1 :auteurs> <ns1 :auteur>kotler</ns1 :auteur> <ns1 :auteur>dubois</ns1 :auteur> </ns1 :auteurs> </ns1 :livre> 14

2.6. ASPECTS TECHNIQUES Les schémas XML Un schéma XML est un document XML permettant la définition d une structure possible d un document XML. Ce schéma permettra la validation dudit document en décrivant l ensemble des éléments ainsi que des attributs pouvant apparaître dans ce dernier, l ordre des éléments fils ainsi que leur contenu, les types de données des éléments et des attributs ainsi que leur valeur par défaut. Le schéma XML 2.3 correspond à celui du document XML 2.1. 2.6.3 SOAP SOAP 29, ou encore Simple Object Access Protocol 30, est un standard du Consortium W3C définissant un protocole RPC 31, tout comme RMI et CORBA, mais utilisant XML pour structurer les messages. Il permet donc l échange de messages entre entités SOAP d un émetteur à un récepteur pouvant passer par des intermédiaires. Un des grands avantages de ce protocole est qu il n est pas limité à un seul protocole de transport, contrairement à son ancêtre XML-RPC 32 qui, lui, est basé sur HTTP. En effet, alors que la grande tendance est à HTTP, on pourrait parfaitement utiliser SMTP, FTP ou tout autre technologie future pour l implémentation de cette couche. Le protocole SOAP précise les aspects suivants : la manière avec laquelle XML sera utilisé pour représenter le contenu des messages, comment une paire de messages peut être utilisée pour former un échange du type Request-Reply, des règles définissant par exemple comment le récepteur d un message doit traiter les différents éléments XML qu il contient. 29 Afin de réaliser cette section, les références suivantes ont été utilisées : [27, 44, 52] 30 Cet acronyme n est valable que jusqu à la version 1.1 car la version 1.2 ne le spécifie plus. SOAP devient alors un nom propre n ayant plus aucune relation avec l acronyme. 31 Remote Procedure Call : mécanisme permettant d appeler des procédures situées sur un ordinateur distant. 32 http://www.xmlrpc.com/ 15

2.6. ASPECTS TECHNIQUES Code source 2.3 Exemple de schéma XML <xs :schema xmlns :xs= http ://www.w3.org/2001/xmlschema elementformdefault= qualified > <xs :element name= collection > <xs :complextype> <xs :sequence> <xs :element maxoccurs= unbounded ref= livre /> </xs :sequence> <xs :attribute name= nom use= required /> </xs :complextype> </xs :element> <xs :element name= livre > <xs :complextype> <xs :sequence> <xs :element ref= titre /> <xs :element ref= auteurs /> <xs :element ref= sujet /> </xs :sequence> <xs :attribute name= id use= required type= xs :integer /> </xs :complextype> </xs :element> <xs :element name= titre type= xs :string /> <xs :element name= auteurs > <xs :complextype> <xs :sequence> <xs :element maxoccurs= unbounded ref= auteur /> </xs :sequence> </xs :complextype> </xs :element> <xs :element name= auteur type= xs :NCName /> <xs :element name= sujet type= xs :NCName /> </xs :schema> 16

2.6. ASPECTS TECHNIQUES Les messages SOAP Deux formats de messages SOAP sont possibles, dépendant de l utilisation ou non de pièces jointes. Comme illustré dans la figure 2.5, un message sans pièce jointe se compose de trois parties : une enveloppe (Envelop) qui est obligatoire et qui contient le nom du message ainsi que les namespaces XML-SOAP utilisés, un entête (Header) qui est optionnel et utilisé pour spécifier les comportements que doivent adopter les différents intermédiaires se situant entre l expéditeur et le récepteur du message, un corps (Body) qui est obligatoire et qui contient les noms des différentes méthodes qui seront exécutées par le destinataire, ainsi que les paramètres associés, ou la réponse à une requête ou encore un message d erreur. Enveloppe SOAP Entête SOAP Entrée de l entête Entrée de l entête Corps SOAP Entrée du corps Entrée du corps Fig. 2.5 Format d un message SOAP sans pièce jointe 17

2.6. ASPECTS TECHNIQUES La version avec pièce jointe s obtient aisément en ajoutant au format de base, à l extérieur de l enveloppe, des blocs de pièces jointes qui sont composés d un entête MIME 33 ainsi que du contenu. Il est à noter que dans les deux formats possibles, le message sera encapsulé par la couche de communication utilisée. Afin d illustrer un échange Request-Reply 34 utilisant SOAP, les codes 2.4 et 2.5 montrent respectivement un message SOAP faisant appel à la méthode SayHello avec le paramètre Bob, ainsi que le message de réponse associé contenant la réponse Hello Bob. Code source 2.4 Message de requête SOAP <soapenv :Envelope xmlns :soapenv= http ://schemas.xmlsoap.org/soap/envelope/ xmlns :xsd= http ://www.w3.org/2001/xmlschema xmlns :ns1= http ://test/ > <soapenv :Body> <ns1 :SayHello> <name>bob</name> </ns1 :SayHello> </soapenv :Body> </soapenv :Envelope> Code source 2.5 Message de réponse SOAP <soapenv :Envelope xmlns :soapenv= http ://schemas.xmlsoap.org/soap/envelope/ xmlns :xsd= http ://www.w3.org/2001/xmlschema xmlns :ns1= http ://test/ > <soapenv :Body> <ns1 :SayHelloResponse> <return>hello Bob</return> </ns1 :SayHelloResponse> </soapenv :Body> </soapenv :Envelope> Finalement, il est à noter que des extensions peuvent être ajoutées au protocole SOAP de façon à assurer par exemple la sécurité, la fiabilité de transmission, le routage asynchrone, etc. 33 Multipurpose Internet Mail Extensions. 34 Une communication unidirectionnelle est aussi possible. 18

2.6. ASPECTS TECHNIQUES 2.6.4 WSDL A ce stade, dans la pile des couches des services web, une problématique naît d un point de vue de la description des services puisque le protocole SOAP ne s occupe que de l échange de messages. En effet, dans l exemple d échange Request-reply (2.4), comment l utilisateur du service connaît-il les paramètres, les noms de méthodes de services distants et le type de réponse? La solution à cette problématique a été apportée par les sociétés Ariba, IBM et Microsoft, qui ont proposé la spécification WSDL 35 permettant la description de services web et en particulier de leur interface au moyen de documents WSDL. Il est à noter que Microsoft et IBM sont également à l origine de SOAP. Ainsi, chaque prestataire de services va définir dans un document WSDL les différents types de messages qu il peut recevoir et éventuellement ceux qu il peut envoyer en guise de réponse. En plus de définir ces derniers, WSDL définit également la localisation des services ainsi que les différents mécanismes pour accéder à ceux-ci puisque ces derniers sont accessibles via plusieurs protocoles différents. Structure d un document WSDL <definitions> <types> </types> <message> </message> <porttype> </porttype> <binding> </binding> </definitions> Fig. 2.6 Structure d un document WSDL 35 Web Services Description Language. [48] 19

2.6. ASPECTS TECHNIQUES Un document WSDL est un document XML qui est constitué des éléments suivants : Définition : elle contient le nom du service qui est décrit dans le document ainsi que les namespaces utilisés. Il s agit de l élément Root du document. Types : il s agit de la définition des types de données qui seront utilisés dans les messages. On y trouvera donc par exemple des schémas XML. Messages : il s agit d une description de la structure des messages qui seront échangés. On y retrouve deux types de messages : les messages entrants et les messages sortants. Chaque message peut être composé de plusieurs parties décrivant les différents paramètres de ces derniers. PortTypes : il s agit d un ensemble d opérations, chacune se référant à un message entrant et sortant. Bindings : ils spécifient quels protocoles seront utilisés. Service : il s agit des informations permettant la localisation du service. La structure d un tel document est illustrée à la figure 2.6. Ainsi, lorsqu un client veut accéder à un service web, il va tout d abord devoir se procurer la description WSDL de ce dernier. A l aide de celle-ci, il aura toutes les informations nécessaires pour créer les messages SOAP afin d effectuer l invocation et récupérer la réponse. En pratique, la majorité des développeurs de services web n a pas besoin de comprendre les détails SOAP et WSDL puisque ceux-ci sont gérés par les toolkits utilisés. 2.6.5 UDDI UDDI [26], ou Universal Description Discovery and Integration, est la spécification d un framework 36 permettant le stockage de descriptions de services web ainsi que la découverte de ces derniers. Ce projet, lancé par les sociétés Microsoft, IBM et Ariba et soutenu initia- 36 Ensemble de bibliothèques qui permet de développer rapidement une application. 20

2.6. ASPECTS TECHNIQUES lement par plus d une trentaine d entreprises, est la réponse à la problématique du B2B 37 sur Internet ainsi qu au succès du commerce électronique. L API UDDI est en fait un service web qui est décrit via la technologie WSDL et qui permet d accéder à un annuaire de services web (annuaire UDDI) via le protocole SOAP. Une analogie peut être faite entre un annuaire UDDI et un annuaire téléphonique : un annuaire UDDI va organiser l information sur les services web en trois catégories : Les pages blanches : celles-ci sont constituées des informations de description des entreprises fournissant les différents services web. Une entrée de ces pages sera donc formée du nom de l entreprise, de son adresse, des informations de contact ainsi que d une description de celle-ci. Les pages jaunes : il s agit de la classification des services web selon des taxonomies standards comme par exemple les sortes de produits, les entreprises ou encore la localisation géographique. Les pages vertes : il s agit des informations techniques concernant les différents services web. Ceci se fera par l intermédiaire de documents WSDL. Pour ce faire, la spécification UDDI définit un modèle de données constitué des quatre entités principales suivantes : l entité Business (BusinessEntity) : contient les informations concernant l entreprise incluant son nom, sa description, son adresse ainsi que les informations de contact ; il s agit donc de l équivalent des pages blanches. l entité Service (BusinessService) : cet élément décrit les services web associés à l entité business correspondante ; il contient le nom, la description ainsi qu une liste (optionnelle) de BindingTemplates ; il s agit donc de l équivalent des pages jaunes. l entité modèle de liaison (BindingTemplate) : il décrit les informations techniques permettant de savoir où et comment accéder au service web ; il est donc ici question des pages vertes. 37 Business-to-Business. 21

2.6. ASPECTS TECHNIQUES BusinessEntity Name Contacts Description Business services Identifier Categories BusinessService (1..n) Name Contacts Description Binding template Categories BindingTemplate (1..n) Description Address Detailed info References to tmodels tmodel Name Contacts Description OverviewDoc Identifiers Categories WSDL document Fig. 2.7 Entrée d un annuaire UDDI l entité modèle technique (tmodel) : il décrit les spécifications d un service web. Il contiendra donc une référence vers un fichier de description, généralement un document WSDL. Afin de publier un ou plusieurs services web dans un annuaire UDDI, il faut d abord définir les tmodels qui vont décrire les caractéristiques des services web, comme l interface du service en WSDL. Il est à noter qu un tmodel peut déjà exister pour un service implémentant une interface standardisée qui a déjà été publiée par le consortium de standardisation correspondant. Ensuite, il convient de publier les informations concernant l entreprise (dans une BusinessEntity), celles concernant les services web (dans une BusinessService) et finalement les informations techniques(contenant notamment une référence vers un tmodel) pour les différents services. La figure 2.7 illustre une entrée dans un annuaire UDDI ainsi que les relations entre les différentes entités. 22

2.7. SÉCURITÉ 2.6.6 WS-BPEL Jusqu à présent, les différents standards décrits ne permettent qu une interaction simple (qu elle soit bidirectionnelle ou non) entre deux applications. Malheureusement, l intégration de systèmes demande plus que ces simples interactions ; elle requiert un modèle standard d intégration entre les différentes applications : elle nécessite donc le recours à un outil pour décrire de manière précise les différentes interactions possibles entre les acteurs concernés. Ceci est rendu possible grâce à WS-BPEL 38 qui tire ses origines de WSFL 39 et XLANG 40. Il s agit d un langage d orchestration basé XML permettant de décrire un processus de haut niveau via la description des interactions entre différents services web. La distinction entre le modèle d orchestration et celui de chorégraphie est importante. En effet, l orchestration se place au niveau d un participant (et va donc décrire comment celui-ci va interagir avec les autres) tandis que la chorégraphie donne une vue globale du processus en reprenant tous les participants ainsi que leurs interactions entre ceux-ci. 2.7 Sécurité Alors que les services web permettent l échange de données passant par un réseau pouvant être vulnérable (comme Internet), il convient de sécuriser ces dernières. Plusieurs points doivent être adressés de façon à garantir la sécurité des échanges d informations : L authentification : permet de vérifier que l accès à une application ou à une ressource distante ne se fait que par des entités ayant prouvé leur identité. L identification : garantit que l entité accédant à une ressource distante ait bien accès à celle-ci. L intégrité : permet de vérifier que le message reçu par le destinataire n a pas été modifié durant sa transmission et donc qu il s agit bien du message envoyé par l émetteur. La confidentialité : permet de vérifier que les messages transmis ne peuvent être 38 Web Service Business Process Execution Language [25]. 39 Web Services Flow Language. 40 XML Business Process Language. 23

2.7. SÉCURITÉ lus par des entités autres que le récepteur et l émetteur du message. La non-répudiation : garantit au destinataire d un message que l émetteur de celuici est bien celui qu il dit être. Par défaut, les services web n implémentent pas ces critères de sécurité. Aussi, il convient de mettre en place certains dispositifs de façon à renforcer la sécurité du système. 2.7.1 Sécurisation de la connexion Un première approche pour sécuriser les services web est la sécurisation de la connexion entre le fournisseur de service et l utilisateur afin de la rendre fiable. A ce stade, plusieurs possibilités peuvent être mises en oeuvre, selon le réseau et la fréquence des interactions. Firewall Une première possibilité est la configuration des règles de firewall, en limitant l accès aux adresses IP 41 connues. Cette méthode est pratique si l on veut restreindre l accès au sein d un réseau privé LAN ou WAN. Néanmoins, cette méthode n offre aucun cryptage et par conséquent, n est applicable que si le contenu des messages n est pas secret. SSL Une seconde méthode permettant l échange sécurisé de messages cryptés est l utilisation du protocole SSL 42 /TLS 43, offrant les fonctionnalités suivantes : L authentification du serveur qui va donc permettre au client de s assurer de l identité du serveur. Pour ce faire, le client va utiliser des techniques de cryptographie à clé publique afin de vérifier la validité du certificat ainsi que de l ID publique du serveur. L authentification du client qui fonctionne de la même manière que l authentification du serveur. 41 Internet Protocol. 42 Secure Sockets Layer. 43 Transport Layer Security. 24

2.7. SÉCURITÉ Une connexion chiffrée permettant ainsi la confidentialité et l intégrité. Cette méthode est efficace pour une communication client/serveur. Malheureusement, ce protocole perd ses avantages lorsqu il existe des intermédiaires dans la communication. En effet, un scénario possible serait un client qui se connecte à un intermédiaire A par SSL qui, lui, va se connecter à un intermédiaire B via un protocole différent ne garantissant pas l intégrité et ce dernier est connecté au serveur. 2.7.2 XML Signature XML Signature [51] est une recommandation du W3C assurant l authentification, l intégrité ainsi que la non-répudiation de données. Pour ce faire, les signatures XML permettent de signer partiellement ou entièrement de manière digitale n importe quel document de façon à ce que les parties non signées de ce dernier puissent être modifiées par des intermédiaires. On retrouve trois types de signature selon l emplacement de celle-ci dans le document : la signature enveloppée (enveloped signature) qui s applique aux données entourant celle-ci dans un document, la signature enveloppante (enveloping signature) qui s applique aux données signées qu elle contient, la signature détachée (detached signature) qui s applique à des ressources qui sont extérieures au document la contenant. Un des avantages d une signature XML est que celle-ci est transformée en forme régularisée ou canonique. En effet, cette transformation permet d éviter les problèmes de jeu de caractères ou d espaces. La structure d une signature XML est illustrée par le code source 2.6 et est composée des éléments XML suivants : SignedInfo : il s agit d un élément XML obligatoire qui contient les données qui seront réellement signées. Cet élément contient le nom de l algorithme utilisé pour la régularisation (ou la canonisation qui se produit avant la signature), celui utilisé pour la signature (retournant la valeur de l élément SignatureValue) ainsi que des éléments Reference contenant chacun une référence vers un objet à signer, les transformations à lui appliquer, du nom de l algorithme (DigestMethod) utilisé pour sa 25

2.7. SÉCURITÉ signature (Digest), ainsi que la valeur de cette signature représentée par l élément DigestValue. SignatureValue : il s agit également d un élément obligatoire qui va contenir le résultat de la signature obtenu en utilisant l algorithme précisé dans l élément SignedInfo. KeyInfo : élément indiquant la clé qui devra être utilisée pour valider la signature. Cet élément est optionnel car le signataire peut souhaiter ne pas rendre publique les informations de clé aux différents intermédiaires. De plus, cette donnée peut être connue dans le contexte de l application et ne doit donc pas être représentée. Object : élément optionnel permettant d inclure des données à la signature comme par exemples un nom, une date, etc. Code source 2.6 Structure d une signature XML <Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI? > (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)? (<Object ID?>)* </Signature>? représente zéro ou une occurrence, + représente une ou plusieurs occurrences et * zéro ou plusieurs occurrences 2.7.3 XML Encryption L encryptage XML [50] est, tout comme les signatures XML, une recommandation du W3C. Celui-ci permet de garantir la confidentialité de messages passant par différents in- 26

2.7. SÉCURITÉ termédiaires. Pour ce faire, l encryptage avec XML permet de crypter certaines parties d un document XML, laissant ainsi d autres parties lisibles par des intermédiaires. Aussi, cela permettra à différents destinataires de lire un document de manières différentes ; chacun pouvant lire certaines parties de celui-ci sans avoir accès à la totalité des données du document. Le résultat du chiffrement d une partie d un document XML (ou du document dans son entièreté) est un élément XML EncryptedData qui remplacera l élément ou le contenu dans la version cryptée du document. Dans le cas du cryptage du document dans son entièreté, l élément EncryptedData deviendra l élément ROOT du nouveau document XML. La structure de cet élément est illustrée par le code source 2.7 et est composée des éléments XML suivants : EncryptionMethod : élément XML optionnel décrivant l algorithme de chiffrement utilisé. ds :KeyInfo : il s agit d un élément XML contenant les informations utiles dans le but de décrypter le contenu de l élément CipherData. CipherData : il s agit d un élément obligatoire qui contient soit le contenu chiffré, soit une référence vers le contenu chiffré. EncryptionProperties : élément XML renfermant des informations supplémentaires sur le contenu chiffré. Ce mode de cryptage sera très utile avec les services web dans le cryptage de parties d un message SOAP. 2.7.4 XKMS XKMS [49, 46], ou XML Key Management Specification, est une spécification proposée notamment par Microsoft, Verisign et webmethods au W3C. Elle permet d intégrer PKI 44 ainsi que les certificats numériques dans les transactions sur Internet, dans le but de sécuriser ces dernières. Ainsi, cette spécification va permettre la distribution ainsi que 44 Public Key Infrastructure : il s agit d une infrastructure à clés publiques permettant notamment l enregistrement d utilisateurs, la génération/renouvellement/révocation/publication de certificats, identification et authentification des utilisateurs, etc. 27

2.7. SÉCURITÉ Code source 2.7 Structure de l élément EncryptedData <EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds :KeyInfo> <EncryptedKey>? <AgreementMethod>? <ds :KeyName>? <ds :RetrievalMethod>? <ds :*>? </ds :KeyInfo>? <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData> <EncryptionProperties>? </EncryptedData>? représente zéro ou une occurrence l enregistrement de clés publiques qui seront notamment utilisées avec XML Signature (2.7.2) et XML Encryption (2.7.3). Un autre objectif de cette spécification est de simplifier l application voulant intégrer la sécurité. En effet, l application n a plus besoin de gérer la syntaxe ni la sémantique des PKI, puisqu il lui suffit d utiliser un protocole XML plus simple pour obtenir les informations requises sur une clé auprès d un service XKMS distant. Comme précisé par Kareen Renaudin (responsable après-vente de webmethods) dans [1], XKMS est destinée à être implémentée en tant que service web, permettant ainsi à un client d accéder aux différents services PKI. La spécification XKMS est constituée de deux parties : X-KISS (XML Key Information Service Specification) : est un protocole permettant la localisation sans validation obligée, puisque ce service peut être un relais vers un autre service et par conséquent n est pas obligé de se prononcer sur la validité ou la validation de l information associée à une clé publique en utilisant alors des données locales. X-KRSS (XML Key Registration Service Specification) : est un protocole permet- 28

2.7. SÉCURITÉ tant l enregistrement d une paire de clés par son propriétaire de façon à la rendre utilisable par le protocole X-KISS. 2.7.5 SAML SAML, ou Security Assertion Markup Language, est un langage développé par OASIS permettant l échange d informations de sécurité aussi appelées assertions. Pour ce faire, celui-ci va définir la syntaxe ainsi que la sémantique des messages d affirmation encodés en XML, définir un protocole de requête et de réponse entre différentes parties échangeant ces informations de sécurité et définir des règles, ces dernières afin d utiliser les affirmations sur divers standards de transport (par exemple comment une affirmation SAML est transportée en utilisant SOAP). La création de SAML n est pas un hasard. En effet, ce standard tente de résoudre un problème très important : l authentification unique ou SSO 45. L authentification unique permet à une entité (pouvant être un individu ou une machine) de n effectuer qu une seule fois une procédure d authentification et d étendre cette authentification à plusieurs applications, chacune nécessitant une authentification, sans réitérer la procédure à chaque application. Ceci est illustré à la figure 2.8. 2.7.6 XACML XACML, ou Extensible Access Control Markup Language, est un langage basé XML standardisé par OASIS permettant la description de stratégies de contrôles d accès à certaines ressources. Pour ce faire, ce langage inclut des types de données, des fonctions ainsi que de la logique. Afin d effectuer une action sur une ressource, un demandeur va envoyer une requête auprès de l entité protégeant la ressource (comme par exemple un serveur web), aussi appelée Policy Enforcement Point (PEP). Ce dernier va construire une requête en fonction des différents attributs du demandeur, de l action demandée, de la ressource concernée et de toute autre information pertinente. Une fois ceci fait, il va l envoyer à un tiers de décision appelé Policy Decision Point (PDP) qui va vérifier s il existe bel et bien une règle accordant l accès à cette ressource pour cette action à cet utilisateur et renvoyer une réponse au PEP 45 Single Sign-On. 29

2.7. SÉCURITÉ Fig. 2.8 Authentification unique qui va accorder ou non en conséquence l accès au demandeur. Il est important de remarquer que le PEP et le PDP peuvent se retrouver dans une même application ou distribués sur plusieurs serveurs. 2.7.7 WS-Security WS-Security, ou WSS, est une spécification qui a d abord été développée par IBM, Microsoft et Verisign, pour l être ensuite par le consortium OASIS permettant d inclure dans un message SOAP (2.6.3) des mécanismes de sécurité tels que la signature numérique (XML Signature), l encryptage (XML Encryption) et des jetons de sécurité. Cette spécification permettra par conséquent d assurer l intégrité et la non-répudiation via la signature numérique et la confidentialité 46 des données transmises via l encryptage de celles-ci. De plus, une confidentialité totale peut être obtenue en utilisant un protocole de communication adéquat tel que HTTPS 47. Les jetons de sécurité pourront quant à eux être utilisés dans des méthodes d authentification telles que Kerberos [20] ou encore avec la recommandation 46 Celle-ci peut être partielle par rapport à la totalité des données. 47 HTTPS = HTTP + SSL/TLS. 30

2.7. SÉCURITÉ X.509 [16]. Il est important de faire une distinction entre la sécurité apportée par un protocole de communication particulier et celle du message en tant que tel. En effet, nombreuses sont les différences entre ces deux types de sécurité pouvant mener, lors de l implémentation d une infrastructure services web, à un choix à effectuer en fonction des avantages et inconvénients de ces derniers. Une comparaison [33] de ces deux types de sécurité est résumée ci-dessous. Alors qu une sécurité au niveau transport crée un tunnel de sécurité de point à point sur un chemin, la sécurité au niveau du message s applique entre deux extrémités (endpoint). De plus, la sécurité au niveau du message apporte une plus grande flexibilité dans le sens où XML Encryption permet de ne crypter qu une certaine partie du message, rendant ainsi le contenu non crypté accessible et modifiable par les intermédiaires. Un autre avantage d une sécurité au niveau du message est que celle-ci peut utiliser une stratégie différente pour plusieurs messages. En effet, on pourrait parfaitement crypter une requête mais rendre la réponse à cette dernière lisible par tous. De plus, la sécurité au niveau du message ne dépend pas directement du protocole de transport utilisé. Malheureusement, ces avantages ont un prix : celui de la complexité, qui est une conséquence directe de l usage des différents standards pouvant être fait de diverses manières 48. Néanmoins, il est tout à fait possible de combiner les deux solutions de façon à utiliser par exemple des jetons de sécurité, apparaissant normalement en clair, qui sont protégés via une sécurité de transport. 2.7.8 Autres spécifications basées sur WS-Security Alors que WS-Security constitue la couche de base du modèle de sécurité des services web, une myriade de spécifications vient s y superposer de façon à rajouter des fonctionnalités à celle-ci. Ceci est illustré à la figure 2.9 ; la couche constituée de WS-Policy, WS-Trust et WS-Privacy formant à son tour une base pour les spécifications de plus haut niveau : WS-SecureConversation, WS-Federation et WS-Authorization. L avantage de ce modèle est clair : permettre une grande modularité. En effet, selon les besoins, on pourra choisir les spécifications qui nous intéressent. Ainsi, nous pouvons disposer, en plus de WS-Security, des spécifications suivantes : 48 Faut-il une signature numérique, une authentification, un cryptage? Quel algorithme de cryptage utiliser? Où le client va-t-il trouver une clé publique pour encoder les données? etc. 31

2.7. SÉCURITÉ Fig. 2.9 Standards basés sur WS-Security WS-Policy : permet de décrire en terme de sécurité les exigences du destinataire ainsi que les capacités de sécurité de l émetteur d un message. WS-Trust : décrit un modèle permettant d établir des relations de confiance pouvant se baser sur un système de jetons de sécurité. WS-Privacy : décrit les règles de discrétion et de confidentialité. WS-SecureConversation : décrit comment deux entités peuvent communiquer en s authentifiant mutuellement et en formant un contexte de sécurité. WS-Federation : permet de construire des espaces de confiance globaux permettant ainsi d effectuer des authentifications entre entités utilisant des méthodes d authentification différentes. WS-Authorization : décrit comment gérer et créer des règles d autorisation, certifier des autorisations via des jetons, échanger ces jetons et interpréter ceux-ci de manière à contrôler correctement les accès aux services. 32

Chapitre 3 Réseaux peer-to-peer 3.1 Introduction L apparition des réseaux peer-to-peer est une conséquence logique du désir de résoudre différents problèmes liés à l augmentation de la demande de services sur Internet. En effet, le but premier de ce type de réseau est de permettre le partage de ressources et de données à grande échelle tout en évitant le modèle centralisé utilisant des serveurs pour lesquels l administration peut être une tâche complexe et coûteuse, surtout si ceux-ci sont soumis à de grands trafics. Cette décentralisation va permettre d effectuer non plus une relation de client à serveur dans laquelle chaque entité joue un rôle bien distinct, mais une relation de pair-à-pair 1 dans laquelle le rôle de chaque entité est équivalent. En effet, chaque entité occupera la fonction de client mais également celle de serveur. Toutefois, différentes topologies de réseaux peer-to-peer existent, modifiant ainsi le rôle de chaque entité au sein de ces derniers. Ce chapitre 2 a pour but de donner une vue d ensemble du sujet tout en soulignant l un des problèmes principaux de ce mémoire : les algorithmes de routage au sein d un réseau peer-to-peer. Pour ce faire, ce chapitre donnera une définition ainsi que les caractéristiques et objectifs d un réseau peer-to-peer. Ensuite, celui-ci décrira les différentes topologies existantes de tels réseaux et détaillera différents protocoles de routage au sein de réseaux peer-to-peer structurés. 1 Peer-to-peer en Anglais et est abrégé P2P. 2 Afin de réaliser ce chapitre, les références suivantes ont été utilisées : [8, 40] 33

3.2. HISTORIQUE 3.2 Historique Le premier réseau peer-to-peer a fait son apparition en 1999 avec le lancement du système Napster [28] ayant pour but de permettre à ses utilisateurs d accéder à une grande collection de fichiers musicaux, collection qui se devait d être accessible à grande échelle. La première utilisation d un réseau peer-to-peer fut donc le partage de musique. Durant sa période de gloire, Napster compta plusieurs millions d utilisateurs enregistrés permettant ainsi d échanger des milliers de fichiers musicaux de manière simultanée. Toutefois, ce réseau peer-to-peer n était pas totalement décentralisé (les différentes topologies de réseaux P2P sont développées dans la section 3.4). En effet, comme illustré à la figure 3.1, l architecture de Napster s appuie sur un index centralisé et répliqué permettant aux différents clients du système de localiser les fichiers au sein du réseau. Client 1. Demande de localisation 3. Demande du fichier 4. Réception du fichier 2. Liste des clients offrant le fichier Serveur d index Napster 5. Mise à jour de l index Client Serveur d index Napster Fig. 3.1 Napster : fonctionnement Le fonctionnement illustré à la figure 3.1 est donc le suivant : 1. Un client (ou peer) effectue une requête auprès d un des serveurs d index afin de connaître l ensemble des clients ayant le fichier par lequel le client est intéressé. 2. Le serveur répond à cette requête avec cette liste. 34

3.3. DÉFINITION, CARACTÉRISTIQUES ET OBJECTIFS 3. Le client peut alors choisir une entité de la liste afin d obtenir le fichier. 4. Le client envoie une requête à l entité possédant la ressource. 5. Cette entité effectue l envoi du fichier. 6. Le client venant de réceptionner le fichier peut maintenant le rendre disponible sur le réseau. Pour ce faire, une mise à jour de l index sera opérée. Ainsi, le système Napster a démontré la faisabilité d un réseau peer-to-peer permettant le partage de fichiers à grande échelle en solutionnant le problème de localisation en utilisant un index répliqué. Néanmoins, ce système souffrait de la limitation suivante : une partie du système (les serveurs d index) restait centralisée devenant ainsi un goulot d étranglement. Malheureusement, ce système fut pris d assaut par le piratage de fichiers musicaux le menant ainsi, deux années après sa création, à sa fermeture imposée pour infraction à la législation sur les droits d auteurs. Quelques temps plus tard, Napster est devenu un portail de téléchargement légal de musique permettant aux utilisateurs, sur base d un abonnement, d écouter des extraits de titres disponibles et de télécharger leur version complète. Par la suite, une seconde génération de réseau peer-to-peer va naître. Celle-ci va permettre de répondre, de manière plus efficace, au problème de localisation de ressources au sein du réseau en décentralisant les informations de localisation. 3.3 Définition, caractéristiques et objectifs Définition Tout comme pour le sujet des services web, plusieurs définitions existent pour les réseaux peer-to-peer. Néanmoins, celles-ci ne mènent pas à une mauvaise utilisation des termes Réseaux P2P. Une définition complète illustrant très bien le concept est donnée dans la référence [24] et est reprise ci-dessous : A peer-to-peer system is a self-organizing system of equal, autonomous entities (peers) which aims for the shared usage of distributed resources in a networked 35

3.3. DÉFINITION, CARACTÉRISTIQUES ET OBJECTIFS environment avoiding centralized services. Plusieurs notions importantes sont utilisées dans cette définition. Dans un premier temps, un système peer-to-peer se doit d être self-organizing signifiant que le système doit pouvoir prendre en charge l ajout, la déconnexion ou encore la défaillance d un ou de plusieurs noeuds de manière simultanée tout en empêchant un blocage du système et ce, de manière décentralisée. En second lieu, cette définition insiste sur le fait que les différents noeuds du système doivent être des entités autonomes et égales. Par égales, la définition entend que chaque entité possède les mêmes fonctionnalités et joue donc un même rôle au sein du système. Toutefois, nous verrons plus tard que certains noeuds, en plus de fournir les mêmes fonctionnalités que les autres, peuvent jouer un rôle particulier. Caractéristiques Indépendamment de la topologie utilisée, les systèmes peer-to-peer partagent les caractéristiques suivantes : leur design implique que chaque utilisateur contribue aux ressources du système, bien que les noeuds les composant peuvent différer de part leur contribution en terme de ressources, ceux-ci ont les mêmes responsabilités ainsi que les mêmes fonctionnalités au sein du système, leur bon fonctionnement ne dépend pas de l existence d un système centralisé, leur design peut permettre aux différents intervenants du système d obtenir un certain degré d anonymat, la difficulté principale dans leur design est le choix d un algorithme de placement des données entre les différents noeuds de manière à balancer la charge de travail et à assurer la disponibilité des ressources tout en évitant de surcharger le système. Objectifs Un middleware peer-to-peer doit, à des degrés pouvant différer d un système à un autre, essayer de remplir les objectifs suivants afin de fonctionner de manière efficace : Extensibilité globale : le design d un middleware peer-to-peer doit prendre en compte le fait qu une application P2P peut connecter un grand nombre d utilisateurs répartis 36

3.4. LES DIFFÉRENTES TOPOLOGIES sur Internet et donc gérer de nombreuses données. Balancement de la charge : permet d obtenir de bonnes performances dans un système composé de nombreuses entités. Optimisation des interactions entre noeuds proches : étant donné que la distance réseau entre différents noeuds interagissant entre-eux peut introduire des latences supplémentaires, il convient de privilégier des interactions entre noeuds voisins afin de diminuer ces dernières. Adaptation aux comportements des noeuds : il est important de tenir compte du fait que chaque noeud qui compose le système est libre de s y connecter ou de le quitter à tout instant. En effet, aucune autorité centralisée n est utilisée pour administrer le système. Aussi, aucune garantie quant à la délivrance de services ne peut être donnée. Néanmoins, le design d un middleware peer-to-peer doit essayer d éviter les cas extrêmes dus aux comportements de ces noeuds. Sécurité : il convient de maintenir un certain degré de confiance dans ce genre de système en utilisant des mécanismes de cryptage et d authentification. Anonymat : un noeud, faisant partie du système et possédant une certaine donnée, doit pouvoir nier la responsabilité de posséder cette dernière. 3.4 Les différentes topologies 3.4.1 Architecture centralisée L architecture centralisée, ou modèle centralisé, est illustré à la figure 3.2. Ce modèle a comme avantage principal de permettre une administration centralisée et permet ainsi de réduire le nombre de décisions nécessaires en ce qui concerne le placement des ressources dans le système. Il s agit, par exemple, du modèle qui est utilisé dans le système de fichiers réseau NFS 3. Toutefois, cette architecture est limitée de par ses inconvénients. En effet, l extensibilité d un tel système est limitée de par les caractéristiques techniques du serveur ainsi que des connections réseaux ; on dira même qu il s agit d un goulot d étranglement. De plus, le serveur, constituant le point névralgique du système, peut être soumis à des défaillances paralysant ainsi ce dernier. 3 Network File System. 37

3.4. LES DIFFÉRENTES TOPOLOGIES Fig. 3.2 Architecture centralisée 3.4.2 Architecture décentralisée hybride Afin de pallier au problème du serveur unique de l architecture centralisée, plusieurs serveurs peuvent y être ajoutés de façon à former un réseau de serveurs ou de super-peers et éviter une panne totale en cas de défaillance. Comme illustré à la figure 3.3, chaque super-peer joue le rôle de serveur auprès d un certain nombre de clients. De plus, ces superpeers sont reliées entre elles de façon à échanger des informations sur le réseau comme par exemple une liste de l ensemble des clients. Il est à noter que lors de la défaillance d une super-peer, une peer y étant précédemment connectée peut la remplacer. 3.4.3 Architecture décentralisée P2P pure Finalement, la dernière architecture est celle totalement décentralisée ou peer-to-peer pure. Dans cette dernière, chaque peer joue le même rôle et est directement interconnectée à d autres peers. Cette architecture est illustrée à la figure 3.4. 38

3.4. LES DIFFÉRENTES TOPOLOGIES Fig. 3.3 Architecture décentralisée hybride Fig. 3.4 Architecture centralisée P2P pure 39

3.5. COUCHE DE ROUTAGE 3.5 Couche de routage Afin de permettre la localisation des noeuds ainsi que des objets (ou données) au sein d une architecture décentralisée, une couche de routage doit être utilisée. Cette couche va permettre de transférer une requête provenant de n importe quel client vers le noeud possédant l objet d intérêt. Il est à noter que chaque objet peut être placé et déplacé vers n importe quel noeud du système et ce, de manière transparente pour le client. Cette couche permettra donc d accéder à n importe quel objet en transférant une requête au travers une série de noeuds, chacun utilisant sa connaissance (partielle) du réseau. En plus de cette tâche, la couche de routage doit également permettre l insertion d un nouvel objet dans le réseau, la suppression de ce dernier et la répartition des objets entre les différents noeuds du système lors de l ajout ou de la suppression d un de ces derniers. Afin de retrouver un objet ou un noeud dans l étendue du système, ces derniers doivent être caractérisés par un GUID 4. Le choix de celui-ci est non négligeable, étant donné qu il doit permettre d identifier de manière unique n importe quel composant (noeud ou objet) tout en évitant les conflits. Pour ce faire, l utilisation d une fonction fournissant une valeur unique avec une grande probabilité est primordiale. L unicité de la valeur calculée via cette fonction pourra alors être garantie en effectuant une recherche de celle-ci dans le réseau. Une pratique courante est d utiliser une fonction de hashage telle que SHA-1 [11] de manière à obtenir ces identifiants. Étant donné que ces derniers sont utilisés pour le placement des objets au sein du système, la couche de routage est souvent appelée table de hashage distribuée 5. Dans ce modèle DHT, un objet ayant comme GUID la valeur X sera stocké au noeud ayant son GUID numériquement le plus proche de X (ainsi qu à un certain nombre d autres noeuds proches numériquement dans le cas d une réplication). Il s agit donc ici d un réseau P2P structuré puisque les objets sont placés à des endroits déterminés. Ce type de réseau permet d effectuer des recherches plus efficaces que les réseaux non-structurés dans lesquels le placement des objets et la disposition des noeuds sont aléatoires. Ce dernier type de réseau utilisera des méthodes telles que par exemple le flooding 6 afin de localiser les ressources. La suite de ce chapitre va donc se focaliser sur les réseaux P2P structurés. 4 Globally Unique ID. 5 Distributed Hash tables en Anglais, abrégé DHT. 6 Mécanisme ayant pour but d inonder le réseau par une requête. 40

3.5. COUCHE DE ROUTAGE 3.5.1 Protocoles de routage au sein de réseaux structurés Les protocoles de routages au sein d un réseau P2P structuré étant un domaine actif de recherche, plusieurs solutions ont été développées et testées avec succès comme l indique la référence [21]. Aussi ai-je décidé de n en présenter qu une sélection dont les mécanismes forment les bases de ce type de protocoles. Dans cette section, les protocoles de routage Chord, CAN et Pastry sont résumés. CAN CAN, ou Content Addressable Network [30], est une infrastructure P2P distribuée et décentralisée permettant les fonctionnalité d une table de hashage distribuée à l échelle d Internet. Le design de cette infrastructure est telle qu elle permet à CAN d être extensible, tolérante aux fautes et auto-adaptative 7. Son architecture utilise un espace cartésien de dimension d qui est dynamiquement réparti entre les différents noeuds (on suppose un nombre de N peers) de manière à ce que chaque peer possède sa propre portion de l espace. Ainsi, chaque peer va maintenir une table de routage contenant l adresse IP des noeuds voisins ainsi que leurs coordonnées associées au sein de l espace permettant alors à cette peer de router un message vers un noeud qui est plus proche de la destination. Pour un espace de dimension d partitionné en n zones, la longueur moyenne d un chemin lors d un routage est de dn 1 d sauts et chaque noeud maintient 2d noeuds voisins. Afin 4 de placer la paire Clé, Valeur, une fonction de hashage uniforme est utilisée de façon à faire correspondre la clé à un point de l espace. Ensuite, dans le but de retrouver la valeur correspondante à une clé, un noeud va utiliser cette même fonction pour trouver le point P. Si le noeud effectuant la requête ou ses voisins ne détiennent pas le point P dans leur espace, la requête sera alors transférée au travers le réseau CAN jusqu à ce noeud. Comme illustré à la figure 3.5, un noeud arrivant dans le système doit se voir accorder une portion de l espace. Pour ce faire, le nouveau noeud se connecte auprès du noeud de bootstrap 8 qui va lui renseigner de manière aléatoire un certain nombre de peers. Le nouveau noeud choisira alors dans cette liste une peer qui permettra de transférer une requête JOIN vers un point aléatoire P de l espace. Ce message se verra transférer jusqu au noeud le plus proche en terme de coordonnées du point P qui se verra partager son espace 7 Self-organizing. 8 Noeud de connexion de français. 41

3.5. COUCHE DE ROUTAGE Fig. 3.5 CAN : ajout du noeud 7 et partage de la zone appartenant à 1 en deux propre en deux avec le noeud joignant. Le nouveau noeud pourra alors créer son ensemble de noeuds voisins. Lorsqu un noeud quitte le réseau, un noeud voisin le détecte et va récupérer la zone précédemment occupée. Les voisins vont également mettre à jour leur table de routage afin d éliminer le noeud qui n est plus actif. Chord Chord [41] utilise le hashing consistent [18] afin répartir des clés entre les différents peers du système tout en balançant la charge avec une grande probabilité (les noeuds reçoivent plus ou moins le même nombre de clés). De plus, lors de l ajout ou du départ du N e noeud, seulement O( 1 ) des clés se verront déplacées afin de maintenir la répartition N de la charge. Dans un système à N peers, chaque noeud maintient des informations de routage pour seulement O(logN) peers. La fonction de hashing consistent assigne à chaque noeud ainsi qu à chaque clé un identifiant de m bits qui sera calculé par hashage sur base de l adresse IP pour les noeuds et sur base de la clé dans le cas d une clé. Afin d éviter au maximum des conflits d identifiants, la valeur de m se doit d être suffisamment grande de manière à rendre la probabilité d un conflit très petite. L ensemble des identifiants est ordonné sur un cercle modulo 2m qui est représenté à la figure 3.6. Sur ce cercle, la clé k sera stockée au premier noeud ayant son 42

3.5. COUCHE DE ROUTAGE N8's Finger Table +1 +2 +4 +8 +16 +32 Fig. 3.6 Chord : finger table du noeud N8 identifiant qui suit celui de la clé dans le sens des aiguilles d une montre. Ce noeud sera appelé le successeur de la clé k et est noté successeur(k). Afin de préserver la répartition de la charge lors de l arrivée d un noeud n, certaines clés assignées aux successeurs de n doivent être assignée à n. De même, lors du départ du noeud n, toutes les clés assignées à n doivent être réparties entre les différents successeurs de n. Le nombre de messages nécessaires pour rétablir le cercle lors de l arrivée ou du départ d un noeud est de l ordre de O(log 2 N). m étant le nombre de bits de l espace d adressage des identifiants, chaque noeud va maintenir jusqu à m entrées dans une table de routage appelée finger table. La i e entrée de la finger table du noeud n contient l identité du premier noeud s qui suit n d au moins 2 i 1. Autrement dit, s = successeur(n+2 i 1 ). Chaque entrée de cette table contient l identifiant du noeud concerné ainsi que son adresse IP. Il est important que les informations concernant les successeurs soient à jour. Pour ce faire, Chord exécute périodiquement un algorithme de stabilisation qui va mettre à jour les pointeurs vers les noeuds successeurs dans la finger table. Le mécanisme utilisé par le noeud n lors d une requête pour trouver le successeur de la clé k et donc pour connaître le noeud stockant cette donnée est le suivant : n va rechercher 43

3.5. COUCHE DE ROUTAGE dans sa finger table le noeud ayant un identifiant plus proche de celui de k que le sien et lui transférer la requête. Chord effectue ainsi le routage avec grande probabilité en O(logN) dans des conditions standard avec un système composé de N noeuds. Pastry Pastry [34] utilise, tout comme la couche de routage Tapestry 9, le mécanisme de routage par préfixe afin de déterminer les routes empruntées lors de l envoi de messages. Cette méthode, illustrée à la figure 3.7, permet de se rapprocher efficacement de la destination en augmentant, à chaque saut constituant la route, la longueur du préfixe commun à l identifiant du noeud courant et à celui de la destination. 128 Fig. 3.7 Pastry : Routage par préfixe Cette couche de routage assigne à chaque noeud ainsi qu à tout objet un GUID d une longueur de 128 bits. Ce dernier est calculé pour les noeuds en appliquant une fonction de hashage sécurisée (telle que SHA-1 [11]) sur l adresse IP du noeud considéré ou encore sur sa clé publique. En ce qui concerne l identifiant des objets, ce dernier est calculé en 9 Tapestry [56] ne sera pas détaillé dans ce mémoire étant donné sa grande similitude de fonctionnement avec Pastry. 44

3.5. COUCHE DE ROUTAGE appliquant également une fonction de hashage sécurisée sur par exemple le nom de l objet. Cette assignation d identifiants permet d obtenir des GUIDs uniformément distribués sur l intervalle de [0 ; 2 128 1], qui seront ordonnés sur un cercle de GUIDs tout comme celui de Chord. En supposant un réseau composé de N noeuds, Pastry permet de router un message vers le noeud qui est numériquement le plus proche d une certaine clé en moins de log B N sauts et ce, sous des conditions standard (B = 2 b est un paramètre de configuration avec une valeur typique pour b de 4). Un GUID est donc considéré ici comme une séquence de chiffres en base B. Lors du routage, une peer va transférer un message au noeud ayant un identifiant qui partage avec la clé un préfixe, qui est au moins un chiffre plus long que le préfixe partagé par la clé et le noeud courant. Dans le cas où un tel noeud n est pas connu, ce message sera transféré à un noeud ayant un identifiant partageant un préfixe avec la clé aussi long que la peer courante mais étant numériquement plus proche de la clé que l identifiant du noeud courant. Pour ce faire, chaque noeud va maintenir les trois ensembles suivants détaillés par la suite : une table de routage, un leaf set, un neighborhood set. Une table de routage R, illustrée à la figure 3.8, est une table composée de log B N lignes composées chacune de B 1 entrées. Les B 1 entrées se trouvant à la n e ligne de R correspondent à des peers ayant leur identifiant (NodeID) qui partage les n premiers chiffres de l identifiant du noeud courant mais qui diffère de ce dernier au chiffre n + 1. Chaque entrée composant R contient l adresse IP de la peer se conformant à la règle précitée et est choisie selon une métrique de proximité. Le choix de la valeur de b constitue donc un compromis entre la taille de la table de routage de chaque noeud (égale à (log B N)(B 1)) et le nombre de sauts nécessaires lors du routage d un message (égal à log B N). Le neighborhood set M est un ensemble constitué de couples NodeId, Adresse IP de M noeuds proches du noeud local en terme d une certaine métrique de proximité (telle que le nombre de sauts IP). Cet ensemble n est pas utilisé lors du routage d un message mais est fort utile afin de maintenir les propriétés de localité de Pastry. Le leaf set L est un ensemble de noeuds divisé en deux parties : L /2 noeuds numériquement proches ayant leur NodeId plus grand que le noeud courant et L /2 noeuds numériquement 45

3.5. COUCHE DE ROUTAGE P= 0 1 2 3 Préfixes des GUID suivis des nodehandles correspondants n 0 1 2 3 4 5 6 7 8 9 A B C D E F n n n n n n n n n n n n n n n 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F n n n n n n n n n n n n n n n 650 651 652 653 654 655 656 657 658 659 65A 65B 65C 65D 65E 65F n n n n n n n n n n n n n n n 65A0 65A1 65A2 65A3 65A4 65A5 65A6 65A7 65A8 65A9 65AA 65AB 65AC 65AD 65AE 65AF n n n n n n n n n n n n n n n Fig. 3.8 Pastry : Table de routage du noeud ayant un GUID commençant par 65A1. les n correspondent à des couples GUID, Adresse IP symbolisant des noeuds qui devront être utilisés lors du routage. proches ayant leur NodeId plus petit que le noeud courant. Le leaf Set est utilisé lors du routage comme précisé ci-dessous. Les tailles de M et de L sont généralement de B ou 2B. Le routage d un message s effectue en suivant l algorithme ci-dessous : 1. Tout d abord, le noeud recevant le message vérifie si la clé se trouve dans l étendue du leaf set. Si c est le cas, le message est directement transféré vers le noeud de destination, soit le noeud appartenant au leaf set et dont l identifiant est le plus proche de la clé. 2. Dans le cas contraire, la table de routage devra être utilisée et le message sera transféré au noeud partageant un préfixe avec la clé d une longueur plus grande d un chiffre qu avec le noeud courant. Dans certains cas, il est possible que l entrée appropriée de la table de routage soit vide ou non-joignable. Dans ce cas, le message est transféré vers un noeud qui partage un préfixe avec la clé aussi long qu avec le noeud courant mais qui est numériquement plus proche de la destination que ce dernier. A moins que L /2 noeuds adjacents du leaf set ne souffrent de défaillances simultanément, la livraison se produit correctement. Pastry prévoit également le comportement 46

3.5. COUCHE DE ROUTAGE dynamique de noeuds pouvant joindre le réseau ou le quitter de manière brutale à n importe quel instant. Afin de joindre le réseau, un noeud X va contacter une peer A proche en terme de localité et lui envoyer un message JOIN ayant X pour destination. Ce message sera alors routé de façon normale entre différents noeuds jusqu à arriver au noeud Z qui est numériquement le plus proche. L ensemble des noeuds traversés entre A et Z vont envoyer à X des parties de tables de routage et de leaf set, de façon à ce que ce dernier puisse s initialiser. Dans le cas d une défaillance d un noeud I appartenant au leaf set d une peer K, celle-ci va contacter un noeud A numériquement proche de I. A va alors envoyer en réponse une copie de son Leaf Set qui sera utilisé par K pour réparer son leaf set. La réparation de la table de routage se fait lors de la consultation de cette dernière durant le routage d un message. 47

Chapitre 4 Communication de groupe 4.1 Introduction Le multicast, ou diffusion de groupe, est un mode de communication qui est apparu afin de répondre au problème de surcharge d un réseau engendré par une communication d une station vers un groupe de stations intéressées. En effet, ce genre de communication nécessitait d envoyer un même message à chaque membre du groupe de destination, engendrant ainsi un flux de données beaucoup plus important qui va encombrer le réseau. Ce type de communication utilise donc le principe de communication unicast qui est illustré à la figure 4.1. Ainsi, afin d éviter cette surcharge, la communication multicast permet de n envoyer qu un seul message vers un groupe de processus intéressés, l appartenance au groupe étant généralement transparente pour l expéditeur du message. Il est à noter que ce type de communication est souvent confondu avec la communication broadcast qui permet d envoyer un message d un processus vers tous les processus d un réseau, tandis que le multicast le permet vers certains processus. Un autre mode de communication possible au sein d un système distribué est la communication anycast qui permet d envoyer un message vers un seul membre d un groupe, généralement le plus performant ou le plus proche. Les applications utilisant le mode de communication multicast sont nombreuses et couvrent un grand nombre de domaines. Parmi celles-ci, on peut citer les applications suivantes : 48

4.1. INTRODUCTION Données envoyées = 4 x taille d un seul message Emetteur Destination 4 Destination 3 Destination 1 Destination 2 Fig. 4.1 Envoi d un même message vers quatre destinations le tableau partagé 1 permettant à plusieurs intervenants de modifier simultanément une zone d écriture ou de dessin, facilitant ainsi par exemple la collaboration d employés d une même entreprise se trouvant aux quatre coins du monde, les applications de chat, les conférences Audio/Vidéo, la communication avec un groupe de serveurs, la réplication de données, les jeux interactifs à grande échelle sur Internet, les bases de données distribuées,... Après avoir introduit les concepts du IP-multicast, ce chapitre se focalisera sur le multicast de type applicatif implémenté dans un environnement peer-to-peer tout en essayant de mettre en évidence ses avantages par rapport au IP-multicast. 1 Shared whiteboards. 49

4.2. IP-MULTICAST 4.2 IP-Multicast Un premier type de multicast est celui construit sur le protocole Internet, IP, et est appelé IP-Multicast. Celui-ci permet à un émetteur de n envoyer qu un seul paquet IP à un ensemble d ordinateurs formant un groupe au lieu d un par destinataire. Il est à noter que la taille de ce groupe ainsi que les différents membres de celui-ci ne sont pas connus de l émetteur. De plus, un tel groupe est dynamique puisqu à tout moment, un ordinateur peut s y joindre ou s en retirer, modifiant ainsi la configuration du groupe. Un groupe de diffusion est identifié via une adresse IP de classe D 2 et peut être agrandi par n importe quel hôte pour autant que ce dernier supporte le multicast. Un tel groupe est également dit libre puisqu il n est pas nécessaire pour une station d appartenir à ce dernier pour pouvoir y émettre un paquet. Les paquets IP peuvent être envoyés en mode multicast sur des LANs 3 ainsi que sur des WANs 4. Pour ce faire, le multicast au niveau d un réseau local utilise une méthode propre au réseau telle que le multicast MAC 5. Une interaction entre ce réseau local et le monde extérieur est possible via le protocole de gestion de groupe IGMP 6. En ce qui concerne le multicast au niveau d Internet, des routeurs sont utilisés afin de transmettre un paquet IP vers des routeurs d autres réseaux comportant des membres du groupe multicast, qui recevront ce dernier via multicast au sein du LAN. Malheureusement, IP-multicast souffre de plusieurs inconvénients. Parmi ceux-ci, on peut citer : étant basé sur UDP, IP-multicast ne garantit pas la livraison à l entièreté d un groupe. En effet, il est possible que seulement une partie des membres et non tous ne reçoive le paquet. Ce mode de multicast peut donc être caractérisé de non-fiable puisqu il ne garantit pas la livraison à tous les membres du groupe. Il est d ailleurs parfaitement possible qu aucun membre d un groupe ne reçoive le paquet multicast 2 Adresse débutant par 1110 dans le cas de IPv4. 3 Local Area Network. 4 Wide Area Network. 5 Utilise des adresses MAC commençant par 01-00-5E. 6 Internet Group Management Protocol [5]. 50

4.3. MULTICAST APPLICATIF SUR UNE INFRASTRUCTURE P2P il s agit d un service Best Effort puisque des paquets peuvent être perdus. l ordonnancement des paquets n est pas garanti. 4.3 Multicast applicatif sur une infrastructure P2P Des infrastructures peer-to-peer telles que Chord, Pastry, CAN peuvent être utilisées afin de mettre en oeuvre des mécanismes de multicast au niveau applicatif. Ce type de multicast permettra donc de profiter de la puissance des infrastructures peer-to-peer en terme d extensibilité, d auto-adaptation et de performance tout en évitant les différents problèmes posés par le IP-multicast tels que la nécessité de disposer de matériel supportant le multicast. Dans la suite de cette section, une technique de multicast applicatif construit sur une infrastructure P2P sera détaillée. Il s agit de Scribe, une méthode de diffusion multicast implémentée sur la couche de routage Pastry. D autres méthodes sont également disponibles, comme par exemple CAN-multicast [31] qui est implémentée sur la couche P2P CAN, mais ne seront pas détaillées dans la suite de cette section. En effet, Pastry se démarquant des autres couches P2P d un point de vue des performances 7, celui-ci a été sélectionné afin de constituer une base pour le multicast applicatif. 4.3.1 Scribe Scribe [6] est une infrastructure construite au-dessus de la couche de routage Pastry qui permet d effectuer du multicast applicatif à grande échelle. Ainsi, chaque noeud appartenant au système Scribe 8 peut joindre un groupe, créer un groupe, envoyer des messages en mode multicast à l ensemble des membres d un groupe. Il est à noter qu un noeud peut appartenir à plusieurs groupes, l ensemble des groupes étant extensible et pouvant être de taille importante. Chacun de ceux-ci peut être constitué d un grand ensemble de membres pouvant être composé de plusieurs sources ainsi que de plusieurs membres récepteurs. Scribe construit un arbre multicast (par groupe) recouvrant l ensemble de ces membres, 7 cet aspect sera traité dans un chapitre suivant. 8 Ensemble de noeuds Pastry exécutant Scribe. 51

4.3. MULTICAST APPLICATIF SUR UNE INFRASTRUCTURE P2P l un d eux étant la racine de ce dernier et est appelé le point de rendez-vous. Scribe offre une API simple aux applications de communication de groupe : create(credentials, groupid) permet de créer un groupe ayant pour identifiant groupid ; credentials étant utilisé pour les droits d accès. join(credentials, groupid, messagehandler) permet au noeud local de joindre le groupe groupid. L ensemble des messages multicast reçus pour ce groupe étant transféré à la routine de traitement des messages messagehandler. leave(credentials, groupid) permet au noeud local de quitter le groupe. multicast(credentials, groupid, message) permet d envoyer un message au groupe spécifié en mode multicast. Chaque groupe est identifié par un identifiant qui est, tout comme pour les noeuds de Pastry, calculé par l intermédiaire d une fonction de hashage résistant aux collisions sur base du nom (au format textuel) du groupe. Le noeud Scribe ayant son identifiant le plus proche numériquement de l identifiant d un groupe se verra désigné comme étant le point de rendez-vous de celui-ci et deviendra, par conséquent, la racine de l arbre multicast de ce dernier. Un tel arbre est composé de noeuds appelés forwarders qui peuvent être ou non membres du groupe considéré. Ces noeuds ont pour but de maintenir la structure d arbre en utilisant une table de noeuds enfants appartenant à l arbre multicast. Joindre le réseau Ainsi, lorsqu un noeud Scribe souhaite joindre un certain groupe, il va, via la couche de routage Pastry, router un message JOIN qui aura comme clé l identifiant du groupe. Ce message va donc traverser un ensemble de noeuds jusqu à arriver au noeud numériquement le plus proche de la clé, à savoir le point de rendez-vous du groupe. Chacun de ces noeuds intermédiaires va vérifier dans sa liste de groupe s il constitue déjà un forwarder pour ce dernier. Si c est le cas, il va ajouter le noeud à sa liste d enfants pour ce groupe et arrêter de router le message. Dans le cas contraire, il va ajouter ce groupe dans sa liste et ajouter le noeud source du message dans sa table d enfants. Ensuite, toujours dans ce dernier cas, 52

4.3. MULTICAST APPLICATIF SUR UNE INFRASTRUCTURE P2P il va router à son tour un message JOIN jusqu au point de rendez-vous. Ce mécanisme est illustré à la figure 4.2. 1111 0100 1100 Racine 1001 1101 0111 Fig. 4.2 Inscription à un groupe de discussion via l envoi d un message JOIN Sur la figure 4.2, l identifiant de certains noeuds a été indiqué. Ici est faite l hypothèse d un groupe ayant comme identifiant 1100 et ayant comme point de rendez-vous le noeud ayant le même identifiant. Le noeud 0111, souhaitant joindre le groupe, va envoyer un message JOIN vers le noeud 1001. Ce dernier va à son tour router le message au noeud 1101 qui va finalement envoyer ce message au point de rendez-vous 1100. Cette route est indiquée sur la figure à l aide des flèches de couleur rouge. Imaginons maintenant que les noeuds 1001 et 1101 ne font pas encore partie des forwarders pour ce groupe. Le message JOIN envoyé par le noeud 0111 aura, dans ce cas, pour effets d incomber à ces derniers la tâche de forwarder et d ajouter le noeud 0111 à la table d enfants du noeud 1001 et 1001 à la table d enfants de 1101. Par la suite, si le noeud 0100 décide également de joindre le groupe, ce dernier va envoyer un message JOIN qui devrait, en temps normal 9, suivre le chemin vert. Toutefois, 9 Sans la présence des forwarders 1001 et 1101. 53

4.3. MULTICAST APPLICATIF SUR UNE INFRASTRUCTURE P2P étant donné que le noeud 1001 est forwarder de ce groupe, celui-ci va ajouter le noeud 0100 à sa table d enfants pour ce groupe et ne va pas router le message JOIN. Quitter le réseau Dans le cas où un noeud Scribe souhaite quitter un groupe, il enlève ce dernier de son ensemble de groupe. Ensuite, il va vérifier si sa table d enfants est vide. Si tel est le cas, il va envoyer un message LEAVE au noeud parent dans l arbre multicast. Ce message va remonter l arbre récursivement jusqu à arriver à un noeud ayant sa table d enfants non vide (après avoir retiré le noeud sortant). Envoi multicast Toute source multicast doit connaître le point de rendez-vous du groupe pour lequel elle veut effectuer l envoi. Pour ce faire, une source utilise Pastry afin router un message permettant de localiser la racine de l arbre qui y répondra avec son adresse IP. Cette dernière sera mise en cache de façon à éviter d effectuer cette manoeuvre à chaque envoi multicast. Dans le cas où le point de rendez-vous a changé ou est défaillant, une source utilise à nouveau Pastry pour trouver la nouvelle racine de l arbre multicast. Un message multicast est transmis à tous les intéressés par l intermédiaire du point de rendez-vous en parcourant l arbre multicast à partir de la racine de la manière suivante : un noeud recevant un message multicast va l envoyer à l ensemble des noeuds faisant partie de la table d enfants de ce groupe. De plus, si ce noeud est membre du groupe, il transfère ce message à la routine de gestion de messages de l application. Réparation de l arbre Périodiquement, chaque noeud (n étant pas une feuille de l arbre) appartenant à l arbre va envoyer un message HEARTBEAT aux noeuds faisant partie de sa table d enfants. Chacun de ceux-ci sait que, s il ne reçoit pas ce message, il peut suspecter son parent d être défaillant. Dans le cas d une défaillance du parent, le noeud va utiliser Pastry afin de router un message JOIN pour le groupe considéré. Pastry va donc permettre de reconstruire l arbre en suivant le mécanisme utilisé pour joindre un groupe. Il est à noter que l envoi d un message multicast aux enfants d un noeud peut être considéré comme étant également un message HEARTBEAT. 54

4.3. MULTICAST APPLICATIF SUR UNE INFRASTRUCTURE P2P Scribe prend également en compte la défaillance possible du point de rendez-vous d un groupe. Pour ce faire, l état 10 de ce point est répliqué aux k noeuds les plus proches appartenant donc au leaf set de la racine de l arbre. Ainsi, lors de la défaillance du point de rendez-vous, un de ces noeuds réplicas va la détecter et va router par l intermédiaire de Pastry un message JOIN, qui arrivera au nouveau point de rendez-vous. En ce qui concerne les enfants d un noeud, ceux-ci doivent envoyer périodiquement un message à leur parent, indiquant ainsi qu ils souhaitent continuer de faire partie du groupe. Dans le cas contraire, le parent enlèvera l enfant de sa table. 10 Celui-ci est composé de l identité du créateur du groupe ainsi de la liste de contrôle d accès. 55

Chapitre 5 Architecture P2P sur une couche de transport service web 5.1 Présentation générale Ce chapitre a pour but d effectuer une corrélation entre les différents concepts abordés dans les trois chapitres précédents (2 à 4) en présentant les différents détails d une application. Cette dernière, but principal de ce mémoire, consiste en un middleware utilisant les différents standards des services web qui a pour buts la création de chemins de routage au sein d un réseau peer-to-peer ainsi que de permettre une communication de groupe au sein de ce dernier. Par communication de groupe, il est ici entendu de permettre la création de groupes de réception dans lesquels auront lieu des envois de messages en mode multicast ainsi qu en mode anycast. C est donc tout logiquement que le design de cette application se décompose en trois couches illustrées à la figure 5.1 et décrites ci-dessous : La couche de transport : cette couche a pour but de véhiculer les différents messages provenant des couches supérieures. Ce rôle sera rempli par les services web. La couche de routage P2P : cette couche est destinée à la maintenance du réseau peerto-peer ainsi qu à la formation des chemins de routage au sein de celui-ci. Cette couche se devra d être performante afin d accepter un grand nombre d utilisateurs. De plus, elle devra prendre en compte la notion de localité de façon à ce qu un message em- 56

5.2. COMBINAISON DE SERVICES WEB ET P2P Couche de communication de groupe Couche de routage P2P Couche de transport : Services Web Fig. 5.1 Découpage en couches de la solution prunte un chemin optimisé en terme de distance. La couche de communication de groupe : elle aura pour tâches la formation de groupes ainsi que la maintenance des structures associées, le support de messages en modes multicast et anycast envoyé à ces groupes. Ce chapitre va, dans un premier temps, présenter les avantages ainsi que les inconvénients d une combinaison de la technologie des services web avec les réseaux peer-to-peer. Par la suite, après avoir justifié les différents choix opérés au niveau des différents protocoles, ce chapitre s attardera sur les aspects techniques des différentes couches de l application. Finalement, l application basée sur ces différentes couches sera détaillée et un exemple d exécution sera présenté et commenté. 5.2 Combinaison de services web et P2P Une première question que l on peut se poser à 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èmes distribués, les services web respectent une architecture client/serveur tandis que les architectures P2P adressent des architectures totalement décentralisées. 57

5.2. COMBINAISON DE SERVICES WEB ET P2P Aussi, la combinaison de ces deux technologies qui évoluent chaque jour permettra à chacune d hériter des avantages de l autre mais également de ses inconvénients. Dès lors, cette section donnera un aperçu de ce qu une architecture P2P peut apprendre des services web, de ce que les services web peuvent tirer d une architecture P2P mais également des différents inconvénients 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érents aux différentes qualités de ceux-ci. Un aperçu de ces apports est décrit ci-dessous : XML : comme précisé dans le chapitre 2 portant sur les services web, ces derniers utilisent de manière assez significative la technologie XML. Celle-ci, notamment utilisée pour la représentation de types données neutres aux différents langages de programmation par l intermédiaire des schémas XML, permettra au différents noeuds d une architecture P2P de s échanger les informations concernant la maintenance de la couche de routage, tout en permettant une divergence dans le langage de programmation utilisé pour l implémentation de ces peers. Cette technologie, pouvant facilement être modifiée via l utilisation de modules spécialisés tels que WS-security, permettra à l architecture P2P d en bénéficier. Ainsi, les mécanismes de sécurité XML permettent d assurer un certain degré de sécurité à l intérieur de réseaux P2P. L interopérabilité : l un des grands buts des services web est d être le plus ouvert et interopérable possible. Ainsi, une interface standardisée décrite via WSDL peut être utilisée à chaque noeud, permettant ainsi à n importe quel système capable de traiter du XML de communiquer avec une peer du réseau. De plus, l utilisation des services web dans une architecture P2P permet de faire disparaître les barrières telles que le langage de programmation ou encore le système d exploitation utilisé. La sécurité : plusieurs mécanismes ont été développés afin d introduire un certain niveau de sécurité au niveau des services web. Les différents noeuds d un réseau P2P pourront donc bénéficier de mécanismes tels que les modules de sécurité XML ou encore d une communication sécurisée grâce à HTTPS. 58

5.2. COMBINAISON DE SERVICES WEB ET P2P Le choix du protocole de transport : les services web n étant pas limités à 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éanmoins, l utilisation du protocole HTTP permettra au réseau P2P de s étendre sur Internet en fonctionnant à travers les firewalls. La décentralisation : les services web s appliquent à des communications serveur/client. Néanmoins, une peer joue ces deux rôles en étant tantôt le serveur dans une communication avec une peer A tantôt le client dans une communication avec une peer B. Dans ce sens, l utilisation des services web dans une architecture peer-to-peer permettra donc une décentralisation des services web. UDDI distribué : la technologie UDDI traitée dans le chapitre sur les services web est initialement prévue pour fonctionner de manière centralisée. Néanmoins, la décentralisation de cette technologie est un domaine actif de recherche. Ainsi, quelques exemples de travaux concernant cette décentralisation à l aide d une architecture P2P peuvent être trouvés dans les références [35, 38, 37, 47]. 5.2.2 Les inconvénients La combinaison de ces deux technologies n apporte malheureusement pas que des avantages. En effet, un aperçu des inconvénients pouvant apparaître lors de la combinaison de ces dernières est donné ci-dessous : Utilisation de la bande passante : la technologie XML étant utilisée afin de représenter les messages, celle-ci est de poids plus important, nécessitant ainsi plus de bande passante. De plus, la synchronisation fréquente des différentes peers étant un point crucial dans la maintenance de la structure de routage P2P, un tel réseau génère par défaut beaucoup de trafic. Ainsi, une conjonction de ces deux facteurs implique logiquement une augmentation de la bande passante utilisée. La sécurité : bien que la sécurité soit un sujet très important dans une architecture P2P, elle constitue toutefois son point faible. En effet, même si l utilisation de la sécurité apportée par les services web accroît le degré général de sécurité, celle-ci n a pas 59

5.3. CHOIX DES PROTOCOLES encore atteint sa phase de maturité. De plus, la gestion des différents droits d accès des noeuds d un réseau P2P est plus complexe que celle d une architecture centralisée. La maintenance difficile et une architecture complexe : un effet négatif d une architecture décentralisée, que ce soit avec ou sans services web, est son architecture complexe inhérente découlant des difficultés de sécurité ainsi que de l utilisation de ressources distribuées. La maintenance de telles applications est également complexe étant donné la difficulté d identifier et de réparer la ressource défaillante dans le réseau P2P. 5.3 Choix des protocoles Afin de développer l application considérée, deux choix ont dû être opérés. Celui du protocole de routage P2P et celui du protocole de communication de groupe. Ainsi, cette section justifiera ces choix par une comparaison des différents protocoles possibles. 5.3.1 Choix du protocole de routage P2P Ce choix a été opéré entre les protocoles Chord, Pastry et CAN. En effet, ceux-ci constituent les fondations pour des protocoles plus complexes mais encore en phase de développement. Le but poursuivi ici est d utiliser un protocole de base performant de façon à illustrer une application type ainsi que sa faisabilité. De par ses performances ainsi que ses propriétés de localité, ce sera Pastry qui sera utilisé comme couche de routage pour l application. En effet, Pastry donne de meilleures performances que CAN puisque ce dernier permet un routage en O(d.N 1 d ) tandis que Pastry le permet en O(log B N). En ce qui concerne Chord, celui-ci est moins performant que Pastry lors de l arrivée ou du départ d un nouveau noeud. En effet, Chord nécessite O(log 2 N) messages dans ces circonstances, tandis que Pastry n en nécessite que O(log B N). De plus, Pastry tient compte de la localité, ce que ne font ni CAN, ni Pastry. 60

5.4. ASPECTS TECHNIQUES 5.3.2 Choix du protocole Multicast En ce qui concerne le protocole de communication de groupe, le choix s est très vite tourné vers Scribe puisque ce dernier bénéficie des performances de Pastry. De plus, une comparaison entre CAN-multicast et Scribe peut être trouvée dans [19]. Celle-ci montre que Scribe fonctionne avec des temps de latence plus petits que ceux que donne CAN-multicast et ce, avec différentes configurations 1 de ces deux protocoles. 5.4 Aspects techniques Dans cette section, sont détaillées les différentes librairies utilisées pour chacune des couches de l application ainsi que les diverses difficultés rencontrées durant l implémentation. Ces explications commenceront par la couche la plus basse (la couche de transport utilisant les services web) pour terminer par la couche la plus haute ( la couche de communication de groupe). De plus, pour chacune de ces couches, différents extraits de codes sont donnés en annexe, le code entier de l application étant sur le support CD fourni en annexe à ce document. 5.4.1 Couche services web Afin de permettre l utilisation de services web, il a été fait usage de Systinet Server for Java 6.5. De par ses performances, sa grande facilité d emploi et sa documentation complète, Systinet Server for Java [42] se démarque de solutions telles que Apache Axis [3]. Systinet Server for Java 6.5 Systinet Server for Java 6.5 est une solution complète permettant la construction de services web JAVA/J2EE et donc d architectures orientées services. Elle supporte les différents standards services web tels que SOAP 1.1, SOAP 1.2 et WSDL 1.1 et offre de très bonnes performances, une livraison fiable et sécurisée. Gagnante de plusieurs prix au niveau de l industrie, Systinet Server for Java est largement déployée dans des compagnies leader dans leur domaine telles que Barclays Global Capital et T-Mobile. Une liste non-exhaustive de 1 Ceci, d un point de vue des paramètres. 61

5.4. ASPECTS TECHNIQUES ses caractéristiques est donnée ci-dessous : support de nombreux standards : SOAP 1.1, SOAP 1.2, WSDL 1.1, JAX-RPC, XML Signature,... indépendance de la plateforme : Systinet Server for Java supporte JAVA 1.3 et plus et tourne sous les systèmes Windows, Linux, AIX, HP-UX et Solaris. sécurité : support de nombreux mécanismes de sécurité incluant WS-Security. Systinet Server for Java supporte également des mécanismes de sécurité basés XML tels que XML Signature, XML encryption et SAML. console de management : une console permet d avoir une vue globale des services web déployés ainsi que des différentes options offertes. support pour une communication fiable. support des déploiements de services web de manière persistante mais également de manière dynamique. Service web de l application Dans le cadre de l application, un service web composé de plusieurs méthodes doit être créé à chaque noeud de façon à permettre à la couche de routage Pastry de fonctionner normalement. Afin de maintenir cette structure de routage, chaque noeud doit pouvoir acquérir des leaf set ainsi que des tables de routage de noeuds distants. De plus, l envoi de messages personnalisés doit être possible. Pour ce faire, chaque noeud devra implémenter l interface suivante, disponible dans le fichier WSRemoteNodeI.java en annexe A.1 : getleafsetm() : permet à un noeud du réseau de récupérer le leaf set d un noeud distant. getrouterow(row) : permet à un noeud de récupérer la ligne row à l intérieur de la table de routage d un noeud distant. 62

5.4. ASPECTS TECHNIQUES getnodeid() : est utilisé afin d obtenir l identifiant du noeud distant. remotereceivemessage(msg,hopdest) : permet de router un message msg en l envoyant au noeud distant tout en précisant la destination finale souhaitée, hopdest. Il est à noter qu à part la méthode getnodeid, ces méthodes renvoient et nécessitent des variables sous une forme sérialisée. Ce sujet fera l objet d une section plus loin dans ce chapitre. Chaque peer du réseau sera donc composée des deux parties suivantes, illustrées à la figure 5.2 : 1. une partie cliente qui aura pour tâche de faire appel aux différentes méthodes des noeuds distants, 2. une partie serveur permettant d exposer ces méthodes au monde extérieur ainsi que de les implémenter. Publication de services web Afin de pouvoir communiquer via services web, les différents noeuds du réseau doivent publier une instance de leur service web sur le Systinet Server. Cette opération permettra de rendre publique une interface composée des différentes méthodes disponibles. Pour ce faire, il convient de créer, dans un premier temps, le document WSDL qui décrira différents types 2 ainsi que l interface des méthodes nécessaires. L outil java2wsdl, fourni avec Systinet Server, permet aisément d effectuer cette tâche de manière dynamique dans le code 3 à partir d une classe Java. Cet outil repose sur Java2Schema, un composant permettant d effectuer une corrélation entre les différents types de données Java et leur représentation sous forme de schéma XML. Ainsi, toutes les méthodes publiques et nonstatiques contenues dans la classe Java seront publiées sous forme d opérations. Dans le 2 Il s agit en fait d extra types. Ceux-ci sont décrits plus loin dans cette section. 3 Il est également possible d utiliser cet outil à partir d une console. 63

5.4. ASPECTS TECHNIQUES Partie Serveur Résultat Appel GetLeafSetM() getrouterow(row) getnodeid() remotereceivemessage(msg,hopdest) Service web Peer A Appel Résultat Partie client Peer B Service web Fig. 5.2 Parties d une peer de l application cas où cette classe hérite d une autre, l ensemble des méthodes héritées non-statiques et publiques le seront également. Java2Schema est utilisé ici non seulement afin de créer une correspondance entre les différents types de bases Java et permettre leur transport dans un message SOAP, mais également afin de supporter des types personnalisés tels qu une classe. L ensemble des types de bases Java ayant une correspondance par défaut avec un schéma XML sont cités en annexe A.2. Par défaut, seuls les attributs privés d une classe sont traités. Néanmoins, il est possible, en changeant la configuration du serveur, de traiter les membres publics. Dans cette application, nous aurons donc besoin de types supplémentaires symbolisant un message contenant par exemple un leaf set. Pour ce faire, étant donné que plusieurs messages sont possibles dans notre cas, du polymorphisme est utilisé : chaque message particulier hérite d une classe message général et le type message général est utilisé pour manipuler les messages particuliers. Afin de supporter ce polymorphisme, il convient d ajouter ces types particuliers de message à la description WSDL ; ces types étant appelés des extra types. En pratique, cette opération est effectuée en créant un ensemble (HashSet) dans 64

5.4. ASPECTS TECHNIQUES lequel il faut ajouter les classes désirées 4 et en le passant en paramètre à une méthode (setextratypes) de java2wsdl. Une fois le document WSDL généré, il convient de créer une instance du noeud implémentant l interface décrite. Une instance d un service web est accessible du monde extérieur par l intermédiaire de points d entrée 5. Ceux-ci constituent donc les portes d accès aux différentes méthodes du service web. Il est à noter que plusieurs points d entrée donnant sur la même instance du service web peuvent être créés. Un point d entrée étant caractérisé par un document WSDL et une adresse URI, deux de ces derniers donnant sur une même instance de service web permettront d exposer de manières différentes les méthodes d un service web en utilisant différents protocoles de communication ainsi que des propriétés de sécurité adaptées par exemple au type de réseau 6. Diverses possibilités de points d entrée sont illustrées à la figure 5.3. Classe d implémentation C Instance du service I1 avec son état propre Instance du service I2 avec son état propre Endpoint E1 Http://myhost.be:6060/ E1 Endpoint E2 Http://myhost.be:8080/ E2 Endpoint E3 Http://myhost.be:8080/ E3 Endpoint E4 Https://myhost.be:7070/ E4 Description S1 WSDL du service Description S2 WSDL du service Description S2 WSDL du service Fig. 5.3 Instances et points d entrées 4 Ces dernières sont identifiées par leur nom suivi de.class. 5 Endpoint en Anglais. 6 Ceci, afin d obtenir une sécurité plus faible des appels provenant de l intranet de la société offrant ses services. 65

5.4. ASPECTS TECHNIQUES L instance du service web étant créée, la création d un point d entrée vers cette dernière est faite en utilisant comme paramètres un document WSDL, une référence vers l instance et l adresse URI souhaitée. Afin de finaliser la procédure de publication, il convient de publier le point d entrée créé dans un registre local de Systinet server, le rendant ainsi accessible à l adresse spécifiée. Un extrait de l ensemble des lignes de codes comprenant ces étapes est disponible en annexe A.3. Appel d un service web L utilisation d un service web par un client peut être faite très aisément. La classe ServiceClient, disponible dans les librairies de Systinet Server, joue le rôle de client d un service web. Lors de l initialisation de ce dernier, l adresse du document WSDL distant est donnée en paramètre. Un objet ServiceClient peut être utilisé de plusieurs manières. Néanmoins, l usage qui en est fait dans l application est la génération dynamique d un proxy qui permettra ensuite l accès aux méthodes distantes. Ce dernier, de type WSRemoteNodeI 7, est initialisé en lui passant en paramètre l interface utilisée. L initialisation de ce dernier va permettre de prendre connaissance des multiples méthodes distantes et ainsi rendre possibles les appels vers celles-ci. Par la suite, il suffira d utiliser le proxy de la manière suivante afin d appeler une méthode (getleafsetm par exemple) : LeafSet tmp = proxy.getleafsetm() Problème de sérialisation Comme expliqué dans une section précédente, une conversion d un type Java vers un schéma XML (et inversement) est faite pour tout type utilisé dans les messages échangés ; que ce soit en paramètre ou en valeur de retour. Pour ce faire, Systinet Server utilise Java2Schema. Bien que cet outil effectue cette conversion de manière concluante pour les types primitifs (voir annexe A.2), les collections Java et les classes simples, celui-ci a échoué pour ce qui concerne les classes plus complexes de l application. En effet, ces dernières, composées souvent de types complexes utilisant de l héritage assez abondamment, génèrent une foule de messages d erreurs lors de la sérialisation de celles-ci. Aussi, afin de résoudre ce 7 Nom de l interface. 66

5.4. ASPECTS TECHNIQUES problème, il a fallu créer, pour chaque classe complexe, une classe simple 8 pouvant hériter d une autre classe simple de façon à permettre une sérialisation sans embûches et éviter ainsi une longue chaîne d héritage. Par conséquent, tout objet de type complexe susceptible d être envoyé doit être converti en objet de type simple et inversement. Pour ce faire, chaque classe de sérialisation doit contenir un constructeur permettant d initialiser les différents attributs de celle-ci et ce, de manière récursive en faisant appel à d autres constructeurs de classes de sérialisation lorsque cela est nécessaire. De plus, chaque classe complexe doit implémenter un constructeur, prenant en paramètre l objet simple correspondant, qui initialisera les différents attributs et ce, également de manière récursive. 5.4.2 Couche de routage P2P Afin d implémenter la couche de routage P2P Pastry ainsi que la couche de communication de groupe, l utilisation du package FreePastry [32], une implémentation open-source de Pastry par Rice university, a été faite. La version de FreePastry utilisée 9 suivants : supporte les trois types de couches de transport Le mode direct : permet d effectuer une simulation de Pastry localement, c est-à-dire sans aucune communication réseau en émulant un réseau de noeuds Pastry. Le mode RMI : permet d utiliser comme couche de transport Java RMI. Le mode Wire : utilise une communication par sockets. Le but ici est donc de créer un nouveau mode Web Service. Tout ces modes de communication ont leur propre version des trois fichiers suivants (du mode RMI dans ce cas-ci) : RMINodeHandle.java : représente une référence vers un noeud Pastry qui sera utilisée par exemple dans le leaf set. Cette classe implémente les différents appels des méthodes d un noeud distant. Celle-ci sera donc la partie cliente de la couche de transport. 8 Classe composée d attributs primitifs ou d objets d autres classes simples et appelée classe de sérialisation dans la suite. 9 Version 1.3.1. 67

5.4. ASPECTS TECHNIQUES RMIPastryNode.java : représente un noeud en tant que tel qui va implémenter les différentes méthodes accessibles au monde extérieur. Il s agira donc ici de la partie serveur de la couche de transport. RMIPastryNodeFactory.java : permet de construire une instance d un PastryNode, d initialiser l ensemble de ses tables ainsi que ses différents dispositifs de communication. Cette classe permettra également la connexion du noeud créé à un noeud distant du réseau. La suite de cette section détaillera donc ces différents fichiers du mode Web Service créé ainsi que certains détails de sérialisation. WSNodeHandle.java Cette classe, héritant de la classe DistNodeHandle 10, devra contenir une référence vers le noeud distant associé de façon à permettre aisément les appels de méthodes via le service web. Pour ce faire, un attribut de type WSRemoteNodeI (qui est l interface du service web) est créé et initialisé en suivant les instructions décrites à la section 5.4.1. De plus, cette classe implémente les méthodes suivantes : void dosend(message msg) : il s agit de la méthode qui va effectuer l envoi en tant que tel d un message vers le noeud distant auquel fait référence cet objet. Elle va également traiter le problème de non-joignabilité du noeud distant ou tout autre problème menant à l échec de l envoi en marquant ce dernier comme susceptible d être mort. Cette mortalité sera vérifiée, par la suite, par le noeud local lors du rafraîchissement du leaf set. Dans le cas d un envoi réussi, le noeud distant sera marqué comme vivant. void receivemessageimpl(message msg) : cette méthode est appelée en pratique pour envoyer un message vers le noeud distant. Celle-ci va insérer ce message dans une file d attente de messages à envoyer. D ailleurs, ce sera cette file qui fera appel à la méthode dosend ci-dessus. void doping() : comme son nom l indique, cette méthode permet de vérifier si le noeud distant est vivant. Pour ce faire, la méthode va essayer de récupérer l identifiant du 10 Symbolise un noeud distant et est caractérisée notamment par une adresse réseau et un identifiant de noeud. 68

5.4. ASPECTS TECHNIQUES noeud distant (via la méthode getnodeid() du service web distant) et modifier le statut de vie de ce dernier, en conséquence de la réussite ou de l échec de cette opération. Un constructeur de sérialisation : ce constructeur aura pour tâches d initialiser les divers attributs du handle et surtout d initialiser le proxy qui permettra les connexions vers le service web du noeud distant. WSPastryNode.java WSPastryNode est une classe qui a pour tâches d implémenter les diverses méthodes du service web et prendre en charge des files d attente pour l envoi et la réception de messages. Pour ce faire, un tel objet aura deux processus chargés de vérifier le contenu de chacune des deux files et d effectuer l envoi ou la réception via l appel de fonctions adéquates. Il est à noter que l ensemble des comportements décrits dans la section Pastry du chapitre 2 est assuré par les classes parentes (en particulier la classe PastryNode). Les différentes méthodes implémentées pour le service web sont les suivantes : LeafSetMessage getleafsetm() : cette méthode a pour buts de récupérer le leaf set du noeud courant et de retourner comme résultat ce leaf set au format sérialisé. RouteSetMessage[ ] getrouterow(int row) : comme son nom l indique, cette méthode va récupérer une ligne de la table de routage du noeud local et retourner cette ligne au format sérialisé comme résultat. remotereceivemessage(sermessage msg, NodeId hopdest) : cette méthode va désérialiser le message et appeler une autre méthode locale, de même nom, qui va ajouter ce dernier à la file d attente de réception. Il est à noter que le polymorphisme est utilisé à ce stade, étant donné que les messages sont de types spécialisés multiples. De plus, la phase de désérialisation aura pour mission de tester les types de façon à reconstruire un message avec le bon type. Il est à noter que la méthode permettant de récupérer l identifiant du noeud est implémentée par la classe PastryNode. En effet, celle-ci ne nécessite aucun traitement spécifique à la couche P2P mais sera juste rendue disponible au monde extérieur. 69

5.4. ASPECTS TECHNIQUES WSPastryNodeFactory.java Cette classe a pour tâches de permettre la construction d un WSPastryNode ainsi que l initialisation de ce dernier. Pour ce faire, WSPastryNodeFactory implémente les méthodes suivantes : NodeHandle generatenodehandle(inetsocketaddress address) : Cette méthode va permettre de renvoyer un NodeHandle (de type WSNodeHandle) dont le proxy vers le noeud distant aura préalablement été initialisé. L utilisation de celle-ci est faite lors du démarrage d un noeud afin de construire une référence vers le noeud (de bootstrap), qui sera utilisé lors de la phase d initialisation. Il est à noter que l adresse passée en paramètre à cette méthode se verra convertie au format URI pour la construction du proxy. PastryNode newnode(bootstrap,nodeid) : Permet de créer un WSPastrynode qui sera initialisé à partir du noeud distant bootstrap. En pratique, cette méthode est appelée par une autre méthode (de même nom) qui se chargera de générer l identifiant du noeud. Après avoir effectué les différentes opérations concernant la publication du service web (décrites à la section 5.4.1), cette méthode va initialiser le leaf set ainsi que la table de routage du noeud créé. De plus, elle va initialiser les différents gestionnaires de messages particuliers (comme la demande de maintenance du leaf set) et y transmettre certains messages, démarrant ainsi la procédure de connexion au réseau. Méthode de proximité : WSPastryNodeFactory implémente également une méthode permettant de déterminer le noeud le plus proche entre deux selon une métrique de proximité. Dans cette application, cette métrique définit le temps total mis par la demande/réponse de l identifiant du noeud distant. Cette méthode ainsi que des méthodes de requête de tables diverses seront utilisées lors de l initialisation du noeud. 5.4.3 Couche de communication de groupe La couche de communication de groupe, utilisant Scribe inclus dans le package Free- Pastry, n a pas été modifiée de manière importante et respecte bien la description faite de Scribe au chapitre 4. Les modifications notables concernent la sérialisation des différents 70

5.5. EXPÉRIENCE ET RÉSULTATS messages pouvant être envoyés via service web. Il en est d ailleurs de même pour la couche de routage P2P. Ainsi, il est à remarquer une certaine dépendance entre les trois couches illustrées à la figure 5.1 vis-à-vis de la partie de sérialisation de la couche de transport service web : un ajout d un message dans un des protocoles (P2P ou communication de groupe) nécessitera l ajout du support de ce dernier au niveau de la (dé)sérialisation. 5.5 Expérience et résultats Afin d illustrer le bon fonctionnement des différentes couches modifiées, le développement d une application de type chat a été effectué. Celle-ci aura pour tâches de permettre, après l initialisation d un noeud à partir d un noeud distant, l appel des diverses méthodes implémentées par la couche de communication de groupe Scribe, l affichage des groupes, l affichage des messages reçus et l affichage de messages systèmes. Cette section présente l interface de l application et décrit également certains détails concernant l utilisation de la couche de communication de groupe. De plus, un exemple d exécution y est exposé. 5.5.1 L interface Lors de l exécution de l application, une première fenêtre appelée Connexion et illustrée à la figure 5.4 apparaît. Celle-ci permet à l utilisateur d insérer les différents paramètres afin que le noeud présent puisse se connecter au réseau. Pour ce faire, il convient d introduire le nom ou l adresse IP du noeud distant (comme par exemple localhost ou MyDesktop45) dans la case Adresse. De plus, le port distant ainsi que le port local sur lequel doit être déployé le service web du noeud local doivent être insérés dans les cases correspondantes. Dans le cas où le noeud que l on souhaite démarrer doit être le premier du réseau, il suffit de laisser la case Adresse vide. Il est à remarquer que les champs Adresse et port (distant) seront transformés par l application sous la forme du URI suivant : http://mydesktop45:9045/pastryservice La description WSDL du service web est, quant à elle, disponible pour ce noeud à l adresse : http://mydesktop45:9045/pastryservice/wsdl Après avoir inséré ces paramètres et avoir cliqué sur le bouton OK, une fenêtre composée d une barre de progression s ouvre de manière à informer l utilisateur de l état d avancement de la connexion au réseau. Il est à remarquer que cette connexion peut prendre un 71

5.5. EXPÉRIENCE ET RÉSULTATS Fig. 5.4 Fenêtre de connexion certain temps étant donné la procédure d initialisation de Pastry. La procédure d initialisation étant terminée, la fenêtre principale de l application, illustrée à la figure 5.5, fait son apparition. Cette fenêtre est divisée en plusieurs partitions décrites ci-dessous : Abrégé de l identifiant du noeud : celui-ci peut-être aperçu dans le coin supérieur gauche de la fenêtre. Messages reçus : cette partie affiche tous les messages reçus en modes multicast et anycast. Toutefois, afin de pouvoir réceptionner des messages en mode anycast, il convient de cocher la case présente dans cette portion. Liste des groupes : cette partie affiche la liste des groupes auxquels appartient le noeud. De plus, trois boutons permettent respectivement de créer un nouveau groupe, de s y connecter et de supprimer le groupe sélectionné dans la liste. Lorsque l utilisateur souhaite créer ou se connecter à un groupe, une fenêtre l invite à introduire le nom du groupe ainsi que le mot de passe qui sera utilisé pour (dé)crypter les messages envoyés/reçus pour ce groupe. Envoi d un message : permet à l utilisateur d insérer un message et de sélectionner le mode d envoi qui sera utilisé pour transmettre ce message au groupe sélectionné dans la liste. 72

5.5. EXPÉRIENCE ET RÉSULTATS Fig. 5.5 Fenêtre principale Messages systèmes : affiche certains messages systèmes tels que le transfert d un message, la défaillance du noeud parent, le changement de ce dernier et l ajout d un fils ou la défaillance de celui-ci (si le noeud courant est le parent). Le bouton Effacer permet de purger les messages systèmes et reçus. 5.5.2 L implémentation De manière à permettre une bonne interaction entre la couche de communication de groupe et l application, cette dernière doit implémenter l interface IScribeApp.java. Celleci doit être implémentée par n importe quelle application voulant utiliser Scribe. Les différentes méthodes devant être implémentées sont les suivantes : void scribeisready() : méthode appelée par la couche Scribe de manière à prévenir l application que celle-ci est prête. void receivemessage(msg) : est appelée par Scribe lorsqu un message de type multicast est arrivé. void forwardhandler(msg) : cette méthode est appelée par Scribe avant de transférer le message à ses enfants dans l arbre multicast. 73

5.5. EXPÉRIENCE ET RÉSULTATS void subscribehandler(topicid, child, wasadded, obj ) : est appelée par Scribe lorsque l un des enfants du noeud dans l arbre multicast apparaît ou disparaît. void faulthandler( msg, faultyparent ) : est appelée par Scribe avant qu un message de réparation ne soit envoyé lorsque ce noeud suspecte son parent d être défaillant. boolean anycasthandler(msg) : cette méthode est appelée par Scribe lors de la réception d un message de type anycast. Elle permet de vérifier si l application locale sait traiter celui-ci. Dans l affirmative, le message n est pas transféré aux autres noeuds. Dans le cas contraire, ce message sera transféré. void isnewroot(topicid) : indique au noeud local qu il devient le point de rendez-vous pour un certain groupe. void newparent( topicid, newparent, data) : cette méthode est appelée par Scribe afin d indiquer au noeud local que son parent dans l arbre multicast pour un certain groupe a changé. De plus, l application doit permettre, outre gérer l appartenance aux différents groupes ainsi que les mots de passe associés, l appel aux différentes méthodes de Scribe. On trouvera donc les méthodes suivantes : void creategrp(string grp, String mdp) : cette méthode va permettre, après avoir généré l identifiant du groupe, de faire appel aux méthodes create et join de Scribe ainsi que de gérer une liste contenant les groupes auxquels appartient le noeud local. void unsubscribe(string topic) : permet au noeud local de quitter un groupe en faisant appel à la méthode leave de Scribe ainsi qu en effectuant diverses opérations afin de supprimer le groupe de sa liste d appartenance. void send(string ms, String topic) : cette méthode va permettre d envoyer le message au groupe considéré en mode multicast. Elle va donc, après avoir crypté le contenu du message, faire appel à la méthode multicast de Scribe. void anycast(string ms, String topic) : permet au noeud local de crypter un message et de l envoyer en mode anycast au groupe considéré. void connectgrp(string grp, String mdp) : permet au noeud local de se connecter au groupe considéré en faisant appel à la méthode join de Scribe. Elle va également insérer le groupe ainsi que son mot de passe dans une liste d appartenance. 74

5.5. EXPÉRIENCE ET RÉSULTATS En ce qui concerne la sécurité, l application permet de crypter les messages envoyés via l algorithme de cryptage Blowfish [39], assurant ainsi la confidentialité de ceux-ci. Ce dernier est un algorithme de chiffrement symétrique par blocs de 64 bits utilisant une clé dont la longueur peut varier entre 32 et 448 bits. Sa rapidité d exécution ainsi que sa résistance confèrent à cet algorithme les caractéristiques nécessaires pour être utilisé dans l application. 5.5.3 Exemple d exécution Afin d illustrer le fonctionnement de l application, un exemple d exécution composé de plusieurs situations est décrit ci-dessous. Pour ce faire, les quatre noeuds suivants ont été créés : Identifiant du noeud noeud de connexion utilisé D69E32 / 906A71 D69E32 8D728D D69E32 98AD63 8D728D Les différents scénarios qui suivent sont classés par ordre chronologique d exécution. Création d un groupe Le noeud D69E32 créée un nouveau groupe nommé MyGroup avec comme mot de passe test en cliquant sur le bouton Créer et en remplissant ces données. Le message système suivant est alors affiché : New parent 0x8D728D.. for topic : 0x78D572.. Celui-ci renseigne le noeud que son parent pour ce groupe est le noeud 8D728D puisque ce dernier est numériquement plus proche de l identifiant 78D572 du groupe MyGroup que le noeud courant. Inscription à un groupe (1) Le noeud 8D728D souhaite faire partie du groupe MyGroup. Pour ce faire, l utilisateur clique sur le bouton Connecter et entre les différents paramètres. 75

5.5. EXPÉRIENCE ET RÉSULTATS Inscriptions à un groupe (2) Le noeud 906A71 souhaite également faire partie de ce groupe. Pour ce faire, l utilisateur procède de la même manière qu avec le noeud 8D728D. Ceci étant fait, le message système suivant signifiant que le noeud 8D728D est son parent apparaît au noeud 906A71 : New parent 0x8D728D.. for topic : 0x78D572.. De plus, le message système suivant apparaît au noeud 8D728D : child 0x906A71.. added for topic 0x78D572.. Ce dernier indique que le noeud 906A71 fait partie de ses enfants pour le groupe My- Group. Le noeud 98AD63 se connecte de la même manière à ce groupe et son parent est le noeud 8D728D. Ce dernier sera également averti de l arrivée d un nouveau fils. Défaillance de la racine Afin de simuler la défaillance de la racine, le noeud 8D728D est fermé via le bouton Quitter. Dès cet instant, la reconstruction de l arbre se produit. Le noeud 906A71 étant numériquement le plus proche de l identifiant du groupe, celui-ci devient la nouvelle racine de l arbre. Le message système suivant s affiche d ailleurs à ce dernier : IS ROOT for topic : 0x78D572.. Ce message indique à ce noeud qu il est devenu la racine pour le groupe considéré. Peu après, les noeuds D69E32 et 98AD63 détectent la défaillance de leur parent (la racine 8D728D). Ces deux noeuds affichent alors comme messages systèmes les messages suivants : Parent failure detected! New parent 0x906A71.. for topic : 0x78D572.. Ce dernier message indique le nouveau parent. De plus, le noeud 906A71 affichent les messages suivants indiquant l ajout des deux noeuds dans sa table d enfants : child 0x98AD63.. added for topic 0x78D572.. child 0xD69E32.. added for topic 0x78D572.. Multicast d un message Le noeud 98AD63 envoie un message en mode multicast. Pour ce faire, ce dernier sélectionne le groupe dans la liste, entre son message, coche la case multicast et clique sur le bouton Envoyer. On remarque alors que les trois noeuds reçoivent ce message correctement. 76

5.5. EXPÉRIENCE ET RÉSULTATS Dans le cas où un des noeuds a indiqué un mauvais mot de passe lors de sa connexion au groupe, le message devant apparaître crypté est remplacé par des dièses et un message système l en avertit. Anycast d un message Les noeuds 98AD63 et D69E32 cochent la case pour accepter les messages en mode anycast. Le noeud 906A71 effectue l envoi en mode anycast d un message qui sera réceptionné seulement par le noeud 98AD63. Si l utilisateur désactive l arrivée de messages anycast au noeud 98AD63 et que 906A71 effectue à nouveau l envoi, seul le noeud restant le reçoit. Départ d un enfant Afin de se désinscrire du groupe, le noeud D69E32 sélectionne le groupe dans la liste et clique sur le bouton Supprimer. Celui-ci ne recevra donc plus de messages associés à ce groupe. De plus, son parent (906A71) reçoit son message de désinscription et affiche : child 0xD69E32.. removed for topic 0x78D572.. 77

Chapitre 6 Conclusions Ainsi, la première partie de ce travail a démontré la puissance de la technologie XML et sa plus-value dans le domaine des services web. En effet, cette technologie est utilisée abondamment afin de représenter les types de données via des schémas XML, structurer les messages SOAP, permettre à WSDL de décrire les différents services d un service web et rendre possible la mise en place de mécanismes de sécurité autour de celle-ci. Dès lors, XML constitue la base sur laquelle la technologie des services web repose. De ce fait, ces derniers héritent des avantages mais également des inconvénients de la technologie XML. Dans cet ordre idées, peuvent être cités les avantages de l interopérabilité ainsi que d une grande étendue d utilisation. Néanmoins, XML a une influence négative directe sur les performances des services web par rapport à d autres moyens de communication étant donné qu un document XML est plus lourd à transmettre et donc utilise plus de bande passante. Dans un second temps, ce mémoire a exposé l utilité d opter pour une architecture de type peer-to-peer par rapport à une architecture centralisée. En effet, un système peer-topeer permet d éviter un goulot d étranglement d un point de vue de performance d une part, ainsi qu un point unique de défaillance d autre part. De plus, de tels systèmes présentent des propriétés intéressantes telles que la répartition de la charge, une extensibilité globale ou encore l auto-adaptation face au départ ou à l ajout de noeuds et ce, à n importe quel instant. Finalement, ces systèmes requièrent des algorithmes de placement de données entre les différentes peers. Le choix opéré entre de tels algorithmes constitue donc un point clé 78

afin d obtenir des bonnes performances et d éviter, au maximum, des défaillances ayant pour conséquence d empêcher l accès à certaines ressources. De plus, ce document a traité tant des différents avantages que des inconvénients à utiliser les services web comme couche de transport d une architecture peer-to-peer. Ainsi, l utilisation d XML par les services web permet aux réseaux peer-to-peer de profiter du concept d interopérabilité, mais au prix d une perte de performance. En outre, dans une telle combinaison, un effort supplémentaire doit être fourni de façon à effectuer les sérialisations nécessaires au bon fonctionnement du système. Finalement, une preuve de faisabilité d un système, utilisant une telle combinaison, a été apportée par l implémentation d une application permettant une communication de groupe reposant sur une architecture peer-to-peer qui, elle, utilise les services web. Cette dernière a mis en évidence les problèmes de sérialisations ainsi que l importance des choix des différents paramètres de synchronisation du système, puisqu il s agit là d un compromis à effectuer entre la charge au niveau de la bande passante utilisée et le temps de validité des données de routage. En effet, plus la synchronisation des ensembles nécessaires au routage est fréquent, plus la validité de ces données est garantie mais cela, au détriment d une plus grande charge du réseau. Ainsi, la combinaison des services web avec une architecture peer-to-peer ouvre ses portes vers des applications nécessitant une très grande souplesse de fonctionnement vis-àvis de la défaillance de noeuds tout en permettant de profiter du principe d interopérabilité qu offrent les services web. 79

Annexe A Annexes A.1 WSRemoteNodeI.java Code source A.1 Interface du service web d un noeud 1 public interface WSRemoteNodeI{ public LeafSetMessage getleafsetm ( ) throws Exception ; public RouteSetMessage [ ] getrouterow ( int row ) throws Exception ; 5 public NodeId getnodeid ( ) throws Exception ; public void remotereceivemessage ( SerMessage msg, NodeId hopdest ) throws Exception ; } 80

A.2. MAPPING TYPE JAVA - XML SCHÉMA A.2 Mapping type Java - XML schéma Java Type Schema Type boolean boolean byte byte byte[] binary char string double double float float int int java.lang.boolean boolean java.lang.byte byte java.lang.character string java.lang.double double java.lang.float float java.lang.integer int java.lang.long long java.lang.object anytype java.lang.object anysimpletype java.lang.object simpletype java.lang.object urtype java.lang.short short java.lang.string string java.lang.string timeinstant java.lang.string uri java.lang.string language java.lang.string NMTOKEN java.lang.string NMTOKENS java.lang.string Name java.lang.string NCName java.lang.string ID Suite page suivante... 81

A.2. MAPPING TYPE JAVA - XML SCHÉMA suite de la page précédente Java Type java.lang.string java.lang.string java.lang.string java.lang.string java.lang.string java.math.bigdecimal java.math.biginteger java.math.biginteger java.math.biginteger java.math.biginteger java.math.biginteger javax.xml.namespace.qname long java.sql.date java.sql.time java.sql.timestamp java.util.date org.idoox.wasp.serialization.xsdbuiltin.date org.idoox.wasp.serialization.xsdbuiltin.duration org.idoox.wasp.serialization.xsdbuiltin.time short Schema Type IDREF IDREFS ENTITY ENTITIES NOTATION decimal integer non-negative-integer positive-integer non-positive-integer negative-integer QName long datetime datetime datetime datetime date timeduration time short Tab. A.1 Mapping des types primitifs Java - schémas XML 82

A.3. PUBLICATION DE SERVICES WEB A.3 Publication de services web Code source A.2 Extrait de la publication d un service web de WSPastryNodeFactory.java 1 // c r e a t e new Java2WSDL p r o c e s s o r Java2WSDL java2wsdl = Java2WSDLFactory. newjava2wsdl ( ) ; // customize the c r e a t e d p r o c e s s o r add i n h e r i t e d t y p e s Set extratypes = new HashSet ( ) ; 5 extratypes. add ( r i c e. pastry.ws. messaging. LeafSetMessage. class ) ; extratypes. add ( r i c e. pastry.ws. messaging. NodeHandleMessage. class ) ; extratypes. add ( r i c e. pastry.ws. messaging. RouteSetMessage. class ) ; extratypes. add ( r i c e. pastry.ws. messaging. SimilarSetMessage. class ) ;... 10 java2wsdl. setextratypes ( extratypes ) ; // g e n e r a te wsdl d e f i n i t i o n D e f i n i t i o n wsdl = java2wsdl. g e n e r a t e D e f i n i t i o n (WSRemoteNodeI. class ) ; 15 S e r v i c e I n s t a n c e s e r v i c e I n s t a n c e = S e r v i c e I n s t a n c e. c r e a t e ( pn ) ; Wasp. s t a r t S e r v e r ( http : / / + address. gethostname ( ) + : + address. getport ( ) ) ; ServiceEndpoint Endpoint = ServiceEndpoint. c r e a t e ( / P a s t r y S e r v i c e, s e r v i c e I n s t a n c e ) ; Endpoint. setwsdl( wsdl ) ; R e g i s t r y. p u b l i s h ( Endpoint ) ; 83

Bibliographie [1] A. Crochet-Damais. Web Services : retour sur XKMS avec webmethods. JDNet, 2001. http://www.journaldunet.com/solutions/0104/010423 webmethods.shtml. [2] G. Alonso, F. Casati, H. Kuno, and V. Machiraju. Web Services : Concepts, Architecture and Applications. Springer, 2004. [3] Apache. Apache Axis. http://ws.apache.org/axis/. [4] T. Berners-Lee, R. Fielding, and L. Masinter. RFC3986 : Uniform Resource Identifier (URI) : Generic Syntax, 2005. http://gbiv.com/protocols/uri/rfc/rfc3986.html. [5] B. Cain, S. Deering, I. Kouvelas, B. Fenner, and A. Thyagarajan. RFC3376 : Internet Group Management Protocol, Version 3, 2002. http://www.faqs.org/rfcs/rfc3376.html. [6] M. Castro, P. Druschel, A. Kermarrec, and A. Rowstron. SCRIBE : A large-scale and decentralized application-level multicast infrastructure. Selected Areas in Communications, 20(8) :1489 1499, 2002. http://research.microsoft.com/ antr/past/jsac.pdf. [7] E. Cerami. Web Services Essentials. O Reilly, 2002. [8] G. Coulouris, J. Dollimore, and T. Kindberg. Distributed systems : concepts and design. Addison-Wesley Longman Publishing Co. Inc., fourth edition, 2005. [9] R. Cover. Web Services Security Specification (WS-Security, WS-Security 2004), 2006. http://xml.coverpages.org/ws-security.html. [10] F. Deliège. Web services for the management of persistent online game factions. Master s thesis, ULB, 2005. [11] D. Eastlake and P. Jones. RFC3174 : US Secure Hash Algorithm 1 (SHA1), 2001. http://www.ietf.org/rfc/rfc3174.txt. [12] T. Erl. Service-Oriented Architecture : A Field Guide to Integrating XML and Web Services. Prentice Hall PTR, 2004. 84

BIBLIOGRAPHIE [13] Evans Data Corporation. Finding Growth in SOA and Web Services Implementation, 2006. http://www.evansdata.com/n2/pr/releases/web%20services%207 18 06.shtml. [14] N.A.B. Gray. Comparison of Web Services, Java-RMI, and CORBA service implementations. In Fifth Australasian Workshop on Software and System Architectures (AS- WEC 2004), pages 52 63, 2004. http://mercury.it.swin.edu.au/ctg/awsa04/papers/ gray.pdf. [15] IBM and Microsoft. Security in a Web Services World : A Proposed Architecture and Roadmap. 2002. http://msdn2.microsoft.com/en-us/library/ms977312.aspx. [16] ITU-T. ITU-T Recommendation X.509, 2005. http://www.itu.int/rec/t-rec-x.509/ en. [17] H. Kadima and V. Montfort. Les Web services : techniques, démarches et outils XML, WSDL, SOAP, UDDI, Rosetta, UML. Dunod, 2003. [18] D. Karger, E. Lehman, T. Leighton, R. Panigrahy, M. Levine, and D. Lewin. Consistent hashing and random trees : distributed caching protocols for relieving hot spots on the World Wide Web. In ACM Symposium on Theory of Computing, pages 654 663, 1997. [19] K. Katrinis and M. May. Application-Layer Multicast. In Peer-to-Peer Systems and Applications, volume 3485, pages 157 170, 2005. [20] J. Kohl and C. Neuman. RFC1510 : The Kerberos Network Authentication Service (V5), 1993. http://www.ietf.org/rfc/rfc1510.txt. [21] E. Keong Lua, J. Crowcroft, M. Pias, R. Sharma, and S. Lim. A Survey and Comparison of Peer-to-Peer Overlay Network Schemes. Communications Surveys & Tutorials, pages 72 93, 2004. http://www.cl.cam.ac.uk/teaching/2005/advsystop/survey.pdf. [22] L. Maesano, C. Bernard, and X. Le Galles. Services Web avec J2EE et.net : conception et implémentation. Eyrolles, 2003. [23] A. Mantrach. Les services Web avec SOAP, WSDL et UDDI. Master s thesis, ULB, 2003. [24] B. Nielsen. Introduction to distributed systems - peer-to-peer systems, 2006. http: //www.cs.aau.dk/ bnielsen/ds-e07/material/p2p.pdf. [25] OASIS. Web Services Business Process Execution Language Version 2.0. http://docs. oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html. [26] OASIS. UDDI, 2006. http://www.uddi.org. 85

BIBLIOGRAPHIE [27] OASIS. Web Services Security : SOAP Message Security 1.1 (WS-Security 2004), 2006. http://www.oasis-open.org/specs/index.php#wssv1.1. [28] OpenNap. OpenNap : Open Source Napster Server, 2001. http://opennap.sourceforge. net/. [29] P. Papanastassiou. Comparaison entre les solutions de développement de Web Services Microsoft (environnement.net) et Sun (environnement ONE-Java). Master s thesis, ULB, 2003. [30] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Schenker. A scalable contentaddressable network. In Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM 01), number 4, pages 161 172, 2001. http://berkeley.intel-research.net/sylvia/cans.pdf. [31] S. Ratnasamy, M. Handley, R. Karp, and S. Shenker. Application-Level Multicast Using Content-Addressable Networks. In Proceedings of the Third International COST264 Workshop on Networked Group Communication (NGC 01), pages 14 29, 2001. http://berkeley.intel-research.net/sylvia/can-mcast.pdf. [32] Rice University. FreePastry. http://www.freepastry.org/freepastry/readme-1.3.1. html. [33] J. Rosenberg and D. Remy. Securing Web Services with WS-Security. Sams Publishing, 2004. [34] A. Rowstron and P. Druschel. Pastry : Scalable, distributed object location and routing for large-scale peer-to-peer systems. In Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms Heidelberg (Middleware 01), pages 329 350, 2001. http://www.research.microsoft.com/ antr/past/pastry.pdf. [35] O. D. Sahin, C. Evren Gerede, D. Agrawal, A. El Abbadi, O. H. Ibarra, and J. Su. SPiDeR : P2P-Based Web Service Discovery. In Proceedings of the Third International Conference Service-Oriented Computing (ICSOC 2005), pages 157 169, 2005. http: //www.cs.ucsb.edu/ odsahin/papers/icsoc2005.pdf. [36] Y. Sam and O. Boucelma. Personnalisation de Services Web : Approche Fondée sur la Composition. In Troisième conférence en Recherche d Information et Applications (CORIA 2006), pages 237 248, 2006. http://www.irit.fr/aria/2006/237.pdf. [37] M. Schlosser, M. Sintek, S. Decker, and W. Nejdl. A Scalable and Ontology-Based P2P Infrastructure for Semantic Web Services. In Peer-to-Peer Computing, Second Inter- 86

BIBLIOGRAPHIE national Conference, pages 104 111, 2002. http://www.kbs.uni-hannover.de/arbeiten/ Publikationen/2002/P2P2002.pdf. [38] C. Schmidt and M. Parashar. A peer-to-peer approach to web service discovery. World Wide Web, 7(2) :211 229, 2004. http://www.caip.rutgers.edu/ cristins/webserv.pdf. [39] B. Schneier. The Blowfish Encryption Algorithm. http://www.schneier.com/blowfish. html. [40] R. Steinmetz and K. Wehrle, editors. Peer-to-Peer Systems and Applications, volume 3485 of LNCS. Springer, 2005. http://www.peer-to-peer.info/. [41] I. Stoica, R. Morris, D. Karger, F. Kaashoek, and H. Balakrishnan. Chord : a scalable peer-to-peer lookup protocol for internet applications. In Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM 01), pages 149 160, 2001. http://pdos.csail.mit.edu/ papers/chord:sigcomm01/chord sigcomm.pdf. [42] Systinet. Systinet Server For Java. http://www.systinet.com/products/ssj/overview. [43] A. Tanenbaum. Réseaux. Pearson Education, fourth edition, 2003. [44] D. Tidwell, J. Snell, and P. Kulchenko. Programming Web Services with SOAP. O Reilly, 2001. [45] A. Tsalgatidou and T. Pilioura. An Overview of Standards and Related Technology in Web Services. Distributed and Parallel Databases, 12(2-3) :135 162, 2002. http: //www.springerlink.com/content/l2746455w4674t04. [46] Verisign. XML Trust Services - XKMS. http://www.verisign.com/developer/xml/xkms. html. [47] K. Verma, K. Sivashanmugam, A. Sheth, A. Patil, S. Oundhakar, and J. Miller. METEOR-S WSDI : A Scalable P2P Infrastructure of Registries for Semantic Publication and Discovery of Web Services. Information Technology and Management, 6(1) :17 39, 2005. http://knoesis.wright.edu/library/download/vsspom 05-MWSDI-JITM.pdf. [48] W3C. Web Services Description Language (WSDL) 1.1, 2001. http://www.w3.org/ TR/wsdl. [49] W3C. XML Key Management Specification (XKMS), 2001. http://www.w3.org/tr/ xkms/. [50] W3C. XML Encryption Syntax and Processing, 2002. http://www.w3.org/tr/ xmlenc-core/. 87

BIBLIOGRAPHIE [51] W3C. XML-Signature Syntax and Processing, 2002. http://www.w3.org/tr/ xmldsig-core/. [52] W3C. SOAP Version 1.2, 2003. http://www.w3.org/tr/soap12-part0/. [53] W3C. Web Services Architecture, 2004. http://www.w3.org/tr/2004/ NOTE-ws-arch-20040211/. [54] W3C. Web Services Architecture Requirements, 2004. http://www.w3.org/tr/ wsa-reqs/#id2604831. [55] W3C. Extensible Markup Language (XML) 1.0, 2006. http://www.w3.org/tr/2006/ REC-xml-20060816/. [56] B. Zhao, J. Kubiatowicz, and A. Joseph. Tapestry : An Infrastructure for Faulttolerant Wide-area Location and Routing. Technical report, UC Berkeley, 2001. http: //bnrg.cs.berkeley.edu/ adj/publications/paper-files/csd-01-1141.pdf. 88