Ministère de l'education Nationale UNIVERSITE MONTPELLIER II SCIENCES ET TECHNIQUES DU LANGUEDOC-ROUSSILLON. D.E.A. Informatique Ecole Doctorale I2S

Transcription

1 Ministère de l'education Nationale UNIVERSITE MONTPELLIER II SCIENCES ET TECHNIQUES DU LANGUEDOC-ROUSSILLON D.E.A. Informatique Ecole Doctorale I2S Rapport de stage BASTIDE Gautier Directeur de stage : Pierre Pompidor Sujet : Recherche de ressources pédagogiques dans les réseaux pair-à-pair Du 01/03/2004 au 01/07/2004 Laboratoire : L.I.R.M.M. 161, rue Ada Montpellier

2 Remerciements J adresse à Madame Danièle Hérin, directrice du groupe de recherche, mes chaleureux remerciements pour son soutien et ses précieux conseils. Je suis particulièrement reconnaissant envers Monsieur Pierre Pompidor, mon directeur de stage, pour sa collaboration et son aide dans mes recherches. Ma gratitude va également vers Monsieur Michel Sala pour ses conseils. Je remercie bien vivement tous les membres de l équipe Weblearn du L.I.RM.M. qui ont travaillé à mes cotés pendant tout le déroulement de mon stage de recherche. Je désire associer à mes remerciements l équipe de Monsieur Wolfgang Nejdl pour les réponses qu ils ont apportées à mes questions. 2

3 Résumé Les réseaux pair-à-pair sont de plus en plus utilisés pour organiser des systèmes de partage de ressources. Leur atout majeur est la décentralisation. Mon travail consiste à étudier les différentes plates-formes pair-à-pair possédant des schémas de données évolués et utilisant des méta-langages pour les manipuler. Une comparaison des différentes plates-formes existantes permet de mettre en avant les différents services proposés dans la gestion d un réseau pair-à-pair. Dans le domaine du e-learning, la plate-forme Edutella se révèle être la plus complète. Le service de recherche de ressources doit être d une efficacité réelle pour ce type de réseau totalement décentralisé. Après avoir étudié, le système de gestion des requêtes mis en place dans le cadre du projet Edutella, mon travail consiste à proposer une amélioration de ce dernier. La localisation des ressources se fait par l intermédiaire de tables possédant plusieurs niveaux de granularité, relatives à la description des ressources que les utilisateurs du réseau se proposent de partager. L intégration d un outil de gestion d ontologie pour organiser le partage des données et modéliser les liens entre les ressources permettrait en complément aux tables de routage citées précédemment de retrouver et de localiser plus efficacement les ressources pédagogiques disponibles. Mon travail consiste à présenter les différents scénarios relatifs à l intégration de Kaon qui est une plate-forme de gestion d ontologies dans le réseau pair-à-pair Edutella. 3

4 Table des matières Remerciements... 2 Résumé Introduction Les réseaux pair-à-pair Définition : qu est-ce qu un réseau pair-à-pair? Le modèle pair-à-pair centralisé Le modèle pair-à-pair décentralisé Le modèle pair-à-pair hybride : topologie «super-peer» Etat de l art Liste des plates-formes pair-à-pair reposant sur des schémas de données AmbientDB Chatty Web DBGlobe Edutella Gaia Hyperion KEx PeerDB P-Grid Piazza Swap Tableaux comparatifs des différentes plates-formes Bilan Gestion des ontologies Présentation de Kaon Intégration de Kaon dans Edutella Objectifs Gestion des méta-données relatives aux ressources pédagogiques Gestion des ontologies au niveau des supers-noeuds Scénario de jonction d un nouveau pair fournisseur Scénario de recherche de ressources pédagogiques dans le réseau Conclusion et perspectives Bibliographie Liens Internet

5 Table des figures Figure 1. Modèle pair-à-pair centralisé... 9 Figure 2. Modèle pair-à-pair décentralisé Figure 3. Modèle pair-à-pair avec supers-nœuds Figure 4. Architecture du système AmbientDB [10] Figure 5. Architecture d un CAS [4] Figure 6. Architecture en couche de JXTA [1] Figure 7. Topologie hyper-cube [16] Figure 8. Exemple de table de routage d un super-nœud Figure 9. Exemple d'arbre de requête en RDF-QEL Figure 10. Système de requête utilisé par Edutella Figure 11. Architecture d'un pair destiné à gérer les annotations [2] Figure 12. Interface Swing Consumer Figure 13. Interface Swebok Consumer Figure 14. Interface Dublin Core Consumer Figure 15. Architecture Hyperion [6] Figure 16. Les principaux composants du système KEx [13] Figure 17. Architecture d un nœud dans un réseau PeerDB [9] Figure 18. Exemple d architecture P-Grid [8] Figure 19. Architecture Swap [5] Figure 20. Architecture de la plate-forme Kaon [18] Figure 21. Interface IO-Modeler de Kaon Figure 22. Interface IO-Modeler de Kaon Figure 23. Maquette d'interface Edutella intégrant Kaon Figure 24. Création d'un noyau de ressources annotées Figure 25. Annotation de ressources pédagogiques : cas n Figure 26. Annotation de ressources pédagogiques : cas n 1 bis Figure 27. Annotation de ressources pédagogiques : cas n Figure 28. Propagation des méta-données : intersection Figure 29. Propagation des méta-données : généralisation locale Figure 30. Propagation des méta-données : généralisation externe Figure 31. Algorithme de remplissage des méta-données Figure 32. Exemple de fichier XML généré par l'algorithme Figure 33. Exemple de fichier RDF généré par l'algorithme Figure 34. Exemple de modèle d ontologie correspondant à la gestion d un super-nœud Figure 35. Représentation des connaissances Figure 36. Exemple de modèle d ontologie pour les mathématiques [21] Figure 37. Scénario de jonction d'un nouveau pair fournisseur Edutella Figure 38. Scénario de recherche de ressources dans un réseau Edutella intégrant Kaon Tableau 1. AmbientDB, Chatty Web, DBGlobe et Edutella Tableau 2. Gaia, Hyperion, KEx et PeerDB Tableau 3. P-Grid, Piazza et Swap

