CHAPITRE 3 : NOTRE PROPOSITION
3 Notre proposition : Mutualisation des
requêtes XQuery
Afin de résoudre la problématique citée
dans le chapitre 1, nous avons proposé une solution qui marie les deux
approches « Mutualisation des requêtes XQuery » et
« e-commerce » en s'inspirant fortement des deux approches
décrites dans l'état de l'art.
3.1 Principe de la mutualisation
Le principe de la mutualisation est le suivant : un pair
P calcule une requête XQuery sur un flux RSS et les autres pairs voulant
calculer la même requête s'abonnent à P et
récupèrent le résultat.
On veut factoriser au maximum les calculs dans le
réseau pair à pair.
Avant d'aborder le principe de fonctionnement de notre
proposition, voyons maintenant quelques définitions :
l Base : Ensemble de flux RSS aspirés
l Cache : Ensemble de XQueries prises en charge
(calculées).
l Vue : XQuery calculée à partir du
cache.
Comme le mentionne la figure ci-dessous, une requête
XQuery peut être exécutée directement sur une Base si elle
n'a pas été prise en charge, sinon elle peut être
exécutée sur un Cache produisant une Vue
![]()
Figure 4: Exécution d'une requête XQuery
3.2 Fonctionnement de la mutualisation
Tout pair ayant exécuté une requête, doit
publier les prédicats de cette requête avec un coût dans la
DHT. En d'autres termes, faire savoir aux autres que cette requête a
été exécutée.
Si un pair P veut exécuter une requête Q, avant
d'aller chercher les sources, il doit chercher dans la DHT, s'il y a un pair
qui a déjà pris en charge cette requête ou une
requête semblable. les requêtes semblables [2] seront
expliquées plus loin.
Ici on a 2 cas :
Ø Cas 1 : si aucun pair n'a pris en charge cette
requête alors chercher les sources, en d'autres termes,
trouver les meilleures bases pour calculer la requête Q.
Ø Cas 2 : si un pair P' a pris en charge la
requête Q (ou une sous partie) alors :
- Si le pair P' peut accepter un nouveau client (coût
intéressant proposé par P'), alors le pair P s'abonne à P'
pour mutualiser la requête Q.
- Sinon chercher les sources, en d'autres termes, trouver les
meilleures bases pour calculer la requête Q.
Notre originalité réside dans
l'intégration du coût dans la DHT, ainsi le pair P va
connaître le coût directement, sans avoir à envoyer des
messages à P' pour connaître le coût.
3.3 Requête semblables (proches)
Deux requêtes sont semblables [2] ou proches, si le
résultat de l'une est inclus dans l'autre
Exemple 1 :
Q1= For $i in document(`Equipe.xml')/rss/channel/item
Where contains($i/title, `Foot') and
contains($i/title, `PSG')
Return $i
Q2= For $i in document(`Equipe.xml')/rss/channel/item
Where contains($i/title, `Foot') and contains($i/title,
`PSG')
and contains($i/title, `2008')
Return $i
Exemple 2 :
Q1= For $i in document(`Equipe.xml')/rss/channel/item
Where contains($i/title, `Foot')
Return $i
Q2= For $i in document(`Equipe.xml')/rss/channel/item
Where contains($i/title, `Foot')
Return $i/description
Dans les deux exemples ci-dessus, le résultat de Q2 est
bien inclus dans le résultat de Q1, donc pour factoriser les calculs au
maximum afin de réduire la charge des pairs, si le pair P1 a pris en
charge la requête Q1, et s'il y a un pair P2 qui veut exécuter Q2,
il suffit que P2 s'abonne à P1, et que ce dernier exécute Q2 sur
le résultat de Q1.
| 
