Lri, projet gemo

Ioana Manolescu
INRIA Futurs - LRI, projet Gemo
n
n
n
Contexte: bases de donnees XML
Traitement de requêtes sur des bases de
donnees XML (quelques notions...)
Quelques applications:
q
q
q
n
Active XML (modèle de base)
Optimisation de calculs distribues ActiveXML
Gestion de masses de donnees XML en P2P
Conclusion
n
n
n
n
Grands volumes de donnees
Stockage persistent, résistant aux pannes, assurant
l'integrite et la cohérence des donnees
Accès en lecture et écriture
Access aux donnees = requête
q
q
q
Requêtes exprimées dans un langage déclaratif
Requêtes compilées dans des programmes d'acces aux
donnees (plan d'execution)
Compilation = optimisation de requêtes
n
Examiner l'espace des plans d'execution pour
une requête donnees (souvent un sous-espace)
n
Estimer les performances de chaque plan
d'execution: estimation de coût
n
Choisir le plan le moins coûteux
SGBD
Utilisateur
Catalogue de
donnees
Analyseur
Statistiques
sur les donnees
Optimiseur
Plan d'exécution
Execution
Données
Modèle de coût
Stratégies de recherche
n
"Think big"
q
q
q
q
n
L'optimisation de requêtes n'est pas de l'optimisation du
code
q
q
n
Grands volumes de donnees
Grand nombre de sources de donnees
Grande complexité / heterogeneite de donnees
Traitement complexes,
"Code" (lg. de requêtes) très spécialise
L'optimisation tient compte des donnees
Centre d'interet un peu différent de "global computing /
middleware":
q
manipulations efficaces de grands volumes de donnees
n
Exploiter (interroger, mettre à jour) des données
réparties sur plusieurs sites
S3
S1
S4
n
Exploiter (interroger, mettre à jour) des données
réparties sur plusieurs sites
S2
S3
S1
S5
S4
n
Connaissances nécessaires pour l'interrogation de
données distribuées :
S2
S3
S1
¢
Catalogue
(quelles données ?)
¢
Localisation
(où sont les données ?)
¢
Capacités de calcul
(qui peut contribuer à
traiter la requête ?)
Coûts d'exécution
(quelles performances ?)
Décision sur l'exécution
(qui traite la requête ?
comment ?)
¢
S5
S4
¢
1.
Hétérogénéité des données
(1a) Modèle, nature, schéma
2.
Hétérogénéité des sites
(2a) Capacités de traitement de requêtes
3.
Partage de l'information sur :
(3a) Les données qui se trouvent dans le système, et
leur localisation (configuration de données)
(3b) Les capacités de calcul de chaque site, et les
coûts associés
4.
Prise de décisions sur :
(4a) La distribution du travail entre les sites
(4b) L'exécution d'un fragment de travail alloué à un site
(4c) Les changements de configuration (réplication, distribution)
! "#
n
n
(1), (2) : sites et données homogènes
(3a) Catalogue et configuration :
q
q
Chaque site connaît sa configuration locale
Pour utiliser sur S1 des données de S2, il faut établir
(manuellement) un lien de données
n
n
n
La configuration de S1 est élargie par l'"importation" des
données
Partage de l'information ponctuel, unidirectionnel
(3b) Capacités de calcul identiques ; coûts ??
q
Optimisation dans Oracle 8 à base de coût ou de règles ;
usage de hash join une heuristique …
! "#
n
(4) Prise de décision sur :
(4a) Distribution du travail pour l'exécution d'une
requête : le serveur qui la reçoit
(4b) Exécution d'un fragment de travail alloué : le
serveur auquel elle est déléguée (SQL)
(4c) Changements de configuration : l'administrateur
du SGBD (manuel)
! "
Utilisateur
Site S1
Catalogue local +
liens
Statistiques
locales
Site S2
Optimiseur
Analyseur
Optimiseur
Plan d'exécution
distribué
Execution
Données
Négociation
de la
distribution
du
travail
Execution
Données
Site S3
Optimiseur
Execution
Données
! "
SQL
Utilisateur
Site S1
Catalogue local +
liens
Site S2
Optimiseur
Analyseur
Execution
Statistiques
locales
Optimiseur
Plan d'exécution
distribué
SQL
Données
Site S3
Execution
Optimiseur
Données
Execution
Données
$
#
n
n
(1) Données hétérogènes
q SGBD : R, R-O, XML, …
q Fichiers : SGML, tabulaire, texte…
q LDAP ; mail ; Excel ; …
(2) Sites hétérogènes
q
q
Certains possèdent uniquement des données et des
adaptateurs pour les données
n Capacités de traitement de requêtes souvent limitées
D'autres sites possèdent des médiateurs
% !& !
'
$
Adaptateur A1 (source web)
Médiator
Utilisateur
Execution
Analyseur
Optimiseur
Plan d'exécution
distribué
Adaptateur A2 (fichiers)
Execution
Execution
Adaptateur A3 (programme)
Données
Execution
% !& !
)
#
n
(
Adaptateur A1
Ex. LeSelect
Médiateur M1
Adaptateur A3
Médiateur M3
Adaptateur A4
SGBD
Médiateur M2
Adaptateur A2
% !& ! &
)
#
n
!&
(
Ex. Disco, Tsimmis
Médiateur M1
Médiateur M3
Adaptateur A4
SGBD
Médiateur M2
Adaptateur A2
Adaptateur A3
Adaptateur A1
*
'
! '
+#
n
Chaque médiateur détient le catalogue des données des
adaptateurs reliés
q
n
Un seul médiateur, catalogue global
q
n
Disco, Tsimmis, Garlic, LeSelect
Information Manifold
Plusieurs médiateurs, service de catalogue distribué et
de localisation
q
Mariposa, ObjectGlobe
*
!
,
n
Les médiateurs ont souvent des capacités de traitement
plus riches que celles des adaptateurs
q
n
Surtout si adaptateurs au-dessus de sources de type fichier
(pas d'operations complexes)
En règle générale, un médiateur connait les capacités de
traitement de ses adaptateurs
q
q
n
+#
D'avance (Tsimmis, Disco)
En demandant lors de chaque exécution (Garlic, LeSelect)
Un médiateur peut ne pas vouloir traiter une requête
q
Si on ne lui paie pas assez (Mariposa, modèle économique)
-
!.
+#
n
Souvent, à capacités de traitement égales, on prefère
déleguer le travail aux adaptateurs
q
q
n
Il est très difficile de caractériser les coûts associés aux
adaptateurs
q
n
On considère qu'un adaptateur "en sait plus"
Réduction des coûts de transfert
Solutions les plus avancées : Disco, Garlic
En général, un médiateur connaît les coûts
q
q
De ses adaptateurs, d'avance
Des médiateurs et adaptateurs impliqués dans l'exécution
d'une requête, lors de l'exécution
!
$ !
/#
n
Le médiateur ayant reçu la requête décide de la répartition du
travail
q En choisissant celle qui minimise sa fonction de coût
q Apres avoir négocié avec les autres médiateurs et
adaptateurs
n
n
n
n
Les paramètres de la fonction de coût
La rémunération (Mariposa)
Certains participants choisissent comment exécuter leur
travail: LeSelect, Disco
Certains participants s'engagent, lors de l'optimisation, à une
exécution précise : Garlic
!
n
! '
/#
Réplication généralement ignorée
q
n
!&
,
Ne peut être prise en compte sans un service de catalogue
global
Exception remarquable : Mariposa
q
q
q
Exécuter une requête rapporte de l'"argent" au médiateur
Pour améliorer ses gains, un médiateur décide d'acheter des
données à un autre (copie locale), afin de répondre à des
requêtes sur ces données
Mécanisme auto-reglé de migration de données là où elles
sont nécessaires
( (
n
Systèmes structurés
q
q
n
Organisés dans une structure de données distribuées et
symétrique (p.ex. distributed hash table)
Certaines primitives de recherche de données
Systèmes non-structurés
q
q
q
q
Absence de catalogue global (données, peers)
Notion de voisinage ("ceux que je connais"), indirection
style IP
Réseau de "connaissances" adaptatif, auto-configurable
Réplication dynamique de données
0
( (
(
n
!
1ere étape : propagation de la question (time-to-live)
q
Identification des peers susceptibles de répondre
P5
P6
P2
P3
P1
P8
P7
P4
P9
P10
0
( (
!
n
2e étape : choix des sites à interroger, collection des
résultats
P5
P2,
P3, P3,
P9
P8, P9
P6
P2
P3
P1
P8
P7
P4
P9
P10
1
$
( (
n
(3a) Modèle de données: fichiers, relationnel, XML
arrive...
q
n
Uniforme pour le moment.
(2a,3b) Traitement de requêtes encore assez réduit
q
q
Dépend beaucoup de la structure du système
Nous allons voir des applications
!
( (
n
(4a) Distribution du travail : celui qui reçoit la requête
q
Connaissances acquises pour décider : limitées au voisinage
n
(4a) Manière d'exécuter un travail précis : chaque site
n
(4b) Changements de configuration :
q
q
Automatiques (cache des données utiles)
n Requêtes ignorent toujours la localisation de la réponse, donc le
cache local est toujours identifié
Manuel
2-3
<item>Une introduction aux
<title>Legendes du Graal</titre> par
<auteur>P.Boulenger</auteur> aux editions
<editeur>Dunod</editeur> pour juste 5.55 Euros !
<click>…</click>
</item>
item
#CDATA
titre
auteur
#CDATA
editeur
#CDATA
click
!
!4
!
n
Hétérogénéité
q
n
2-3
5#
XML permet: des éléments optionnels (?), des répétitions (+, *),
des choix (|)
Identité
q
Deux élements à contenu identique sont différents
a
c
b
b
a/b/c[1] <> a/b/c[2]
c
d c c c d
a/b[count(c)>2]//c
1 2 3
1 2 3
En comparaison, dans une table relationelle, impossible de discerner
entre deux tuples à contenu identiques
!
!
n
!4
2-3
6#
Presence de "mixed content"
q
q
"Données dans les élements"
"Données en dehors des élements"
<item>Une introduction aux
<title>Legendes du Graal</titre> par
<auteur>P.Boulenger</auteur> aux editions
<editeur>Dunod</editeur> pour juste 5.55 Euros !
<click>…</click>
</item>
item
#CDATA
titre
auteur
#CDATA
editeur
#CDATA
click
!
!4
!
n
2-3
+#
Ordre des éléments
<item>Une introduction aux <title>Legendes du Graal</titre> par
<auteur>P.Boulenger</auteur> aux editions <editeur>Dunod</editeur> pour juste 5.55
Euros ! <click>…</click> </item>
item
#CDATA
titre
auteur
#CDATA
editeur
#CDATA
click
<item><auteur>P.Boulenger</auteur><click>…</click><editeur>Dunod</editeur>
<titre>Legendes du Graal</titre>par pour juste 5.55 Euros ! Une introduction aux</item>
item
auteur
click
editeur
titre
#CDATA
#CDATA
#CDATA
!
!4
!
n
2-3
/#
Importance de la structure
q
q
Codée implicitement
Souvent l'interrogation navigue la structure
departement
personne
"Dupont"
adresse
rue
no
personne
responsable
ville
"Dupont"
adresse
rue
no
2 Paris
Lafayette
employe
ville
35 Paris
Bd Opera
!
!4
!
n
2-3
7#
Presence d'un schéma
q
S'il existe, il peut être utilisé pour systématiser le stockage
département
personne
personne
"Dupont"
adresse
rue
no
responsable
ville
"Dupont"
adresse
rue
no
2 Paris
Lafayette
employe
ville
35 Paris
Bd Opera
0
2
n
n
n
n
n
n
n
!
2-3
&
Langage de chemin dans le document
/département
/département/personne/@nom
/département/personne[/@nom="Dupont"]/adresse
//personne[/@nom="Dupont"]
/ancestor-or-self::*
departement
nom:
//personne
personne
personne
"Dupont"
Fonction:
[/@nom="Dupont"]
adresse responsable
adresse
/previous-sibling::*
ville
rue no
rue no
//personne//ville/text()
2 Paris
Lafayette
nom:
"Dupont"
Fonction:
employe
ville
35 Paris
Bd Opera
!
n
$
2
Partition du document selon les axes Xpath
ancestor
preceding-sibling
self
following-sibling
descendent
n
n
Conditions existentielles
//département[person/address/ville="Paris"]//person;
Quelques fonctions d'aggrégation
q
Min, max, count
&
3
n
n
n
2
&
Impossible d'exprimer une corrélation entre des données
situées sur des chemins différents
q Pas de jointure
Ne peut retourner que "des noeuds éxistants"
q Pas de re-formulation, combinaison de plusieurs
documents
"Langage d'adressage" non pas "langage de requêtes"
q Requête: selection, correlation, reconstruction
1
n
28
for $x in document("d.xml")//personne
where $x/@fonction/text()="employe"
return $x/@name;
departement
nom:
"Dupont"
nom:
personne
personne
"Dupont"
Fonction:
Fonction:
adresse responsable
adresse employe
ville
rue no
rue no
ville
2 Paris
Lafayette
35 Paris
Bd Opera
1
n
28
<tousLesDuponts>
for $x in document("d.xml")//employe
where $x/@name/text()="Dupont"
return <fonction> $x/@fonction/text()
</fonction>
</tousLesDuponts>
departement
nom:
"Dupont"
nom:
personne
personne
"Dupont"
Fonction:
Fonction:
adresse responsable
adresse employe
ville
rue no
rue no
ville
2 Paris
Lafayette
35 Paris
Bd Opera
1
n
28
for $x in document("d.xml")//personne,
$y in document("d.xml")//personne
where $x/@name/text()=$y/@name/text()
and $x/@fonction/text()!= $y/@fonction/text()
return $x, $y;
departement
nom:
"Dupont"
nom:
personne
personne
"Dupont"
Fonction:
Fonction:
adresse responsable
adresse employe
ville
rue no
rue no
ville
2 Paris
Lafayette
35 Paris
Bd Opera
!
$
28
n
n
n
XPath
Jointures
Re-structurations arbitraires
q
n
n
n
Possibilité d'ignorer l'ordre des données en entrée (motcle UNORDERED)
Typage, sémantique formelle
Extensibilité : fonctions XQuery
q
n
construction de "nouveau XML"
Y compris fonctions recursives...
Très puissant, mais plus optimisable que XSL-T
2-3
28
Systemes a stockage persistent
Stockage natif
Stockage non-natif
Systemes sans stockage
Streaming
Compilation de code
2-3
28
n
Stockage natif (construit) pour XML
q
n
Stockage non
- n
atif (basé sur le relationnel)
q
n
IBM, Oracle, MS, LegoDB, Rainbow, XQuark ...
Systemes "streaming"
q
n
Natix, Xyleme, Timber, OrientX, Sedna, Jungle, GeX,...
Enosys, BEA
Systemes "compilation de code"
q
Galax, Kawa, XDuce, CDuce, QizX,...
!4
(
'
Document XML
Chargement dans le SGBDR
Recomposition du document
SGBDR (ou R-O)
• Persistence
• Indexation
• Fiabilité
• Transactions
Traitement de requêtes
• Traduction de XQuery
vers SQL
• Exécution de la requête
SQL
• Construction du résultat
XML
!4
n
'
Intérêt:
q
n
(
Re
- utiliser l'existant (un SGBD est coûteux,
difficile à construire, installer, configurer)
Problemes à resoudre:
q
Choix du schéma relationnel de stockage
n
q
q
q
Les documents peuvent avoir un schéma XML
Chargement automatique de documents XML
Traduction des requêtes XML en requêtes SQL
Construction du résultat XML
!4
n
Objectifs
q
q
q
n
'
Regrouppement des objets fréquemment accédés
simultanément (localité de l'acces)
Primitives d'acces efficace (e.g. //person)
Primitives d'évaluation efficace (e.g.
//person//name)
Techniques
q
q
Etiquetage des noeuds crucial
Usage de structures d'indéxation génériques de
niveau plus bas (B
- trees, R
- trees...)
2-3 !
,
'
n
Bonne diffusion des connaissances sur le standard
XQuery
q
q
n
n
La spec est touffue, trop longue
Ce n'est pas une excuse
Langage: mises à jour, interrogation textuelle
Mise en oeuvre (natif):
q
q
q
algèbre standardisée (ou début de consensus...)
modèle d'exécution
techniques générales et validées d'optimisation
000
9
9 2-3:
;
n
)
:
XML s'adapte bien a tous les scénarios distribuées
examinés
q
Bases de données XML distribuées =
Bases de données XML
Bases de données XML
distribuées ?
distribuées ?
%)
n
HTML- - >XML, Word- - >XML: volume !
q
n
2-3
Rapports annuels INRIA en XML !
Nombreux standards facilitent l'interopérabilité entre
plusieurs sites
q
q
q
q
XPath, XQuery, XSL
Dialectes XML spécifiques à des applications
Services Web: APIs de communication basées sur XML
n Standards: SOAP pour l'acheminement de messages
WSDL pour les signatures XML
BPEL4WS pour l'orchestration ...
Une application: ActiveXML
<
2-3
n
n
n
!
%! ) 2-3
Projet développé a l'INRIA Futurs, projet Gemo
09/2001 -- présent
Equipe:
Serge Abiteboul
Bernd Amann
Jérome Baumgarten
Omar Benjelloun
Angela Bonifati
Bogdan C uti
Grégory Cobéna
Cosmin Cremarenco
Frédéric DangNgoc
Florin Dr gan
Ioana Manolescu
Tova Milo
Benjamin Nguyen
Antonella Poggi
Nicoleta Preda
Gabriela Ruberg
Nicolaas Ruberg
....
!
n
Active XML : XML contenant des appels à des
services Web
q
q
n
%2-3
Paramètres : XML
Résultats : XML, insérés dans le document lorsque l'appel
de service retourne
Documents XML/HTML contenant des appels à des
composantes actives / services :
q
q
q
Tous les langages de script dans HTML
Macromedia MX (DreamWeaver)
.NET etc.
2-3 ) !
)!
<directory>
<dept name="Toy“>
<sc>toy.xyz.com/GetToyPersonel()</sc>
</dept>
<dept name=“DVD“>
Appels de services
<sc>dvd2000.com/GetDVDPersonnel()</sc>
</dept>
</directory>
Appels vers n'importe quel service enveloppé
en SOAP :
• e-bay.net, google.com, amazon.com, etc.
• services AXML (requêtes XML)
=
$)
!
$
%2-3
)!
<directory>
<dept name="Toy“>
tat <person pname=“Smith”>
Résul
<phone>01…</phone>
<pda>
<sc>toy.xyz.com/GetPDA(../../@pname)</sc>
Ap
pe
</pda>
l
</person>
<sc>toy.xyz.com/GetToyPersonel()</sc>
</dept>
<dept name=“DVD“>
<sc>dvd2000.com/GetDVDPersonnel()</sc>
</dept>
</directory>
1
28
n
!
>2
%2-3
&
Services AXML : définis comme des requêtes XQuery sur les
documents AXML
let service Get-Toy-Personnel( ) be
for $a in
document("toy.xyz.com/members.axml")/member,
$b in $a//name,
$c in $a//phone,
$d in $a//pda
return
<person pname={ $b/text() }> { $c } { $d } </person>
% !& !
%! ) 2-3
AXML
AXML
XML
AXML
) !%! ) 2-3
1.
Distribution et replication de documents
AXML
2.
Indexation XML en P2P: couplage de AXML
avec un reseau DHT
3.
Optimisation de calculs AXML intensionnels
0005 1
!
!
%! ) 2-3
1
!
!
n
n
n
Problème de gestion de données distribuées
Contexte : architecture peer- to
- peer
Motivation : gestion efficace et flexible pour
q
q
n
%! ) 2-3
Données (A)XML
Services portables (pouvant être installés ailleurs que
dans leurs peer d'origine): Java, XQuery
Solution :
1.
2.
3.
Langage déclaratif pour réplication (distribution)
Traitement de requêtes XML
Réplication dynamique
!
!
2-3
allCNN
weather sports
forecast
archive
weather
…
…
Asia
…
forecast
archive
world
US
Europe
Africa
n
…
…
Europe
…
France
…
!
!
2-3
allCNN
weather sports
forecast
archive
weather
…
…
Asia
…
forecast
archive
world
US
Europe
Africa
n
…
…
Europe
…
France
…
!
2-3
n
Directive de réplication :
q
q
Une requête XQuery sur doc chez pi
Le résultat de la requête est copié chez pj
n
n
Conservant l'identité des noeuds copiés ou non
Conservant les liens fils-père et père-fils ou non
Europe
…
Europe
devient
France
…
…
id1
France
id1
France
…
…
!
2-3
n
Directive de réplication :
q
q
Une requête XQuery sur doc chez pi
Le résultat de la requête est copié chez pj
n
n
Conservant l'identité des noeuds copiés ou non
Conservant les liens fils-père et père-fils ou non
Europe
…
Europe
devient
France
…
…
id1
France
id1
France
…
…
!
2-3
n
Directive de réplication :
q
q
Une requête XQuery sur doc chez pi
Le résultat de la requête est copié chez pj
n
n
n
Conservant l'identité des noeuds copiés ou non
Conservant les liens fils-père et père-fils ou non
Si pi décide d'effacer lés données => distribution
Europe
…
Europe
devient
France
…
…
France
…
1
!
n
¢
¢
>
Chaque peer garde les liens sortants dans un
résumé des points de sortie
Il existe une copie "master" de chaque document
l Et elle est connectée
Conceptuellement : La fusion basée sur des identifiants
de tous les fragments d'un document donne le document
même
Europe
Europe
…
Europe
France
fusion =>
id1
France
id1
France
…
…
…
id1
France
…
0
)!
n
!
2-3
!
La requête peut spécifier la localisation des
données interrogées (~version)
q
q
{Doc("cnn.com")/world/Europe/France}@p1
{/Economie}@p2
Plusieurs variantes possibles
n
n
n
q
@local
@localORAny
@masterORlocalORAny
Si au moins une ambiguïté est possible, il faut choisir la
version à utiliser
8
n
)
:
Requête sur pi :
{Doc("cnn.com/root.xml")/world/Europe/France}@any
cnn
¢
world
Europe
…
¢
id1
France
…
id1
France
…
Le traitement ne peut commencer que :
¢ D'une racine ("cnn.com/root.XML")
¢ D'un noeud de pi
¢
¢
Le reste n'est pas connu / pas accessible
de pi
L'évaluation traverse plusieurs peers
Chaque peer :
¢ Détermine ce qu'il peut traiter de la
requête (utilisant les points de sortie)
¢ Choisit le peer suivant
*&
)
Analyse "what-if" récursive initiée chez pi
n
¢
cnn
world
Europe
…
id1
France
…
id1
France
…
¢
Ensemble de peers candidats
¢ Chaque candidat pourrait à son tour
déleguer une partie du travail à un autre
¢ Pi ne connait pas ce choix (ne "voit" pas
plus loin que le peer suivant).
Pi demande un "devis" à chaque peer
candidat
¢ Un devis = un plan d'exécution réparti
¢ Identification des peers qui exécuteront
chaque pas
-
!.
!&
)
n
cnn
Paramètres objectifs pour chaque requête x peer : CPU,
I/O, réseau, batterie, …
¢
world
Europe
¢
…
id1
France
…
id1
France
…
¢
Chaque peer => ensemble de poids subjectifs
pour chaque paramètre de coût
¢ P.ex.: "en dehors de .inria.fr, coût 0"
Chaque peer demande aux candidats les
coûts objectifs…
¢ Et choisit le devis minimisant
son coût subjectif (ou réfuse de coopérer)
¢ Ceci peut arriver à plusieurs niveaux
Résultat = meilleur consensus négociable
parmi les peers accessibles à pi
*&
n
Aucune analyse des coûts
q
q
q
n
) >)
Heuristiques (locales !)
De manière non-deterministe
Choix sous-optimaux
Limiter l'ensemble de candidats
q
Au plus n à chaque pas
!
1.
!
$
!
Analyse des coûts
P5
P6
P2
P1
P8
P7
P4
P9
P10
P3
!
1.
!
$
!
Analyse des coûts
P5
P6
P2
P1
P9,P10
P8,P3
P8
P7
P4
P9
P10
P3
P3
!
1.
!
$
!
Analyse des coûts
P2
P7,P9,P10
P6,P8,P3
P5
P6
P1
P8,P3
P8
P7
P4
P9
P10
P3
P3
!
1.
!
$
!
Analyse des coûts
P5,P6,P8,P3
P5
P6
P2
P1
P8
P7
P4
P9
P10
P3
!
2.
!
$
!
Exécution
P5,P6,P8,P3
P5
P6
P2
P1
P8
P7
P4
P9
P10
P3
1
n
!
!
%2-3
Que faire si le fragment XML à repliquer contient un
appel de service ?
q
Ne pas le prendre (l'ignorer)
Europe
…
Europe
devient
France
…
météo.fr/getForecast()
…
id1
France
id1
France
…
…
météo.fr/getForecast()
1
n
!
!
%2-3
Que faire si le fragment XML à repliquer contient un
appel de service ?
q
Mettre un lien vers le résultat sur le peer d'origine
Europe
…
Europe
devient
France
…
météo.fr/getForecast()
…
id1
France
id1
France
…
…
météo.fr/getForecast()
1
n
!
!
%2-3
Que faire si le fragment XML à repliquer contient un
appel de service ?
q
Le prendre
Europe
…
Europe
devient
France
…
météo.fr/getForecast()
…
id1
France
id1
France
…
…
météo.fr/getForecast()
1
n
!
!
%2-3
Que faire si le fragment XML à repliquer contient un
appel de service ?
q
Si service Xquery : prendre la définition de service aussi
Europe
…
Europe
devient
France
…
météo.fr/getForecast()
…
id1
France
id1
France
…
…
météo.fr/getForecast()
localGet
Forecast()
1
n
!
!
%2-3
Que faire si le fragment XML à repliquer contient un
appel de service ?
q
Si service Xquery : prendre la définition de service aussi,
et les données nécessaires
Europe
…
Europe
devient
France
…
météo.fr/getForecast()
…
id1
France
id1
France
…
…
météo.fr/getForecast()
localGet
Forecast()
1
!
!
n
n
%2-3
Chaque peer enregistre un coût global subjectif pour
les requêtes et appels de services fait sur ce peer
En prenant des copies locales de données et/ou des
services nécessaires, le peer peut améliorer le coût
global subjectif
q
n
#
Limitations : espace ; bande passante
Algorithme récursif greedy de recherche
q
q
Recommande des choix de réplication
Transparent pour l'utilisateur
0006 0
2-3
!
%2-3
?
6
%@
n
n
n
n
%2-3
Requete: "//personne"
Semantique:
q
n
!
tous les elements XML <personne>, de tous les documents, de
tous les peers.
Plus generalement, "Tree Pattern Queries"
Solution:
q Utiliser des services DHT comme des Web services
q Calculer des cles DHT a partir des documents XML
q A l'aide d'AXML, distribuer l'index sur la DHT
q Exploiter l'index pour repondre a des requêtes
Autres facettes: connaissances semantiques; langage
d'interrogation moins precis (XML-IR)
000+
!!
* !
n
Un paramètre d'un appel de service peut être un
appel de service
q
n
Matérialiser un document AXML:
q
n
altavista.com/translate(<from>Tchek</from>,
<to>Francais</to>,
crystalGlasses.cz/getCatalog())
effectuer tous les appels de services, dans le bon ordre
Plusieurs stratégies possibles
vamos.futurs.inria.fr
altavista.com
crystalGlasses.cz
* !
n
Un paramètre d'un appel de service peut être un
appel de service
q
n
Matérialiser un document AXML:
q
n
altavista.com/translate(<from>Tchek</from>,
<to>Francais</to>,
crystalGlasses.cz/getCatalog())
effectuer tous les appels de services, dans le bon ordre
Plusieurs stratégies possibles
vamos.futurs.inria.fr
altavista.com
crystalGlasses.cz
* !
n
Un paramètre d'un appel de service peut être un
appel de service
q
n
Matérialiser un document AXML:
q
n
ANY/translate(<from>Tchek</from>,
<to>Francais</to>,
crystalGlasses.cz/getCatalog())
effectuer tous les appels de services, dans le bon ordre
Plusieurs stratégies possibles
vamos.futurs.inria.fr
googleTranslate.com
crystalGlasses.cz
* !
n
Un paramètre d'un appel de service peut être un
appel de service
q
n
Matérialiser un document AXML:
q
n
ANY/translate(<from>Tchek</from>,
<to>Francais</to>,
crystalGlasses.cz/getCatalog())
effectuer tous les appels de services, dans le bon ordre
Plusieurs stratégies possibles
vamos.futurs.inria.fr
googleTranslate.com
crystalGlasses.cz
!!
n
Espace de recherche
q
q
q
n
Modèle de coût
q
n
Choix du peer qui fournit un service appelle
Choix du peer qui invoque un service
Heuristiques
Execution de services, transferts, ...
Stratégie de recherche
q
q
1 peer coordinateur; greedy
décision distribuée: in progress
n
n
n
n
Travaux importants sur la gestion de donnees
distribuées
Travaux existants (et a faire) pour la gestion de
donnees XML
La combinaison des deux est possible
Application intéressante: ActiveXML
q
q
n
n
Modèle de donnees oriente sur les arbres
Modèle d'execution distribue
Beaucoup de croisements intéressants a faire
Besoin de plus de resultats XML
- !