6 1. Introduction Un des objectifs de notre équipe de recherche est de concevoir des outils permettant à des professeurs de composer des cours à partir de données de diverses natures réparties sur plusieurs sources. L utilisation d un réseau pair-à-pair comme environnement de partage de ressources s avère être la plus appropriée car elle permet aux utilisateurs de rester maître en permanence des documents qu ils se proposent de partager. En effet, les propriétaires des ressources n ont pas l obligation de déposer leur travail sur un serveur centralisé. Les données sont stockées directement sur les machines de l utilisateur, ce qui lui permet de partager de nouvelles ressources, de modifier celles existantes et de supprimer celles qu il ne souhaite plus partager. Toutes ces opérations se font localement. La décentralisation est un atout majeur pour ce type de réseau. Mon travail se décompose en deux parties. La première consiste à établir une liste de systèmes pair-à-pair évolués c est-à-dire possédant leurs propres schémas de données. L objectif est de mettre en avant une plate-forme pair-à-pair qui soit la mieux adaptée au e- learning. L étude de ses différents projets permet d établir des tableaux comparatifs suivant un certain nombre de critères de sélection comme les services proposés, la topologie du réseau, les outils ainsi que les langages utilisés Les principales caractéristiques que doit posséder une plate-forme pair-à-pair destinée au partage de ressources pédagogiques sont les suivantes : tout d abord, il doit adopter une topologie «super-peer» car celle-ci se révèle être la plus efficace pour administrer un réseau pair-à-pair. En effet, dans une topologie totalement décentralisée, certains services comme celui de la recherche de ressources mobilisent une grande partie de la bande passante du réseau de part les techniques utilisées pour la diffusion des requêtes (techniques d inondation du réseau). Dans le cas d une topologie «super-peer», les entités du réseau sont regroupées en «cluster» possédant certaines propriétés, ce qui permet de cibler les recherches et donc de ne pas monopoliser la bande passante. D autre part, la quantité et la nature des services proposés par les plates-formes sont également des critères de sélection. La plate-forme que l on recherche doit intégrer un service de recherche de ressources, un service de médiation et de «mapping» mais également, un service d annotations. Un des points essentiels dans la réalisation de ce type d application est la recherche des ressources. En effet, le but du projet de mon équipe est de retrouver des morceaux de ressources pédagogiques afin de les assembler pour former un cours qui soit le plus cohérent et le plus complet possible. Pour cela, il est indispensable de posséder des outils de recherche efficaces de manière à sélectionner les meilleurs composants possibles et les mieux adaptés au contexte. Pour cela, il est nécessaire de décrire les ressources par des métadonnées et de modéliser les liens sémantiques de manière à établir des relations entre les données qui sont partagées. Les outils d annotations sont également indispensables dans le domaine du e-learning. De plus, il est obligatoire que la plate-forme soit capable de manipuler des schémas de description de données du type IEEE LOM ou SCORM qui sont des modèles en matière de e-learning. Par ailleurs, il doit posséder tous les outils et langages nécessaires à la manipulation de ces schémas de données. La plate-forme proposée par le projet EDUTELLA satisfait une grande majorité des critères ainsi retenus. Pour cette raison, ce projet sera étudié en détail dans l état de l art de ce rapport. La deuxième partie de mon travail consiste à proposer une nouvelle méthode pour gérer l organisation des ressources pédagogiques au niveau des supers-nœuds du réseau Edutella. L objectif est de faciliter la recherche des ressources pédagogiques au sein du réseau. L utilisation d un outil de gestion d ontologies comme celui proposé dans le cadre du projet Kaon va permettre de modéliser les liens sémantiques entre les ressources. Les 6

7 prototypes proposés dans le cadre du projet Edutella ne fournissent qu une liste de résultats non organisés. Le but final de mon travail est de proposer à l utilisateur des réponses à ses requêtes lui permettant de visualiser les liens entre les ressources. La proposition d intégration de Kaon dans Edutella s échelonne sur plusieurs niveaux : des ressources pédagogiques aux ontologies. Dans un premier temps, il est nécessaire d étudier les problèmes liés à la gestion des méta-données. Toutes les ressources pédagogiques doivent impérativement être décrites de manière à mettre en avant les liens sémantiques. Les ressources qui ne sont pas annotées par leurs auteurs doivent être automatiquement analysées pour en extraire les mots clefs, les titres des chapitres et surtout la bibliographie. Il est alors possible d établir des stratégies de remplissage des méta-données. Puis, le second niveau est consacré à la gestion des ontologies au sein des supers-nœuds du réseau. Une question se pose alors : comment modéliser les ressources pédagogiques de sorte à ce qu elles puissent être retrouvées et localisées facilement et rapidement? Pour cela, les ressources doivent être considérées comme des instances de concept ou de sous-concept du modèle contenu dans le super-nœud. Après, s être penché sur les différentes phases d instanciation du réseau à savoir la connexion d un nouveau pair fournisseur ou bien la mise à disposition d une nouvelle ressource par un pair existant, mon travail consiste à proposer des scénarios de recherche de ressources pédagogiques au sein du réseau Edutella intégrant la plate-forme Kaon. Ce rapport se divise en trois parties. La première partie fournit un ensemble de définitions relatives au réseau pair-à-pair. La deuxième partie contient un état de l art des différentes plates-formes p2p de partage de ressources possédant un moteur de recherche évolué, reposant sur des schémas de données et des méta-langages permettant de les manipuler. Pour cela, les ressources doivent être décrites par des méta-données qui obéissent à des schémas prédéfinis. Les différents projets sont comparés de manière à faire ressortir les plates-formes les plus efficaces pour le partage de ressources pédagogiques dans le domaine du e-learning. La troisième partie de ce rapport est consacrée à ma proposition d intégration d un outil de gestion d ontologie pour modéliser les ressources au sein des supers-nœuds du réseau Edutella. 7

