CHAPITRE 1 : INTRODUCTION
1 Introduction
Les flux RSS basés sur les concepts XML du W3C
constituent une nouvelle approche pour la publication d'informations. Du point
de vue utilisateur, la consommation de ces données pose de nouveaux
problèmes. En effet, l'utilisateur ne peut ou ne souhaite lire en temps
réel l'ensemble des données provenant de ces flux. Un utilisateur
peut être rapidement submergé par les données provenant de
nombreux flux. Il doit pouvoir se faire aider par des outils qui lui
synthétisent une information en tenant compte de la dimension
temporelle. Un exemple de requête sur les flux est : «Quels sont les
articles sur les jeux olympiques de pékin durant les trois derniers
jours ?». Pour cela, il est nécessaire de conserver les flux sur
une période de temps [1]. En outre, les requêtes sont fortement
répétitives. A chaque nouvel item produit sur un flux RSS, il est
nécessaire de recalculer les requêtes définies pour un
utilisateur.
Un réseau P2P est utilisé pour les raisons
suivantes :
- Répartition de la charge de traitement (si beaucoup
de pairs veulent exécuter les mêmes requêtes)
- Fiabilité: ne plus dépendre d'un seul
serveur.
- Collaboration : mise en commun de ressources (ex.
Requête)
L'objectif du stage est d'étudier l'exécution de
quelques requêtes XQuery temporelles bien définies sur plusieurs
caches temporels distribués sur plusieurs machines. Un cache temporel
permet d'aspirer un flux et de les conserver suivant une fenêtre
temporelle. La conservation de ces données permet de faire des
requêtes historiques, des requêtes d'agrégats (combien
d'article parle des médaillées d'Or en natation).
Chaque cache peut également stocker les flux RSS
provenant de plusieurs producteurs. Chaque cache est capable d'exécuter
des requêtes XQuery (contient le SGBD eXist). L'utilisation de XQuery est
justifiée par sa puissance et sa simplicité comme langage
d'interrogation. Pour qu'il y ait une interopérabilité entre les
différents caches répartis sur le réseau P2P, Chaque cache
stocke également les clés permettant à d'autres
utilisateurs d'atteindre les enregistrements pertinents qu'ils recherchent. Ces
clés sont similaires aux clés des index traditionnelles (ex.
BTree). Les clés indiquent où sont stockés les
enregistrements.
Les clés sont calculées par une méthode
d'indexation Pair-à-Pair (PàP) (c'est une sorte d'index
distribué).
Pour l'exécution d'une requête XQuery temporelle,
l'idée est d'utiliser l'index pour isoler les sites contenant les
données pertinentes, et d'envoyer aux sites pertinents la requête
XQuery. Vu la forte répétition des requêtes XQuery
(à chaque arrivé d'un item dans un flux RSS, il faut recalculer
le résultat), et pour éviter que tous les pairs exécutent
la même requête (de nombreux utilisateurs peuvent
s'intéresser aux mêmes sujets), l'idée est de mutualiser
ces requêtes sur le réseau P2P. La mutualisation permets un
meilleur équilibrage des charges et d'utiliser les ressources sur un
réseau de manière plus optimum.
Ce rapport s'articulera donc autour de trois axes :
Tout d'abord, nous présenterons le contexte du stage,
le sujet proposé ainsi que les problématiques posées,
Ensuite, un état de l'art de quelques travaux qui nous ont
inspiré dans la réalisation de ce stage sera décrit.
Enfin, le reste du rapport portera sur l'ensemble du travail
effectué : les choix effectués, les résultats obtenus,
leurs analyses et les perspectives envisageables.
1.1 Le contexte du stage
Le stage s'inscrit dans le cadre d'un projet ANR appelé
ROSES.
Comme base de travail, j'ai utilisé une mini plateforme
en pair à pair pour l'interrogation en historique des flux RSS,
réalisée par les étudiants d'ISTY3 dans le cadre de leur
projet annuel de troisième année. Pour ceci cette mini plateforme
stocke de données RSS suivant le temps, pour pouvoir les interroger
après [1].
Cependant, la réalisation du mini prototype
n'intègre pas les fonctionnalités de mutualisation de
requêtes sur le réseau distribué. Ceci est l'objet du
présent stage.
L'architecture générale de cette plateforme est un
réseau pair à pair avec réseau P2P au centre. Ce
réseau est semi réparti. Il sera par la suite totalement
réparti sur les pairs. La représentation des composants
ci-dessous décrit le mini prototype 
Figure 1 : Architecture du mini prototype
Selon la figure ci-dessous, les composants du réseau
sont:
Ø les pairs : contiennent la base de
données eXist, et aspirent périodiquement des flux RSS.
Ø le réseau P2P (Tour Eiffel) : le contenu
des pairs (flux RSS) est publié dans le réseau, pour pouvoir les
retrouver. Chaque pair possède une portion de code donnant vie au
réseau figurant au centre. Cette portion de code assure les services
comme le routage, le stockage de clés, etc.
Ø Le portail web : il permet de commander les
pairs à distance. Il permet également de visualiser le
comportement des pairs du réseau.
1.2 Fonctionnement du prototype
Si un pair P veut exécuter une requête XQuery Q
sur une période T, P doit interroger le réseau P2P en lui
fournissant comme paramètres quels : flux, mots clés et
période T lui intéressent, le réseau P2P en retour donne
à P les adresses IP des pairs pertinents.
Une fois ceci fait, P envoie la requête Q à
chacun des pairs pertinents, et enfin le résultat serait l'union des
réponses.
1.3 Faiblesses du mini prototype
L'exécution des requêtes XQuery dans le
modèle décrit ci-dessus, engendre plusieurs
problèmes :
Ø Si toutes les réponses des pairs pertinents
sont identiques (redondance), dans ce cas on augmente inutilement la charge du
réseau, donc on risque de l'inonder.
Ø Si d'une manière ponctuelle (ex : Jeux
Olympiques), il y a N pairs (N très grand) voulant exécuter la
même requête Q, selon la logique de fonctionnement décrite
ci-dessus, les N pairs devront faire les mêmes démarches, à
savoir : interroger l'indexeur pour isoler les pairs pertinents, envoyer
la requête Q à ces mêmes pairs, réaliser l'union des
réponses reçues. Ainsi les pairs sources seront vite
saturés.
Ø De plus, pour une requête identique issue de
deux sites différents, compte tenu des temps de transmissions des
données, du temps CPU pour le calcule, il peut s'avérer plus
intéressants de calculer qu'une fois, puis de faire profiter du
résultat à d'autres.
Il y a un vrai problème de répartition de la
charge de traitement des requêtes sur l'ensemble des pairs.
1.4 L'objectif du stage
L'objectif de ce stage est la réalisation d'un
prototype pour l'exécution des requêtes XQuery sur des flux RSS
dans un réseau pair à pair tout en répartissant la charge
de traitement de ces requêtes pour que le réseau s'adapte à
la charge, en utilisant deux approches :
Ø Approche e-commerce (meilleures offres) pour
résoudre le premier problème [3] (à savoir le choix parmi
plusieurs sources possibles)
Ø Mutualisation des requêtes pour résoudre
les derniers problèmes
Ces deux approches seront décrites dans le chapitre
suivant.
| 