8 2. Les réseaux pair-à-pair 2.1 Définition : qu est-ce qu un réseau pair-à-pair? Le terme p2p (Peer-to-Peer, que l on peut traduire par «pair-à-pair» ou «égal-àégal») tel qu il est défini dans l encyclopédie Wikipédia désigne «des protocoles et des réseaux informatiques dont les éléments (les nœuds) ne jouent pas exclusivement les rôles de clients ou de serveurs mais fonctionnent des deux façons, en étant à la fois clients et serveurs des autres nœuds de ces réseaux, contrairement aux systèmes de type client-serveur, au sens habituel du terme». Les échanges peuvent se faire au niveau des données mais aussi, au niveau de la puissance de calcul et de l espace de stockage. Il existe plusieurs types de réseaux pair-à-pair qui diffèrent selon qu ils soient plus ou moins décentralisés (cf. Partie 2. Les différents types de réseaux pair-à-pair). Les avantages de ce type d architecture de réseau sont multiples : tout d abord, l information est disponible directement à sa source. Il n y a pas de problème de stockage car les données sont sur les disques durs des internautes connectés au réseau et le traitement des données se fait en local. La principale caractéristique d un réseau pair-à-pair est son indépendance vis-à-vis d une architecture centrale et des machines. En effet, tout type de matériels peut être intégré au réseau (ordinateurs, PDA, téléphones ). De plus, la mise en œuvre est instantanée. Les utilisateurs peuvent se connecter directement entre eux, sans avoir besoin d un serveur central (dans la majorité des cas pour les réseaux pair-à-pair) de manière à pouvoir échanger librement les fichiers qu ils souhaitent partager, ou même fournir de la puissance de calcul. L un des enjeux majeurs dans les réseaux pair-à-pair est la recherche de ressources. En effet, il n est pas évident de trouver l information que l on recherche à l intérieur d un réseau. Les moteurs de recherche actuels montrent leurs limites. Ils ne fournissent que rarement les informations que l on recherche ou bien celles-ci sont empaquetées dans une trop grande quantité de données. De plus, ces outils n indexent qu une infime partie des ressources réellement disponibles. Tout cela ne permet pas de satisfaire l utilisateur. Il existe une grande quantité d architectures de réseau pair-à-pair différentes. Les deux principales sont le modèle centralisé et le modèle décentralisé. Les variantes qui combinent ces deux modèles sont nombreuses et présentent de nombreux attraits car elles permettent de combiner les atouts de chacun d entre eux. Elles diffèrent essentiellement par leur niveau de décentralisation. 2.2 Le modèle pair-à-pair centralisé Tout d abord, il existe des réseaux pair-à-pair centralisés. Chacun de ces réseaux est formé de pairs et d un serveur central dont le rôle est d indexer les pairs connectés au réseau ainsi que les ressources disponibles (puissance de calcul, capacité de stockage, données ). Les pairs utilisent le serveur central pour localiser les ressources qu ils recherchent, puis communiquent directement entre eux (sans passer par le serveur central). 8

9 Cette topologie de réseau est très peu utilisée car elle ne permet pas d exploiter au maximum la principale qualité d un réseau pair-à-pair à savoir sa décentralisation. Un autre désavantage de cette topologie réside dans le fait qu il n existe qu un seul point d entrée au réseau et donc si le serveur tombe en panne, le réseau tout entier devient alors inutilisable. Ce type d architecture possède, tout de même, de nombreux avantages comme la rapidité et l efficacité de la localisation des ressources car toutes les informations nécessaires à la gestion du réseau sont indexées sur une même machine (le serveur central). Un des points clefs de ce modèle tient dans la mise à jour des tables d indexations contenues dans le serveur central Pairs Serveur central Figure 1. Modèle pair-à-pair centralisé 2.3 Le modèle pair-à-pair décentralisé Il existe également des réseaux pairs-à-pairs décentralisés. Ces derniers sont composés de nœuds qui sont susceptibles de fournir des ressources au réseau. Ils sont également chargés du routage des messages. La stratégie utilisée est généralement l inondation du réseau : le message (requête) émis par un pair est envoyé à ses plus proches voisins qui le relayent aussitôt au niveau suivant (i.e. aux voisins de celui-ci). Lorsque la ressource est enfin localisée, la réponse est renvoyée à l émetteur de la requête suivant le même chemin. Ce modèle est beaucoup plus tolérant aux pannes que le précédent car il n existe pas d unité centralisée. Un pair peut se connecter sur n importe quel nœud du réseau contrairement à l autre modèle où il devait impérativement se connecter au serveur central. Le seul inconvénient majeur de cette topologie de réseau est l utilisation d une très grande quantité de messages pour gérer au mieux le réseau. Ces problèmes sont essentiellement dus aux techniques d inondations qui sont utilisées pour envoyer des messages et rechercher des informations. La bande passante du réseau risque d être rapidement saturée par les services de recherche de ressources. 9

10 Nœuds Pairs Figure 2. Modèle pair-à-pair décentralisé 2.4 Le modèle pair-à-pair hybride : topologie «super-peer» Pour pallier le problème des réseaux décentralisés décrits précédemment, il a été proposé de nombreuses variantes (modèle hiérarchique, modèle en anneau, modèle avec supers-nœuds ). L objectif est de créer des systèmes de partage de ressources efficaces de manière à faciliter le routage des messages et par conséquent la recherche de ressources à l intérieur du réseau. Certaines topologies permettent une meilleure maintenance du réseau et favorisent grandement la sécurité. L architecture la plus utilisée est le modèle avec supers-nœuds. Elle permet de combiner les avantages des deux types de réseaux précédemment décrits (modèle centralisé et modèle décentralisé). Un réseau conforme à ce modèle est composé de nœuds (pairs) et de supers-nœuds. Ce dernier possède les mêmes caractéristiques que le serveur central vu dans le modèle centralisé. Les pairs sont regroupés en «cluster» qui sont organisés autour d un super-nœud. Il existe des modules qui permettent d équilibrer le réseau et de regrouper les pairs selon des concepts (ontologies) Le but reste d optimiser au maximum le réseau (gestion de la bande passante ). Le routage des messages se fait par l intermédiaire de tables de hachages distribuées (DHT) qui sont contenues dans les supers-nœuds. Ces derniers sont chargés de relayer les requêtes lorsqu ils ne sont pas en mesure de les résoudre. De cette manière, la bande passante du réseau n est pas entièrement utilisée lors de l émission de requêtes. Ce système permet de ne pas encombrer inutilement le réseau car les composants qui ne sont pas susceptibles de répondre à la requête émise par l utilisateur ne recevront pas de message. Il existe tout de même des risques de passer à côté d une réponse contrairement aux techniques d inondations qui vont effectuer leurs recherches dans tout le réseau. Les supers-nœuds communiquent entre eux ainsi qu avec les pairs qui sont sous sa responsabilité. Ils contiennent également un certain nombre de services permettant d administrer au mieux le réseau. Par exemple, il peut exister des services de duplication de ressources qui fonctionnent de la manière suivante : les ressources d un pair qui sont les plus demandées par les utilisateurs du réseau, sont copiées dans le super-nœud auquel il est lié, afin de rester 10

11 disponible en permanence (même si le pair contenant la ressource se déconnecte du réseau). Les supers-nœuds peuvent également fournir des ressources et peuvent être utilisés pour stocker des informations sur le contexte. Ils possèdent en général une grande capacité de stockage. Cette topologie de réseau a été adoptée dans une grande partie des projets étudiés ci-après (voir partie 3 : Etat de l art). Supers-peers Peers Figure 3. Modèle pair-à-pair avec supers-nœuds 11

12 3. Etat de l art 3.1 Liste des plates-formes pair-à-pair reposant sur des schémas de données La plupart des moteurs de recherche utilisés dans les réseaux pair-à-pair analysent uniquement les noms des fichiers. Dans la majorité des cas, cette méthode s avère très insuffisante. C est le cas notamment dans le domaine du e-learning où les requêtes sont beaucoup plus complexes. Le problème le plus important dans les réseaux pair-à-pair est la localisation des ressources disponibles. Les deux modèles de réseaux les plus utilisés pour tenter d apporter une solution à ce problème sont : d une part des réseaux non structurés qui utilisent des techniques d inondation (dans ce cas, les messages sont diffusés dans tout le réseau) et d autre part des réseaux structurés, utilisant des tables de hachage distribuées (DHT) destinées à gérer le routage des requêtes. Dans le but de rendre plus efficace la recherche de ressources pédagogiques dans un réseau pair-à-pair, il a été introduit la notion de schéma de données. De plus, l utilisation de méta-langages comme XML, RDF ou OWL est indispensable pour manipuler ces schémas ainsi que les méta-données servant à la description des ressources. Voici une liste de systèmes pair-à-pair basés sur des schémas de données et possédant leurs propres langages de requête : AmbientDB Le projet AmbientDB [11 L10] a pour objectif de créer un cadre de travail pour la gestion des données distribuées dans un réseau constitué de matériels hétérogènes (ordinateurs de bureau, portables, PDA, téléphones ). Il permet de mettre en place un système de recherche d informations efficace. Il utilise des stratégies de duplications, de mises à jour et de synchronisations de manière à gérer la disponibilité des ressources. L une des principales caractéristiques de ce projet est de tenir compte du contexte dans lequel se trouve chaque pair. La notion mobilité est relativement importante. De plus, certains éléments du réseau peuvent rester déconnectés pendant de longues périodes. Tous les composants du réseau coopèrent par l intermédiaire d un schéma global qui est commun à tous. Durant l exécution d une requête les nœuds concernés ne peuvent pas quitter le réseau. Le protocole pair-à-pair utilisé par AmbientDB pour connecter les nœuds est Chord. Il a pour rôle d implémenter des tables de hachages distribuées (DHT) permettant de gérer le routage au sein du réseau. L architecture d un système AmbientDB contient trois composants essentiels : o un outil de gestion de requête, o un schéma d intégration de données XML, Les données contenues dans les nœuds sont échangées sous un même schéma global bien que chaque nœud puisse contenir des schémas différents. o des bases de données locales. Elles peuvent servir d adaptateur si les données sont externes au nœud. Le réseau est structuré en arborescence. Les pairs participant sont identifiés par leur adresse IP et sont regroupés en clusters qui peuvent se chevaucher. Ces derniers sont 12

13 composés de pairs et de supers-nœuds qui sont chargés de traiter les requêtes des autres nœuds (topologie «super-peer»). Ils sont sélectionnés dynamiquement suivant différents éléments comme la capacité de stockage (il doit pouvoir stocker les données des autres nœuds appartenant au même cluster), la bande passante du réseau Le protocole Adb/NP est chargé dynamiquement d attribuer des rôles aux pairs participant, tout en optimisant au maximum le réseau. Certains supers-nœuds peuvent être contenus dans un cluster (on peut définir une hiérarchie entre ces nœuds) et d autres peuvent être indépendants. La communication entre deux clusters se fait uniquement par l intermédiaire des supers-nœuds. Les nœuds indépendants et leurs ressources forment des «nuages» appelés supers-couches. Chaque nœud intermédiaire maintient une table qui contient des informations (statut, capacité de stockage ) sur ses voisins (parents + fils). Les feuilles de l arbre sont considérées comme des ressources pauvres contrairement aux autres nœuds car ils contiennent uniquement des données partageables. Le fonctionnement du processus de requête de base est le suivant : si le nœud qui a émis la requête n est pas un super-nœud alors il la transmet au super-nœud contenu dans son cluster. Quand ce dernier reçoit la requête, il va la diffuser dans toute la super-couche (processus d inondation du réseau). Le nœud initiateur de la requête va récupérer les réponses émises par ses supers-nœuds puis va les présenter à l utilisateur. Figure 4. Architecture du système AmbientDB [10] Chatty Web Chatty Web [14 15] est un projet développé à l école polytechnique de Lausanne (EPFL) en Suisse. Il a pour objectif de proposer une nouvelle approche pour obtenir l interopérabilité sémantique de sources de données différentes à travers des systèmes décentralisés comme des réseaux de type pair-à-pair, des sites Internet ou bien des bases de données fédérées. Le réseau tel qu il est décrit dans le projet Chatty Web est composé de pairs capables de fournir des ressources et est organisé autour d un schéma local (relationnel, XML ou RDF) qui est utilisé pour modéliser les modèles de données. Dans le réseau, il n existe pas de schéma global. Les différents composants (pairs) se doivent de faire l apprentissage des méthodes de traduction qui permettent de passer d un schéma à un autre et ce de manière à assurer l interopérabilité du système. Cet apprentissage se fait généralement manuellement. Chatty Web propose un certain nombre de méthodes pour tenter d automatiser ces actions qui 13

14 sont cruciales dans la gestion de systèmes décentralisés. Les pairs peuvent être regroupés en «cluster» pour permettre une meilleure gestion du réseau. Les communications entre pairs qui sont contenus dans le réseau se font par l intermédiaire de protocoles et suivant une architecture bien établie comme HTTP ou bien JXTA [L1]. Des méta-données servent à décrire les ressources. Elles sont couplées à des méta-modèles comme RDF, OIL, OWL ou DAML+OIL. Des langages de requêtes de type SQL ou XQuery sont utilisés pour questionner et transformer les bases de données. Ces derniers sont constitués d opérateurs algébriques et relationnels de base DBGlobe DBGlobe [4 L7] est un projet qui a pour objectif le développement d un système de gestion destiné à modéliser, indexer et rechercher des informations dans un réseau massivement distribué tel que le pair-à-pair. Il considère les pairs comme des bases de données qu il se charge de gérer. Il propose une approche orientée services. Pour cela, il utilise des méta-données qui vont permettre la description des pairs et de leurs services couplée à des méta-langages basés sur XML. Le langage Active XML (langage basé sur XML permettant de décrire des documents et d inclure des appels à des services web de manière à enrichir son contenu) est utilisé pour composer des documents et WSDL permet de détailler l utilisation des services web. Un document Active XML (AXML) est un document XML contenant un ou plusieurs appels à des services web. L un des principaux avantages qu un document Active XML est sa mise à jour automatique. En effet, l appel à des services pour compléter le document permet d obtenir des informations toujours actualisées. La balise <SC> (Service Call) est utilisée pour gérer les appels à un service. Ce dernier peut entraîner l appel d autres services. Un document Active XML peut être considéré comme une base contenant des données fixes (données XML) et des données dynamiques (obtenues par l appel des services). Par ailleurs, l appel à un service peut se faire avec envoi de paramètres qui peuvent être également des services. Cela pose certains problèmes de sécurité. En effet, des services peuvent être appelés avec comme paramètre l appel d un service «douteux». De nouveaux services peuvent être définis grâce à des requêtes XQuery. Les données récupérées par l appel à un service sont emballées dans le document XML. Un réseau tel qu il est décrit par DBGlobe adopte la topologie «super-peer». Il est composé d appareils mobiles (pairs) appelés PMO (Primary Mobile Objects) et de serveurs appelés CAS (Cell Administration Server) permettant l administration du réseau. Les PMO contiennent les données et les services. Ces derniers ont la possibilité d être dupliqué sur d autres sites s ils sont fréquemment demandés par les autres pairs du réseau. Cela permet de gérer la disponibilité des ressources. Ils ont également la possibilité d incorporer des composants capables de capturer le contexte. Chaque PMO est connecté à un CAS qui va jouer le rôle de proxy. Les CAS sont destinés à rendre possible les échanges d informations entre les PMO. Ils constituent le noyau du réseau. Ils permettent de capturer et de stocker les informations contextuelles et fournissent des services dans la recherche de pairs. Ils gardent une trace de tous les PMO qui s y sont connectés et stockent les méta-données décrivant chaque PMO à savoir le contexte et les ressources qui sont proposés. 14

15 Un module CAS contient : un service de gestion d ontologie (selon un modèle hiérarchique), Un dictionnaire (ontologie-service) est également créé pour faciliter les recherches. un service d annuaire contenant la liste de tous les services offerts par les PMO qu il gère, un service de description des services locaux, un répertoire contenant les adresses des autres CAS, un répertoire contenant la liste des PMO disponibles ainsi que leur description, un gestionnaire destiné à créer des statistiques de manière à tenter de prédire les connexions des PMO et à conserver un historique. Les informations contenues dans les méta-données concernant les PMO, les utilisateurs et leurs données sont utilisées pour former des communautés. Ces dernières peuvent être créées par un administrateur ou bien de manière dynamique par regroupement en fonction des profils et des buts des services. Chacune d entre elles est gérée par un serveur appelé CoAS (Community Administration Server). Il possède les mêmes fonctionnalités qu un CAS. Il extrait les informations pertinentes contenues dans les méta-données des CAS et assiste l utilisateur pour localiser des services. Chaque CoAS conserve des informations sur tous les PMO qui appartiennent à sa communauté ainsi que sur tous les autres groupes. La recherche d informations et de services se fait grâce à des index distribués. Des filtres (structure de donnée permettant de récapituler tous les documents et les services présents dans le voisinage) sont également utilisés pour faciliter le routage des requêtes. Figure 5. Architecture d un CAS [4] Edutella Le projet EDUTELLA [ L2] a pour objectif de gérer un système de partage de données essentiellement dans le domaine du e-learning. Il se propose de fournir un ensemble de services relatifs à la recherche de ressources pédagogiques à travers un réseau pair-à-pair. 15

16 Il s appuie sur l utilisation de méta-données pour décrire les ressources. Ces dernières sont indispensables pour effectuer une bonne gestion de ce type de réseau. Ce projet a pour but de mettre en place une infrastructure (architecture et implémentation) basée sur les standards RDF pour les réseaux pair-à-pair. La plate-forme Edutella se doit d être opérationnelle dans un environnement hétérogène bien qu elle soit focalisée sur l échange de ressources liées au e-learning. Les ressources sont donc décrites par des schémas correspondant aux normes IEEE LOM, IMS ou SCORM. Les ressources peuvent être de différentes natures : bases de données relationnelles, bases de données XML La grande quantité de méta-données utilisées pour décrire les ressources permet d améliorer la qualité et l efficacité des moteurs de recherche. Edutella utilise un cadre de travail JXTA [L1]. Ce dernier contient un ensemble de protocoles basés essentiellement sur XML et destinés à couvrir les fonctionnalités typiques d un réseau pair-à-pair. JXTA est un système développé en Java par Sun, qui permet de créer et de gérer des infrastructures de type pair-à-pair. JXTA constitue en fait la couche réseau de la plate-forme Edutella JXTA est composé de trois couches : la première contient le noyau du système (gestion des pairs, gestion des connexions entre pairs, gestion des groupes de pairs, sécurité). La deuxième comprend l ensemble des services proposés par JXTA (découverte des pairs, indexation ) et la troisième contient des applications JXTA (messagerie..). La plate-forme JXTA permet de connecter différents types de matériel : ordinateurs de bureau, serveurs, PDA, téléphones portables Les protocoles utilisés fournissent des connexions de grandes qualités, qui sont transparentes pour les utilisateurs. JXTA contient des outils de découverte des pairs. Il est chargé de gérer les connexions entre les différents pairs du réseau. Il est chargé également de l organisation des groupes de pairs. JXTA attribue à chaque pair ou groupe de pairs un identifiant unique de manière à faciliter l indexation et la recherche de pairs. Par ailleurs, il contient des outils destinés à gérer la sécurité des transactions (authentification et cryptage). Il propose également un ensemble de services gérés par le protocole SOAP qui permettent de créer des services Web. Figure 6. Architecture en couche de JXTA [1] 16

17 Edutella met en place un système centré sur des bases de données RDF et fournit des techniques pour répondre à des requêtes dans un réseau dont la topologie est appelée «superpeer». Des techniques reposant sur une représentation sous forme d hyper-cube [16] sont utilisées pour gérer le système. Cette topologie assure un meilleur passage à l échelle que les autres réseaux de diffusion. Figure 7. Topologie hyper-cube [16] Un réseau Edutella est composé de pairs et de supers-nœuds. Il existe plusieurs types de pairs : les pairs Edutella, les pairs destinés au stockage des annotations et les pairs Amos II qui contiennent des vues sur un ensemble de ressources (ces dernières peuvent être situées sur un ou plusieurs pairs appartenant ou non au même «cluster»). Les pairs Edutella peuvent jouer deux rôles : celui de fournisseur de ressources (provider) et celui de client (consumer). Chaque pair a la capacité de fournir au minimum un ensemble de données RDF. Les pairs peuvent également posséder d autres types de ressources (bases de données relationnelles, bases de données XML ) avec leur propre langage de requête (SQL, RDF, XQuery ). Pour assurer l interopérabilité du système, des adaptateurs Edutella sont utilisés pour traduire les requêtes ainsi que leur résultat dans un langage commun à tout le réseau. Les données échangées suivent également un même modèle appelé E.C.D.M. (Edutella Common Data Model). Les pairs présents dans le réseau Edutella sont regroupés en «cluster». Chaque groupe est géré par un super-nœud qui contient les schémas nécessaires à la bonne gestion des données et à l échange des ressources. Les supers-nœuds sont chargés d établir la liaison entre deux pairs du réseau n appartenant pas à un même groupe. Ils ont la responsabilité de l efficacité du service de requête et du routage des réponses. Ils communiquent entre eux ainsi qu avec les pairs qui sont sous leur responsabilité. Le routage des messages se fait par l intermédiaire d index. Les supers-nœuds Edutella utilisent des indices de routages qui sont basés sur les descriptions des fournisseurs de ressources. Ces descriptions sont stockées directement dans des tables. Ils contiennent par exemple : le type de schéma (Dublin Core, LOM, SCORM ), les noms des propriétés, le type de valeurs et enfin les données ellesmêmes. Toutes ces données sont regroupées sous forme d index qui permettent de retrouver rapidement l adresse du pair ou du super-nœud que l on recherche. Il existe plusieurs niveaux de granularité qui permettent de rechercher plus ou moins précisément un pair ou un supernœud. 17

18 Niveaux de granularité Granularité Type de schéma Propriété Propriété Type de valeur Propriété Valeur dc:sujet dc:sujet dc:langage lom:contexte Index de SN3 Dublin Core LOM SCORM dc:sujet dc:langage lom:contexte ccs:networks ccs:softwareeng "Français" "Etudiant" SN1, SN5 SN6 SN4, SN2 SN1, SN5 SN5 SN6 SN1 SN5 SN1, SN5 SN6 SN=Super-Noeud Figure 8. Exemple de table de routage d un super-nœud Lorsqu un pair modifie une de ses ressources, il doit en faire part au super-nœud sur lequel il est connecté. Le regroupement en clusters se fait suivant différents critères et ce, principalement de façon à améliorer les performances du réseau. De ce fait, le premier critère consiste à regrouper les pairs suivant leurs intérêts et les concepts qu ils véhiculent (regroupement par ontologies). Il existe également d autres caractéristiques qui sont utilisées pour effectuer ce travail. Par exemple, il est nécessaire d identifier les ressources qui sont le plus utilisées par les pairs de manière à optimiser leur position au sein du réseau. Pour cela, il faut analyser le contenu des requêtes diffusées par tous les pairs. De plus, la présence de ces supers-nœuds a pour but d éviter que les requêtes soient diffusées dans tout le réseau. Ces opérations permettent de diminuer l encombrement du réseau. Le projet Edutella utilise des services pour gérer le réseau. Voici la liste des principaux services que le projet se propose de mettre en place : un service de requêtes, Ce service est le plus important du point de vue de l utilisateur car la recherche de ressources est le point fort de ce genre de plate-forme. Il prévoit la standardisation des requêtes ainsi que la recherche des métadonnées RDF. un service de duplication, Il permet de gérer la persistance et la disponibilité des données tout en maintenant leur intégrité et leur consistance. Les données qui sont le plus fréquemment demandées sont dupliquées sur le super-nœud. Cela permet aux autres utilisateurs d avoir accès à ces ressources en permanence même si le pair qui les contient se déconnecte du réseau. Si les ressources sont modifiées, elles seront à nouveau dupliquées sur le super-nœud. un service de «mapping», Il sert de traducteur entre les différents vocabulaires de méta-données de manière à préserver l interopérabilité entre des pairs différents. un service de médiation, Il permet de créer des vues sur des méta-données provenant de différentes sources tout en gérant les conflits et les recouvrements d informations. un service d annotations. Il permet de créer des annotations et de les partager au sein d un groupe d utilisateurs. 18

19 a) Le service de requête Le système de gestion des requêtes fonctionne de la manière suivante : lorsqu un pair émet une requête, celle-ci va être récupérée par le super-nœud avec lequel il est lié. Ce dernier va ensuite la transmettre aux autres supers-nœuds situés dans un cluster susceptible de fournir une réponse s il ne parvient pas à la résoudre. Les supers-nœuds qui reçoivent une requête, la transmettent alors aux pairs qui sont sous sa responsabilité. Les requêtes sont transcrites dans un langage appelé RDF-QEL-i. Ce langage est basé sur du Datalog et sur RDF. Il possède plusieurs niveaux qui diffèrent par leur forme d expression (de la plus simple à la plus complexe). La lisibilité du langage devient également de plus en plus complexe. Par exemple, RDF-QEL-1 permet de représenter les requêtes comme des graphes RDF possédant la même structure que le graphe qui sert de réponse mais contenant en plus des annotations permettant de définir les variables et les contraintes. Exemple de requête en RDF-QEL-1 : <edu:qel1query rdf:id= Query_1 > <edu:hasvariable rdf:ressource= #X /> </edu:qel1query> <edu:variable rdf:id= X rdfs:label= X > <rdf:ressource= > </edu:variable> Traduction en Datalog : aibook(x):-type(x,aibook) RDF-QEL-2 ajoute de nouvelles fonctionnalités : plusieurs requêtes peuvent être liées entre elles par les relations OU / ET. Elles forment ainsi des arbres qui peuvent être facilement visualisés. Chaque niveau peut être défini de manière récursive en ajoutant de nouvelles propriétés. Seuls les cinq premiers niveaux sont généralement utilisés pour composer des requêtes. En effet, au-delà d un certain niveau (5 en général), les requêtes sont insolvables c est-à-dire qu il n existe pas de solutions ou bien, qu il est impossible de les résoudre dans une limite de temps. Requête Principale ET Sous requête 1 Sous requête 2 OU Figure 9. Exemple d'arbre de requête en RDF-QEL-2 19

20 Dès qu un pair reçoit une requête, il la transforme en clauses de Horn (Datalog) de manière à ce qu il puisse l interpréter et ainsi procéder à l interrogation des données contenues dans les ressources. Les requêtes peuvent être traduites en SQL, RQL, TRIPLE ou Xpath/dbXML. RDF- QEL-3 est assez proche de RQL, SQL et TRIPLE. Ces traductions sont effectuées par un adaptateur Edutella situé à l intérieur du pair. Il permet de traduire les données locales dans un langage commun au réseau Edutella appelé ECDM (Edutella Common Data Model). Il existe également des outils de médiation (Almos II) qui permettent de définir des vues sur différentes sources de données. Les méta-données RDF et RDFS sont traduites dans des données AmosQL afin d être manipulées par Almos II. AmosQL contient également un langage de requêtes permettant d interroger les différentes vues stockées dans le pair Almos II. Les résultats des requêtes sont récupérés par le gestionnaire de requête du pair, puis transformés en graphe de données RDF de manière à ce qu ils puissent être compris par les autres pairs. Le message ainsi créé va être transmis au pair émetteur de la requête et ce par l intermédiaire des supers-nœuds. La réponse pourra alors être présentée à l utilisateur par l intermédiaire d interfaces Edutella. Peer Fournisseur Edutella Super Peer RDF-QEL-i A D A P T A T E U R Clauses de Horn Datalog SQL RQL TRIPLE Xpath / dbxml Ressources Données RDF E C D M AmosQL Amos II Figure 10. Système de requête utilisé par Edutella b) Le service d annotations Le service d annotations [2] fonctionne de la manière suivante : il existe des pairs basés sur Kaon qui permettent de stocker des annotations et de les manipuler grâce à des ontologies. Ce service fournit un outil pour visualiser des documents (en général, ce sont des pages HTML) et un navigateur qui permet de manipuler des schémas RDF. Une annotation est constituée d un ensemble d instanciations de classes RDFS attaché à un document HTML. Elle contient des données détachées du contexte, des citations du 20

21 document et enfin une référence sur l objet annoté. XPointer est utilisé pour sélectionner une partie d un document. Le service d annotations utilise une plate-forme KAON contenant OntoMat ainsi qu une application spécifique aux annotations. OntoMat est un cadre de travail contenu dans Kaon. Il permet de faire appel à des services dynamiquement. L un de ces services Ont-O- Mat est un outil d annotations qui utilise l API de Kaon pour accroître ses connaissances sur les ontologies. Les données sont stockées dans l entrepôt RDF de Kaon. De plus, il existe un adaptateur Edutella (K-Edutella Wrapper) pour Kaon qui permet de traduire les requêtes RDF-QEL-i dans un langage qui peut être utilisé par Kaon. De ce fait, les pairs du réseau Edutella peuvent questionner les bases de connaissances contenues dans Kaon et donc émettre des requêtes sur les annotations. Figure 11. Architecture d'un pair destiné à gérer les annotations [2] c) Implémentations du projet Edutella Le projet Edutella fournit cinq applications que l on peut télécharger sur le site du projet [L2]: Generic Swing Consumer Cette application permet de charger et d éditer des requêtes basées sur RDF-QEL-3 ou Datalog. Les résultats de la requête sont affichés dans le format de RDF/XML. Si aucun fournisseur n est sélectionné, alors la question sera distribuée à tous ceux qui sont présents sur le réseau Edutella. Liste des fournisseurs Edutella Requête exprimée en Datalog ou en RDF-QEL-i Résultats de la requête Figure 12. Interface Swing Consumer 21

22 SWEBOK Consumer Cette application constitue une interface simple pour la recherche des ressources à travers le réseau Edutella. Ce programme type permet de mettre en avant les diverses possibilités de recherches suivant le vocabulaire employé. Les requêtes sont constituées par un ensemble de contraintes que l utilisateur peut sélectionner. Les ressources disponibles correspondant à la requête sont affichées dans le composant résultat. Une description est fournie pour chaque ressource trouvée. L utilisateur peut alors cliquer sur un élément pour faire apparaître la ressource correspondante (un clic sur un résultat montrera la ressource choisie dans le navigateur de l utilisateur).. Liste des fournisseurs Edutella Requête : Liste de contraintes Résultats de la requête Figure 13. Interface Swebok Consumer File Based Provider Cette application permet de créer des fournisseurs Edutella. Elle prend en paramètre un fichier RDF/XML. Edutella Rendezvous Rendez-vous est une application qui permet de générer des pairs Edutella. Elle contient toutes les informations nécessaires à la gestion des connexions entre des pairs différents. Elle permet de tester les applications développées dans le cadre du projet Edutella sans être connecté à l'internet. Dublin Core Consumer Dublin Core est une interface simple qui met en place un système de recherche de ressources basé sur des méta-données. Ce programme type démontre comment rechercher des ressources dans le réseau Edutella utilisant des schémas de Dublin Core. Les recherches peuvent se faire par le titre, l'auteur ou le sujet. Le composant contenant les résultats fonctionnent de la même manière que dans l application SWEBOK Consumer. 22

23 Liste des fournisseurs Edutella Informations sur les ressources recherchées Résultats de la requête Figure 14. Interface Dublin Core Consumer Gaia Le projet Gaia [12] a pour objectif de développer une plate-forme performante pour les services web. Elle possède une véritable architecture pair-à-pair orientée services. Elle propose un certain nombre d outils destinés à la gestion du réseau comme la découverte des pairs, le clustering, la gestion des requêtes Le système Gaia est implémenté comme une collection de services web dont le but est de gérer le réseau pair-à-pair. Ces derniers sont décrits à l aide du langage WSDL et sont associés à des méta-données qui sont utilisées pour la localisation. De ce fait, chaque nœud contient des bases de données XML permettant aux autres de connaître les services qui sont disponibles. Il existe un contrôleur (service proposé par Gaia) qui est chargé de générer une signature unique permettant de désigner l interface d un service. La détection des nœuds qui forment le réseau est automatique. Les nœuds sont alors regroupés en clusters. Gaia contient également un service d authentification qui permet aux pairs de se connecter ainsi qu un service de recherche Hyperion L'objectif du projet Hyperion [6 L6] est d'étudier les problèmes qui peuvent apparaître lors de la gestion de données dans un réseau pair-à-pair et de proposer une architecture qui permettrait d administrer un tel système. Les principales tâches qu il se doit d accomplir sont la gestion des requêtes, des mises à jour et du partage des données. Les principaux axes de recherche de ce projet sont : - fournir des définitions précises des architectures de systèmes p2p dans la gestion de données, - étudier les mécanismes d'intégration, d échange et de configuration de données au sein du réseau, - développer des algorithmes de recherches d informations efficaces - gérer les protocoles de récupération et d échange de données dans le réseau. 23

24 La topologie du réseau forme un modèle dynamique de communication nœud à nœud. Chaque pair est autonome et peut se connecter et se déconnecter à n importe quel moment. L architecture du système de gestion est structurée en couches. Chacune d entre elles est chargée de décrire une fonctionnalité du système. Les trois principaux éléments qui la composent sont : o une interface (P2P API), Elle est destinée à recevoir les questions de l utilisateur et à déterminer si les données locales sont suffisantes pour y répondre ou s il est nécessaire de la transmettre à tout le réseau. o une couche p2p, Cette couche contient trois composants : un gestionnaire de connaissances (AM), Il contient tous les outils nécessaires à la connexion entre deux pairs à la création et la gestion de tables de «mapping» et d expressions. un gestionnaire de requête (QM), Il est chargé de reformuler les requêtes afin qu elles soient comprises par le schéma local. Il utilise pour cela les données contenues dans les différentes tables de «mapping» et d expression. un gestionnaire de règle (RM). Il est chargé de faire respecter la cohérence des données entre les pairs. o un système gestion de bases de données. Il contient les données locales, une table de «mapping» ainsi qu une table d expressions. Ces dernières sont utilisées pour la gestion des échanges avec les autres pairs. Chaque pair possède ses propres vues sur les données qui sont partagées. Le schéma GLAV (Global-and-local-as-view) est utilisé pour intégrer et échanger des données. Le partage se fait au travers de domaines et à l aide des tables de «mapping». Le processus de recherche de ressources est basé sur l adaptation et la réécriture des requêtes et repose sur des tables formées à l aide de méta-données. De cette manière, les schémas utilisés pour décrire les données peuvent être hétérogènes. Figure 15. Architecture Hyperion [6] 24