Master Informatique

Rmy Delmotte
MASTER 2 ID
(Informatique et Document)
RAPPORT-MMOIRE DE STAGE
Mission effectue du 18 fvrier 2008 au 18 aot 2008
au
CT Nord Picardie
2 rue de Bruxelles, 59000 Lille.
tude des capacits d'volution du systme de gestion des documents

XML de l'application de gestion des notices bibliographiques Notix
Sous la direction de:

Fabien Torre (responsable universitaire)
Andr Davignon (Tuteur professionnel)
Soutenu le 15 septembre l'UFR MSES

Universit Charles de Gaule, Lille 3 (Campus Pont de bois)
BP 60 149, 59 653 Villeneuve d'Ascq cedex
Anne universitaire 2007/2008
Je tiens remercier:
Fabien Torre pour ses enseignements, sa disponibilit et ses encouragements,
Andr Davignon pour sa disponibilit et ses conseils,
enfin toutes les personnes du PANDoc pour leur accueil.
Sommaire
Introduction:.........................................................................................................................................4
1 Prsentation....................................................................................................................................5
1.1 Environnement du stage..........................................................................................................5
1.1.1 Le Point d'appui national documentaire (PANDoc)........................................................5
1.1.2 Notix, une solution de gestion des notices bibliographiques..........................................5
1.1.3 La gestion des documents XML avec eXist....................................................................7
1.1.4 La communication entre Notix et eXist........................................................................10
1.1.5 XML:db initiative, une tentative de normalisation des bases XML.............................13
1.2 Droulement de la mission...................................................................................................15
1.2.1 Les volutions de la mission.........................................................................................15
1.2.2 La gestion de projet.......................................................................................................16
1.3 Mthodologie........................................................................................................................18
1.3.1 La recherche d'informations et l'valuation..................................................................18
1.3.2 Les cycles de dveloppement........................................................................................19
2 L'tude des systmes de stockage XML.......................................................................................21
2.1 Les types de solution.............................................................................................................21
2.1.1 Les bases de donnes XML..........................................................................................21
2.1.2 Les bases de donnes relationnelles..............................................................................21
2.2 Une pluralit de formats, standards et protocoles.................................................................24
2.2.1 Les API java..................................................................................................................24
2.2.2 Les formats de communication.....................................................................................24
2.2.3 Les dialectes XQuery....................................................................................................25
2.2.3 Organisation des ressources..........................................................................................26
3 Besoins et critique de l'existant....................................................................................................27
3.1 Un avenir incertain pour l'API XMLDB..............................................................................27
3.2 Une dpendance de Notix avec eXist...................................................................................27
3.3 Mlange des logiques de traitement et de stockage..............................................................28
3.4 - Rptitions des algorithmes dans l'application......................................................................29
4 Prconisations et ralisations........................................................................................................31
4.1 Diagnostic.............................................................................................................................31
4.1.1 - Masquer le systme de stockage utilis pour rduire les dpendances..........................31
4.1.2 Augmenter la lisibilit du dispositif d'accs aux ressources XML...............................34
4.1.3 Factoriser les oprations redondantes...........................................................................37
4.1.4 Implmentation de HTTP/REST...................................................................................38
4.2 L'API xdb..............................................................................................................................39
4.2.1 Le patron de conception "stratgie", pour l'implmentation de nouveaux pilotes........39
4.2.2 Une hirarchie de classes qui favorise l'utilisation des standards.................................39
4.2.3 Le dispositif de configuration et de chargement des pilotes.........................................41
4.2.4 Le mcanisme de composition des URL.......................................................................42
4.3 Intgration Cocoon.............................................................................................................44
4.3.1 L'utilisation d'un pilote unique, la classe XDBSource..................................................44
4.3.2 La mise en place d'un systme de cache.......................................................................45
4.4 Les tests unitaires..................................................................................................................47
4.5 Limites du dveloppement de l'API xdb...............................................................................48
Conclusion:.........................................................................................................................................49
Bibliographie:.....................................................................................................................................50
Annexes..............................................................................................................................................51
Introduction:
Le stockage et l'interrogation des documents XML constitue un domaine d'activit qui
connat des volutions. Les outils de stockage et les langages disponibles pour l'interrogation d'un
corpus de documents XML sont dj nombreux, et des processus de normalisation sont en cours.
La base de donnes XML eXist comme les autres solutions de stockage des documents XML
volue au gr des standards, en raction aux solutions concurrentes, et selon des dynamiques
internes.
Le Point d'Appui National Documentaire dveloppe Notix, une application de gestion des
notices bibliographiques dont le stockage des documents XML repose sur eXist.
L'objectif de mon stage consistait dterminer quelles taient les alternatives envisageables
au systme de stockage des documents XML actuel de Notix, qui permettrait d'amliorer les
performances gnrales de l'application.
Au del des aspects d'valuation des solutions et de comparaison de leurs performances, les
questions lies l'volution de Notix et la modularit de l'application ont progressivement merg.
Dans un contexte de forte volution de l'offre de logiciels, et d'une normalisation progressive
mais encore en devenir des outils d'interrogation des corpus XML et des systmes de stockage
XML, quelles stratgies peut-on adopter pour garantir la capacit d'volution et de rutilisation des
composants d'une solution, lors de l'intgration d'un systme de stockage XML ?
Aprs avoir prsent l'environnement du stage et la mission, nous prsenterons les

principales volutions actuelles des systmes de stockage de documents XML "open source", et les
principaux dysfonctionnements et besoins rencontrs dans Notix concernant le systme de stockage
des documents XML. Enfin nous terminerons par la prsentation des prconisations en termes
d'organisation logicielle qui ont t faites, et les ralisations qui les ont suivies.
1 Prsentation
1.1 Environnement du stage
1.1.1 Le Point d'appui national documentaire (PANDoc)
Le PANDoc est un service du Ministre de l'cologie, de l'nergie, du dveloppement

durable et de l'amnagement du territoire (MEDAT). Ses locaux sont situs au Centre d'tude
techniques de l'quipement (CT) Nord-Pas de Calais Picardie.
Le PANDoc ralise des missions d'ordre documentaire pour le compte du MEDAT, et parfois
pour d'autres ministres. Une des spcificits du service est la composition mixte de
documentalistes et d'informaticiens, qui permet la mobilisation du service sur des missions
requrant cette double comptence.
Le PANDoc est en charge de plusieurs bases documentaires qu'il hberge, administre et
alimente, telle que Urbamet1 , ou Temis2. Le PANdoc s'occupe aussi de raliser des applications
documentaires.
1.1.2 Notix, une solution de gestion des notices bibliographiques

1.1.2.1 Prsentation gnrale
Notix est une application de gestion des notices bibliographiques publie sous licence libre.
La solution a t dveloppe par la socit AJLSM , suite un appel d'offre du PANDoc.
Notix permet d'administrer des bases documentaires composes de notices au format XML.
Les principales fonctionnalits de Notix sont les suivantes:
Oprations sur chaque base
Cration et modification d'un gabarit de notice via un formulaire
Cration, suppression, modification et duplication des notices via un formulaire
Moteur de recherche
Modification d'un champ par lot de notice
1 http://urbamet.documentation.developpement-durable.gouv.fr
2 http://temis.documentation.equipement.gouv.fr
Fonctionnalits transversales
Panier de notices
Historique de recherche, gestion des favoris pour la recherche
Gestion de listes de valeurs pour les champs de formulaire
Administration
Cration et suppression de bases documentaires
Rinitialisation des instances, rindexation, optimisation des index
Gestion des groupes et des utilisateurs
Exportation et importation de notices en masse
Notix a t livre au PANDoc en 2007. La solution est en production et fait l'objet de

dveloppements constants, qu'il s'agisse de maintenance ou d'ajouts de fonctionnalits. Lors de mon
stage deux dveloppeurs travaillaient sur Notix. Par ailleurs la solution a t publie sur la
plateforme de dveloppement cooprative adminsource3.
1.1.2.2 Architecture de l'application
Notix est une application web java qui fonctionne sur le serveur d'application Tomcat. Trois
applications libres ont t utilises pour sa ralisation, Cocoon, SDX et eXist4.
La plate-forme de publication Cocoon constitue le squelette de Notix. Elle fournit un
systme de "pipelines" permettant une gestion simplifie de l'application travers des patrons
d'URL situs dans des sitemaps. Chaque pipeline de l'application dlivre un contenu, la plupart du
temps aprs une srie de transformations XSLT. Cocoon fournit par ailleurs un systme de cache
performant et une gestion avance des formulaires avec les formulaires Cocoon (CFORMS).
La plate-forme SDX permet la gestion de toutes les oprations lies la recherche et
l'indexation en offrant une interaction facilite avec le moteur de recherche Lucene. Elle est base
sur Cocoon et fournit une "taglib5" qui permet des dveloppements rapides et fins. Les documents
pris en charge par SDX sont au format XML.
La base de donne XML native6 eXist est utilise pour la gestion des documents XML et
3
4
5
6
http://admisource.gouv.fr/
cf. annexe 1: Architecture de Notix
Littralement, une bilbiothque de balises.
Ronald Bourret, 2005. XML and Databases[En ligne]. [Consult en aot 2008].
http://www.rpbourret.com/xml/XMLAndDatabases.htm
l'excution de requtes XQuery sur les corpus de notices. Elle permet le stockage des documents
dans une hirarchie de collections, et fonctionne en instances multiples. EXist fonctionne dans
Notix en mode embarqu sous forme d'archives java, ou en mode distant dans un serveur
d'application.
Une des principales caractristiques de Notix est de reposer sur le format et les technologies
XML. Dans son fonctionnement l'application exploite XSLT, DOM, SAX, Xpath et XQuery.
1.1.3 La gestion des documents XML avec eXist

1.1.3.1 Fonctionnement de eXist
EXist est une base de donnes XML native. Elle permet le stockage de documents et de
portions de documents XML. Les documents peuvent tre rcuprs ou interrogs travers les
langages de requte XML XPath et XQuery.
L'organisation d'une base eXist peut exploiter un ensemble de collections, similaire des
dossiers dans un systme de fichier pour stocker les documents XML. Une ressource dans une base
de donne XML peut tre reprsente par un chemin. Dans la base eXist la racine de chaque
ressource est la collection "/db".
1.1.3.2 Les bases documentaires
Pour constituer une base de donne documentaire, Notix cre une collection la racine d'une
base eXist, et cre un gabarit de notice sous la forme d'un fichier RDFS7 plac dans la collection.
Pour Notix, une base documentaire existe si ces deux conditions sont vraies. Par exemple la
prsence d'une collection "/db/Unebase" et son gabarit "/db/Unebase/_Unebase.rdfs" produira une
reprsentation de la base documentaire "Unebase" dans Notix.
1.1.3.3 L'alimentation en notices
L'ajout de notices une base documentaire se fait dans des sous-collections contenant 1000
notices. Ce nombre de notices a t choisi pour permettre d'optimiser les index lors des requtes
XQuery vers la base.
Chaque notice prend pour nom et identifiant le nom de la base laquelle elle appartient suivi
d'un nombre de 7 chiffres. Les 4 premiers chiffres sont utiliss pour rpartir les notices dans les
sous-collections. Ainsi pour une base "/db/Unebase", on a une sous-collection "/db/Unebase/0001"
7 Ressource Description Framework Schema
contenant des notices telles que "/db/Unebase/0001/Unebase-0001001.xml".

Dans Notix la gnration de l'identifiant d'une notice est ralis automatiquement partir
d'un compteur stock la racine de la base. A chaque cration de notice, "/db/Unebase/counter.xml"
est consult puis incrment.
1.1.3.4 L'importation automatique
Lors des oprations d'importation automatique de notices, Notix examine le contenu d'un
dossier et enregistre les notices prsentes dans une base documentaire dsigne. Lors de cette
opration Notix gnre un rapport d'alimentation de la base. Ce rapport est stock dans une sous
collection "rapport" situe elle-mme dans une sous collection "_alix", du nom de l'application
grant les conversions de notices: "/db/Unebase/_alix/rapports/Unebase-date.xml".
Les notices trouves lors de l'importation sont examines pour dterminer si elles
correspondent bien au gabarit de la base cible et si les documents ne constituent pas des doublons.
En cas d'erreur, les notices importes sont stockes pour pouvoir tre modifies par la suite,
respectivement dans "/db/Unebase/_alix/notice rejetees/non valides/" et "/db/Unebase/_alix/notice
rejetees/doublons/".
1.1.3.5 Les bases "Groupe" et "Utilisateur"
La gestion des groupes et des utilisateurs dans Notix est identique au dispositif de gestion
des bases documentaires. Les documents qui dcrivent les groupes et utilisateurs sont, comme pour
les notices, dcrits par un gabarit RDFS, et regroups dans une base documentaire. Nanmoins les
documents "groupe" et "utilisateur" obissent une organisation diffrente en tant stock
directement la racine de la collection. Leur nom et identifiant est celui du groupe ou de
l'utilisateur dcrit par le fichier XML. Par exemple "/db/Utilisateur/utilisateur1.xml".
1.1.3.6 La gestion des listes
Les listes sont disponibles pour toutes les bases documentaires de Notix. Elle reprsentent
un ensemble de termes qui pourront tre utiliss comme champ liste dans les formulaires de
cration de notices. Les listes sont constitues dans une interface spare dans Notix et sont
stockes dans eXist dans une collection "Liste" qui n'est pas associe une base documentaire, c'est
dire sans gabarit RDFS. Les documents de la collection liste sont au format RNG8. Ils sont
enregistrs la racine de la sous collection , et ils sont identifis et nomms par la dsignation
donne dans l'application. Par exemple "/db/Liste/uneliste.rng".
8 RNG pour Relax NG (REgular LAnguage for XML Next Generation) qui est un langage de schma XML
1.1.3.7 Les instances multiples
Notix peut utiliser plusieurs instances d'une mme base eXist. Par dfaut, Notix utilise une
instance eXist nomme "notix", dans laquelle elle cre systmatiquement, si elles n'existent pas, les
bases "Groupe" et "Utilisateur", et la collection Liste. Par la suite, Notix permet la cration de bases
documentaires sur une instance choisie, pourvu qu'elle soit dclare dans la configuration de Notix.
La base eXist qui fournira les instances Notix peut tre disponible sous la forme d'une base
embarque (stocke comme archive java dans les bibliothques de Cocoon) ou sous la forme d'un
serveur d'application distant disposant de eXist.
1.1.3.8 Les URL d'accs aux ressources
Pour accder aux ressources d'eXist depuis Cocoon, Notix emploie l'API XMLDB qui
permet de dsigner les ressources par des URL. L'ensemble des accs aux documents XML est
assur par la dsignation des emplacements dans eXist. Les URL sont constitues selon deux
formats, selon que la base est embarque ou distante. Les patrons des URL sont les suivants:
Pour une base embarque: "xmldb:nomInstance:///chemin"
Pour une base distante: "xmldb:nomInstance://adresseDuServeur/nomInstance/xmlrpc/chemin"
Illustration 1: Organisation du stockage des donnes XML de Notix dans eXist
1.1.4 La communication entre Notix et eXist

1.1.4.1 La configuration des instances eXist
Pour pouvoir disposer de plusieurs instances d'une base eXist dans Notix, une dclaration
pralable est ncessaire dans le fichier de configuration de Cocoon cocoon.xconf. Les instances sont
dclares avec un certain nombre de paramtres de configuration ncessaires leur initialisation.
<component-instance class="org.exist.cocoon.XMLDBSourceFactory"
name="xmldb">
<driver type="notix" class="org.exist.xmldb.DatabaseImpl"
user="admin" password="admin">
<database-id>notix</database-id>
<create-database>true</create-database>
10
<configuration>xmldb/notix.xml</configuration>
</driver>
<driver type="instance2" class="org.exist.xmldb.DatabaseImpl"
user="admin" password="admin">
<database-id>instance2</database-id>
<create-database>true</create-database>
<configuration>xmldb/instance2.xml</configuration>
</driver>
</component-instance>
Les instances de eXist sont dclares comme pilotes de base de donne, et associes au
pseudo-protocole "xmldb:". Cette dclaration des instances autorise plusieurs manipulations dans
Cocoon:
L'obtention d'une liste des instances configures.
L'interrogation d'eXist directement par le protocole "xmldb:", grce au mcanisme des

sources Cocoon et l'API XMLDB.
1.1.4.2 La configuration d'un serveur eXist distant
La configuration d'un serveur eXist distant se traduit par la dclaration d'une variable
globale dans un sitemap Cocoon. Au dmarrage de Notix, la prsence du paramtre est dtecte, et
une variable globale prend pour valeur l'adresse du serveur distant. Lors du fonctionnement de
l'application, l'ensemble des requtes sera adress au serveur distant grce au dispositif de
composition des URL de Notix.
<global-variables>
<exist-url>172.16.41.5:8088</exist-url>
</global-variables>
1.1.4.3 Le mcanisme de composition des URL
Le mcanisme de composition des URL de Notix est ralis en plusieurs tapes.

Lorsqu'une requte est adresse Notix pour raliser une opration sur un document, le pipeline en
charge de la ralisation de cette opration reoit comme argument le nom d'une base documentaire,
et l'identifiant d'un document.
partir de cette information, Cocoon mobilise une liste des bases documentaires recenses
dans les instances eXist, et tablit quelle instance d'eXist sera interroge, par exemple
"xmldb:notix/". Dans un second temps, Cocoon vrifie l'tat de configuration de la variable "exist11
url", et adopte un patron d'URL adapt un eXist embarqu ou distant.

Lorsque la ressource interroge est une notice de base documentaire, la sous-collection dans
laquelle est range la notice est dduite de l'identifiant donn en argument, par exemple "0002" pour
le document "Base-0002001.xml".
1.1.4.4 Implmentation dans Notix
Trois stratgies sont utilises pour l'accs la base de donnes XML:
En utilisant un composant cocoon (FileGenerator) qui rcupre directement le contenu

d'une source en SAX. Cette stratgie est utilise seulement pour la lecture des
documents. Elle est utilise pour les oprations dans l'instance par dfaut "notix" pour
accder aux listes, aux groupes et aux utilisateurs.
<map:generate src="xmldb:notix:///db/Listes/"/>
En utilisant 2 composants Cocoon. Le premier excute le mcanisme de composition de

l'URL atteindre (Action XMLDBURL), le second est un FileGenerator qui produit un
flux SAX partir des informations recueillies. Cette stratgie est utilise pour l'accs en
lecture des documents contenus par les bases documentaires.
<map:match pattern="*/*.xml">
<map:act type="xsp" src="context:/exist/xsp/xmldbURL.xsp">
<map:parameter name="base" value="{1}"/>
<map:parameter name="notice" value="{2}"/>
<map:generate src="{collection}{resource}"/>
En utilisant des scripts serverpages ou flowscript. Dans ce cas, les informations

ncessaires l'identification du document traiter sont passes en paramtre au script.
L'action XMLDBURL peut tre utilise ou non, si elle ne l'est pas, le mcanisme de
composition des URL est ralis dans les scripts. Cette stratgie est la plus couramment
utilise dans Notix car elle permet l'excution d'oprations complexes, notamment les
oprations d'criture et de requtes XQuery.
<map:generate type="xsp" src="xsp/lists-edit.xsp">
<map:parameter name="url" value="xmldb:notix:///db/Listes/

{1}.rng"/>
<map:parameter name="name" value="{1}"/>
12
</map:generate>
<map:act type="xsp" src="xsp/xmldbURL.xsp">

<map:generate type="xsp" src="xsp/supprimer-panier.xsp">
<map:parameter name="pj" value="{global:pj}" />
<map:parameter name="path-sdxapp"
value="{global:path-sdxapp}" />
<map:parameter name="base" value="{../1}"/>
<map:parameter name="collection"
value="{collection}"/>
</map:generate>
Puis dans la xsp, manipulation de la source Cocoon9:

Source notice=resolver.resolveURI(collection + folder + "/" + id + ".xml");
((XMLDBSource)notice).delete();
1.1.5 XML:db initiative, une tentative de normalisation des bases XML
XML:db initiative est un groupe d'intrt autour des technologies XML qui a pour objectif le
dveloppement de technologies standardises dans le domaine des bases de donnes XML, et plus
gnralement la promotion des bases de donnes XML. L'association, active de 2000 2004, avait
pour vocation de proposer des standards sous licence "open source" dans le domaine des bases de
donnes XML. La motivation de cette dmarche tait d'viter la multiplication des technologies
concurrentes, et l'apport rapide de technologies attendues telle que l'extension de XQuery pour les
oprations de mise jour. Le groupe a finalement produit deux recommandations, l'API XMLDB, et
l'extension XQuery XUpdate.
L'API XMLDB est un ensemble d'interfaces java qui prescrit des mthodes d'accs, de
configuration et d'interrogation d'une base de donne XML. Elle permet la manipulation des
collections et documents, et fournit un service d'interrogation XQuery d'un document ou d'une
collection. L'API a t implmente dans eXist et constitue le mode de communication actuel de
Notix avec la base de donne.
Xupdate est une extension au langage de requte XQuery dont le but est d'ajouter la
9 Pour un exemple plus complet de la manipulation des sources cocoon voir annexe 2: Traitement d'un document
XML dans une xsp.
13
possibilit d'diter des documents XML existants en s'intgrant la syntaxe de XQuery. Le langage
est apparu en 2003 sous la forme d'une recommandation inacheve (un "brouillon"), mais a
nanmoins t implment par eXist puisqu'il constituait alors la seule tentative de normalisation
des oprations d'criture en XQuery. Notix utilise ces oprations d'criture pour la correction des
notices par lots, l'dition des listes et des documents utilisateurs.
14
1.2 Droulement de la mission

1.2.1 Les volutions de la mission
La mission de stage qui m'a t propose consistait tudier les performances du systme de
stockage des notices de Notix. L'objectif de cette tude tait de rvaluer la pertinence du choix
actuel de systme de stockage en termes de performances, au regard des solutions existantes. Le
projet s'articulait en trois grandes tapes:
Une qualification des besoins permettant de dfinir le primtre de l'tude.
La mise en place d'un dispositif de veille et d'valuation des solutions de stockage XML.
La conception d'une srie de tests de performance adapts aux usages dans Notix.
Les bnfices attendus de la mission taient une meilleure connaissance de l'offre pour les
systmes de stockage de documents XML, une valuation critique de la solution actuelle, et
potentiellement de meilleures performances pour Notix.
A l'issue de la veille, plusieurs constats ont t raliss qui ont orient davantage la mission
vers la recherche d'une implmentation prenne et gnrique du systme de stockage XML. Une
meilleure connaissance de la constitution des principales solutions de stockage des documents XML
m'a amen considrer les limites qu'impliquaient la conception actuelle des communications avec
le systme de stockage.
Cette seconde phase du projet s'est traduite par une prolongation de l'tude de Notix, et la
mise en place de cycles de dveloppement. L'tude a port sur la communication entre Notix et
eXist et la recherche d'optimisations pour la gestion des documents XML, en vue de disposer d'une
implmentation la plus gnrique possible au regard des diffrentes solutions de stockage des
documents XML existantes.
Cette phase du projet s'est droule en trois tapes:
Un recueil des principales variations qui existaient entre les diffrents systmes de
stockage XML.
Une analyse dtaille de l'implmentation d'eXist dans Notix et l'implmentation d'un

nouveau mode de communication entre eXist et Notix travers des requtes HTTP
(REST).
15
La conception et l'implmentation d'un dispositif gnrique de gestion du stockage des

documents XML dans Notix, en vue d'amliorer l'intgration du nouveau dispositif de
communication et de favoriser les volutions futures.
1.2.2 La gestion de projet

Lots de Tches:
Dmarche exploratoire
tude/Veille sur les solutions de stockage des documents XML
tude des besoins et de l'existant
tude comparative/veille sur les solutions libres de stockage des documents XML
diagnostique et prconisations
Implmentation d'une interface HTTP REST entre Notix et eXist
Recensement des stratgies, mthodes et outils lis au systme de stockage XML.
Implmentation de REST
tude des dpendances lies aux systmes de Stockage dans Notix
Optimisation de l'implmentation en termes de couplage, performances, et d'ouverture aux

standards
valuation des amliorations possibles, conception de l'API xdb
Dveloppement de l'API xdb
Implmentation des amliorations dans Notix
fvrier
mars
avril
Dmarche
exploratoire
mai
juin
juillet
aot
Implmentation d'une interface HTTP REST
Veille sur les solutions de stockage XML
Optimisation de l'implmentation
Illustration 2: Droulement de la mission par lot de tches
16
fvrier
Dmarche
exploratoire
mars
avril
mai
juin
juillet
Veille sur les solutions de stockage

XML
tude des besoins
aot
Conception API
xdb
valuation des
solutions et bilan
de l'tude
Prco
nisati
ons
tude des besoins:
seconde analyse de Notix, dveloppement
interface REST
Dveloppement
API xdb
Implmentation dans
Notix
Illustration 3: Droulement de la mission (dtail)
17
1.3 Mthodologie
1.3.1 La recherche d'informations et l'valuation
Pour mener bien la comparaison des solutions, une premire tude des fonctionnalits
d'eXist utilises dans Notix a t ralise10. L'objectif tait d'tablir un talon pour l'valuation des
fonctionnalits des autres solutions. Cette description des besoins a permis de dcouvrir
progressivement les variations existantes entre les diffrentes solutions, et les amnagements qui
seraient ncessaires dans la conception de Notix pour pouvoir considrer ces solutions comme des
alternatives possibles eXist.
Trois critres dfinissaient le primtre de la recherche. Les solutions devaient tre
utilisables sur les systmes d'exploitation Windows et Mandriva, et les sources disponibles sous
licence open-source. Enfin si les solutions ncessitaient l'usage d'une base de donnes relationnelle,
celles-ci devaient tre utilisables avec PostgreSQL qui constitue le standard au PANDoc. Par
ailleurs, des essais avaient dj t effectus par le PANDoc et l'AJLSM sur un stockage direct des
documents XML sur systme de fichier. La solution tait donc exclue de la recherche d'information.
L'valuation des diffrentes solutions a t guide par 3 types de barme:
La distance avec l'existant.
L'valuation du logiciel "open source".
La prise en compte de l'volution des standards au niveau des API et des technologies
XML par les solutions values.
La mthode d'valuation des logiciels "open source" employe est un arrangement partir
des barmes de la mthode de qualification et de slection de logiciels open source11
(QSOS), et de la mthodologie de cration du guide bull de l'open source12. La barme tait
le suivant:
Barme
Utilisateurs
*
Pas d'utilisateurs
identifis
**
***
Utilisateurs
Communaut
dtectables via internet d'utilisateurs identifis /
Rfrences
10 cf. Annexes 4: tude des besoins
11 http://www.qsos.org/methode.php?lang=fr
12 http://www.novaforge.org/novaforge/fr-partager/methodologie
18
Barme
**
***
Communaut
Groupe de dveloppeurs Communaut

clos / Socit
priphrique /
contributeurs
Fonctionnement en
communaut et outils
associs
Documentation
Basique
Utilisateurs et
dveloppeurs
Systmatis, avec
contributions
Activit
0 3 dveloppeurs
4 7 dveloppeurs, ou + de 7 dveloppeurs
fort turn-over
Maturit
Encore en
dveloppement, pas de
version stable
Version(s) stable(s),
utilisable.
Actualit
Le projet semble
l'abandon
Projet actif, mais

Forte participation,
communication/partici nombreuses actualits
pation peu dense
Version prouve.
Roadmap.
1.3.2 Les cycles de dveloppement

Lors de la seconde phase de la mission de stage, il a t dcid d'implmenter une nouvelle
interface de communication entre Notix et la base eXist. La ralisation de ce projet s'est droule en
plusieurs tapes, en suivant un principe de dveloppement par itrations.
Le premier objectif de dveloppement tait de reproduire le fonctionnement de Notix avec
HTTP/REST, sans chercher d'optimisations particulires du fonctionnement. Il s'agissait d'abord
d'assurer la reproduction des fonctionnalits de l'application.
Une seconde tape a consist rechercher les optimisations possibles de l'implmentation
ralise, en termes d'organisation, de prennit et de lisibilit. Cette tape a conduit la cration
d'une API java ddie la communication avec le systme de stockage.
La dernire tape a t l'implmentation de l'API dans Notix, soit la modification des scripts
de l'application et des fichiers de configuration de Notix. L'objectif de cette tape tait d'assurer
l'implmentation, mais aussi de raliser des optimisations, cette fois au niveau des performances.
Ce droulement en trois tapes a permis de distinguer des logiques de travail et

d'apprhender sparment les difficults du projet.
La premire tape m'a permis de m'approprier le fonctionnement de l'application, d'tablir la
logique des traitement effectus, et de recenser les diffrentes stratgies d'accs au systme de
19
stockage.
La deuxime tape s'est davantage amorce comme une revue critique de l'implmentation,
nourrie par l'tude des systmes de stockage existants. Il s'agissait de concevoir des critres de
gnricit, et d'valuer quelles technologies dans Notix pouvaient tre considres comme prennes.
Le travail consistait donc distinguer les lments changeants et adopter une organisation
permettant de faire face ces changements.
La dernire tape, reste de peu inacheve, a t un mlange des deux logiques de
dveloppement prcdentes : l'implmentation du nouveau dispositif, l'ajout de fonctionnalits
omises, la rectification d'algorithmes, et la recherche d'optimisations des performances appelaient
une vision pragmatique et un souci du dtail.
20
2 L'tude des systmes de stockage XML

Cette partie prsente les principales conclusions et constats qui ont suivi la veille sur les
systmes de stockage des documents XML.
2.1 Les types de solution

2.1.1 Les bases de donnes XML
Les bases de donnes XML natives se distinguent des systmes de stockage XML
fonctionnant avec des bases de donnes relationnelles par 3 caractristiques:
elles prservent la structure physique des documents (lments, attributs, entits, ...)
elles permettent de stocker des documents sans dclaration pralable du schma des
documents.
elles permettent d'accder aux documents partir des API spcifiques XML (Xpath,
XQuery).
Par ailleurs les bases de donnes XML natives permettent la cration de collections
( assimilables des dossiers dans un systme de fichier)
Les principales bases de donnes XML actives "open source" sont les suivantes :
eXist initi par Wolfgang Meier
Berkeley DB XML de Oracle.
Le projet apache Xindice
BaseX du groupe de recherche allemand Database & Information Systems Group
Sedna du groupe de recherche russe Management Of Data & Information Systems
MonetDB/XQUERY de l'institut de recherche nerlandais Centrum Wiskunde &

Informatica
2.1.2 Les bases de donnes relationnelles

Il existe deux manires d'exploiter les bases de donnes relationnelles pour le stockage des
documents XML, les bases de donnes acceptant un type XML, et l'utilisation de middlewares.
21
2.1.2.1 - Les bases de donnes Hybrides ou grant un type XML
Certaines bases de donnes relationnelles permettent de grer un format XML, d'autres

proposent une interface similaire une base de donne XML native (On parle de base hybride).
Actuellement, les bases de donnes hybrides sont des solutions propritaires (dbxml de Oracle et
db2 de IBM).
La gestion des donnes XML dans les bases de donnes relationnelles s'est longtemps
rsume au stockage de chanes de caractres. Actuellement on peut voir au moins deux volutions
dans la gestion de XML:
- Le stockage du XML dans les bases de donnes relationnelles fait l'objet d'optimisations
plus adaptes, avec la cration d'un type XML propre dans les bases de donnes (Arbres binaires).
- La standardisation de fonctions de gestion du XML dans le langage SQL, ainsi que des
recommandations pour l'implmentation de XQuery, via les standards ANSI/ISO, SQL/XML:2003
et SQL/XML:2006 commencent tre dveloppes dans les SGBDR.
L'implmentation de fonctionnalits XML reste nanmoins assez limite, et la prochaine
tape attendue reste le support de XQuery.
Au niveau du type XML, seul PostgreSQL propose une solution optimise avec une
structure de donnes (des arbres binaires) et des index adapts. En termes de fonctions XML, on
retrouve peu prs les mmes fonctionnalits dans MySQL et PostgreSQL: gnration, importation
et accs en XPath au XML. MySQL se distingue nanmoins par l'apport d'un mcanisme de mise
jour des donnes en XPath. Pour les deux solutions, il n'existe pas de support de XQuery, et le
langage d'interrogation demeure SQL. Pour l'accs aux donnes depuis java, les pilotes JDBC sont
utilisables mais ils ne sont pas optimiss pour le traitement d'un modle de document XML.
De manire gnrale, la gestion de documents XML par l'intermdiaire d'une base de
donnes relationnelle n'est pas adapte l'utilisation des API XML.
2.1.2.2 - Les middlewares
Les middlewares ou applications intermdiaires sont utiliss pour le stockage des documents
XML dans les bases de donnes relationnelles, ou pour la manipulation du XML sous forme
22
d'objets. Nous nous intressons ici au premier type uniquement.

Les applications intermdiaires permettent de manipuler les SGBDR de la mme faon que
les bases de donnes XML natives. Les solutions prennent en charges deux aspects: le stockage du
XML dans les tables du SGBDR, et la traduction des requtes en langage XML vers le SQL.
Parmi les solutions existantes on distingue celles qui ne ncessitent pas la dclaration
pralable d'un schma pour le stockage de documents /collections XML, et celles implmentant les
standards XML d'accs aux donnes (XPATH, XQuery).
Dans ce domaine, seul pf/Tijah permet de se passer d'une dclaration pralable du schma
des documents XML. La solution intgre le middleware PathFinder qui permet le stockage en base
de donnes de documents XML, et la traduction de requtes XQuery et XPath en requtes SQL. Pf/
Tijah quand lui intgre la gestion de la recherche plein texte en XQuery.
Les fonctionnalits de Pf/Tijah sont actuellement implmentes dans MonetDB/XQuery, et
aucune facilit n'est faite pour permettre l'intgration dans un autre SGBDR. Seul un article sur
l'intgration dans PostgreSQL paru en 2004, voque la possiblit de le faire; les sources du
middleware ne sont cependant pas accessibles.
Aucune solution de middleware n'a donc t tudie plus avant. Nanmoins l'tude de
MonetDB/XQuery a t ralise parmi les solutions de bases de donnes XML, l'intgration de
pf/Tijah tant transparente.
23
2.2 Une pluralit de formats, standards et protocoles

2.2.1 Les API java
La premire API java avoir t dveloppe des fins de standardisation des accs aux
bases de donnes XML tait l'API XMLDB. Depuis l'arrt des travaux de XML:db initiative,
l'volution du standard est arrte et les API spcifiques aux solutions se dveloppent. Pour les
solutions qui ont implment l'API XMLDB, comme eXist, des volutions ont t apportes qui ne
font plus partie du standard.
Actuellement la JSR 225 XQJ (XQUERY API for Java) semble constituer une alternative
pour les concepteurs de bases de donnes XML natives. Le projet de recommandation est support
par les principaux concepteurs de bases de donnes XML propritaires. La recommandation
dfinitive date du mois de mars 2008. Dans les solutions "open source" l'implmentation est
cependant loin d'tre gnralise.
Pour les principales solutions tudies:
eXist
BDB XML
Xindice BaseX
Sedna
MonetDB/X
QUERY
- xml:db API
oui
non
Oui
Non
Oui
Non
- XQJ (JSR
225)
(en
non
dveloppem
ent)
Non
Non
non
Non
- autres
Non
Non
API
Java.
C, Php,
XRPC(java/j
python, .net, avascript),
Scheme.
CGI binding
(.xq), MAPI
API Java dbxml,

Ruby, PHP, .NET
Illustration 4: Revue des API utilises dans les bases de donnes XML
2.2.2 Les formats de communication

Il existe deux modes possibles pour l'utilisation d'une base de donne XML : les
bases de donnes embarques, et les bases de donnes fonctionnant sur le mode client-serveur;
certaines bases supportant les deux modes de fonctionnement.
Pour les bases de donnes embarques seule une API permet d'effectuer des transmissions de
donnes. Pour les bases fonctionnant sur le mode client-serveur, diffrentes approches existent. Du
protocole binaire bas sur la manipulation de "sockets", aux protocoles orients services web :
SOAP, REST, XML-RPC... noter l'engouement naissant pour le protocole de publication Atom
24
(APP), quivalent WebDav mais bas sur une architecture REST.

Le tableau suivant tablit les implmentations des diffrentes stratgies de communication
en fonction des solutions tudies:
eXist
BDB
XML
Xindice
BaseX
Sedna
MonetDB/
XQUERY
- Mode de
Mode
Mode
Mode embarqu Mode Mode
fonctionnement embarqu, mode embarqu et client-Serveur Serveur Serveur
serveur.
Mode
Serveur
"socket-based"
Non
Non
Oui
Oui
Non
XML-RPC
Oui (via
XMLDB)
Oui
Non
Non
Non
SOAP
Oui
Non
Non
Non
Oui
REST
Oui
Non
Non
Non
Non
APP
Oui
Non
Non
Non
Non
Webdav
Oui
Non
Non
Non
Non
XRPC/XqueryD Non
Non
Non
Non
Oui
Illustration 5: Implmentation des statgies de communication par base de donnes XML
2.2.3 Les dialectes XQuery

Pour la consultation des ressources stockes dans les bases de donnes XML natives, les
diffrentes solutions implmentent des standards W3C diffrents niveaux de conformit, ainsi que
des technologies d'accs et de modification propres. Les standards les plus couramment
implments sont XPath 1.0 et XQuery 1.0, suivis de XPath 2.0.
Concernant les langages de mise jour on distingue trois alternatives, l'utilisation de
XUpdate recommand par XML:db initiative, XQuery Update Facility (XQUF) qui a fait
rcemment l'objet de brouillons du W3C, enfin des solutions spcifiques aux applications.
Un langage de recherche en texte intgral a t recommand par le W3C, mais les
recommandations n'ont pas encore abouti. Selon les solutions des dialectes spcifiques ont t mis
au point, ou les premires recommandations sont dj implmentes.
Des dialectes encore marginaux dans les bases de donnes XML tendent se dvelopper
pour rsoudre des situations varies, tel XQueryP(Procedural XQuery) ou XQueryD (D pour
Distributed: interrogation de plusieurs bases distantes au sein de requtes XQuery).
25
L'implmentation de XQuery dans les bases de donnes XML est test par la XQuery Test
Suite (XQTS) du W3C.
eXist
BDB XML
- XUPDATE Oui
(xml:db)
Non
- XQUERY
99.4%
(XQTS)
- XPath
Oui(1,2)
- XQUF
- XQUERY
FT
Xindice
Sedna
MonetDB/X
QUERY
Non
Oui
Non
99.5% (XQTS) Non
99.3%
(XQTS)
98.8%
(XQTS )
En partie
Oui (1,2)
Oui(1)
Oui (1,2)
En partie
(partiel, vers Non(autre)

Non
un support (en
complet)
dveloppement)
Non (autre)
Non (autre) Oui
oui
Partiel
Non
Non
Oui
BaseX
Oui (1)
Non
Non (autre)
Illustration 6: Implmentation de XQuery par base de donnes XML
2.2.3 Organisation des ressources

La possibilit d'organiser les documents dans les bases de donnes XML natives
varie selon les solutions : on trouve la notion de base de donnes (unique ou multiple), de collection
(unique, multiple, embotable), de document (comme unit, ou sous-arbre d'un unique document).
Pour les solutions tudies:
eXist
BDB XML
Xindice
BaseX
Sedna
- Hirarchie Oui
de
collections
Non
Oui
(Prsence de
"containers":
1 niveau de
hirarchie.)
Non
- Instances Oui
multiples de
bases de
donnes
Non
Oui, mais
Non
une bdd = 1
document.
Oui
Non (1
niveau)
MonetDB/X
QUERY
Non, 1
niveau
Non
26
3 Besoins et critique de l'existant

3.1 Un avenir incertain pour l'API XMLDB
L'API XMLDB ne constitue plus un standard pour la manipulation des bases de donnes
XML. Diffrents constats ont pu tre faits lors de l'analyse des systmes de stockage des documents
XML:
La faible prsence de l'API parmi les solutions tudies ne permet plus de garantir les
ambitions de ralisation d'une interface standardise pour les diffrentes bases de
donnes XML.
La mise en place d'une API concurrente XQJ, appele devenir une rfrence pour
l'excution du XQuery dans les applications java, semble constituer une alternative plus
consensuelle car elle favorise davantage l'utilisation des technologies XML.
L'arrt des activits de l'XML:db initiative a entran un arrt des volutions de l'API, et
a mis en faillite l'avenir de la recommandation comme standard du point de vue des
principales solutions de stockage.
L'API XMLDB permet la manipulation des documents et des collections, alors que cette
dernire caractristique n'est pas trs rpandue dans les bases de donnes XML natives.
La tendance gnrale de normalisation des communications semble s'orienter vers les

protocoles et architectures de services web au dpend des API java. On remarque
notamment la forte prsence de SOAP qui a t normalis par le W3C, et REST bas sur
le protocole HTTP.
3.2 Une dpendance de Notix avec eXist

L'organisation des ressources dans eXist utilise une rpartition des documents en souscollections imbriques. Au niveau de Cocoon, cette organisation se traduit par l'utilisation de
chemins refltant cette structure logique. On a par exemple:
xmldb:notix/db/Base/0001/Base-0001001.xml
Dans cet exemple, plusieurs caractristiques propres eXist apparaissent :

27
La dsignation d'une instance de base de donnes "notix", et non le nom de la base

comme le prescrit l'API XMLDB.
La mention de la racine commune aux bases eXist "/db", qui dans les autres bases de
donnes correspond un simple "/" ou au nom d'un conteneur.
L'imbrication des collections "Base" et "0001". L'implmentation des collections est

toujours assez peu rpandu parmi les solutions libres, et l'imbrication de collections est
une spcificit de eXist.
La rpartition des notices par collection de 1000 units est une organisation des
documents qui vise optimiser les performances d'eXist. Ce type d'organisation n'est pas
ncessaire, ni parfois mme conseill, dans les autres bases de donnes.
L'utilisation de chemins pour accder aux ressources XML stockes dans eXist produit une
dpendance de Notix vis vis du systme de stockage XML eXist. Alors que l'ensemble des
oprations prisent en charge par Notix permet le traitement de documents dans le cadre d'une base
documentaire (ou d'un dossier dans le cas de la collection "Liste"), les communications avec le
systme de stockage ncessitent de manipuler explicitement l'arborescence des collections propres
un systme.
Le mcanisme gnral de composition des URL ncessite de dclarer de nombreux
endroits dans Notix les patrons d'URL tablissant la conversion entre les requtes de l'utilisateur et
l'accs un document dans eXist en vue de son traitement. La multiplication de ces oprations
constitue un frein important aux projets d'volution de la solution du systme de stockage des
documents XML.
3.3 Mlange des logiques de traitement et de stockage

Chaque pipeline de Notix qui excute une opration sur un ou plusieurs documents XML
ralise avant chaque traitement le mcanisme de composition des URL d'accs aux ressources. Ce
mcanisme est partiellement factoris par l'intermdiaire de l'action XMLDBURL, mais pas pour
tous les pipelines. La composition des URL est alors intgre aux scripts serverpages ou flowscript.
Dans ce cas de figure, les scripts combinent globalement trois rles:
28
La composition des URL.
Les opration d'accs et de stockage des notices.
Les traitements et la gnration de contenus.
Cette dmarche est insatisfaisante car elle produit des scripts complexes et difficiles
apprhender. La gestion des URL dans l'application s'ajoute aux oprations de traitements ce qui
rduit la lisibilit des scripts.
Par ailleurs, le dispositif de composition des URL est globalement dispers, et rend difficile
le projet d'implmentation d'un autre systme de stockage que eXist. L'usage du fichier
cocoon.xconf d'une part, et de la variable globale de sitemap d'autre part, gnre une multiplication
des oprations ncessaires la composition des URL vers les ressources XML, et rend ncessaire
ces oprations avant chaque traitement, ce qui entrane un manque de lisibilit et une fermeture aux
volutions.
3.4 - Rptitions des algorithmes dans l'application

Un certain nombre d'oprations lmentaires sont excutes de manire rcurrente dans
Notix:
L'obtention du nom de l'instance eXist d'une base documentaire.
java.util.Map baseMap=null;
if (base != null) {
baseMap=(java.util.Map)baseList.get(base);
String url=(String)baseMap.get("url");
source = (XMLDBSource)resolver.resolveURI(url + "/_" + base +
".rdfs");
Le choix du patron d'URL appropri selon que la base est locale ou distante.
String existUrlString=(String)context.getAttribute("existUrl");
String uri;
if (("///".equals(existUrlString)) || ("local".equals(existUrlString))
|| ("".equals(existUrlString)) || existUrlString==null) uri="xmldb:" +
instance + ":///db/";
else uri="xmldb:" + instance + "://" +
existUrlString+"/"+instance+"/xmlrpc/db/";
source = (XMLDBSource)resolver.resolveURI(uri);
La conversion de documents du format SAX au format DOM et rciproquement.
29
source = (XMLDBSource)resolver.resolveURI(url + "/_" + base +

".rdfs");
org.apache.cocoon.xml.dom.DOMBuilder rdfsBuilder;
rdfsBuilder = new org.apache.cocoon.xml.dom.DOMBuilder();
source.toSAX(rdfsBuilder);
Document rdfsDoc=null;
rdfsDoc = rdfsBuilder.getDocument();
La conversion de chanes de caractres au format DOM et inversement.
function dom2string(document) {
var writer = new Packages.java.io.StringWriter();
var format = new
Packages.org.apache.xml.serialize.OutputFormat("XML","utf-8",true);
var serializer = new
Packages.org.apache.xml.serialize.XMLSerializer(writer,format);
serializer.asDOMSerializer();
serializer.serialize(document);
return writer.toString();
}
Les opration d'numration des collections et des ressources d'une collection.
La cration d'une base documentaire.
Etc.
Ces oprations sont excutes dans les scripts de l'application, et ne font dans le meilleur des
cas l'objet d'une factorisation qu' l'chelle du script, par l'intermdiaire de la dfinition de
fonctions. Cette organisation produit une rptition des algorithmes qui rend la maintenance
difficile, favorise les risques d'erreur et rend difficile l'harmonisation gnrale des stratgies de
l'application.
Notix ayant t dvelopp par plusieurs personnes, et dans des priodes de temps
successives, on rencontre aussi des algorithmes ralisant des tches similaires avec des stratgies
diffrentes, notamment pour les oprations de conversion des donnes.
30
4 Prconisations et ralisations
4.1 Diagnostic
4.1.1 - Masquer le systme de stockage utilis pour rduire les
dpendances
4.1.1.1 Cration d'un pilote intermdiaire: l'API xdb
La cration de l'API xdb rpond au besoin de garder la capacit de modifier l'interface de

communication vers un systme de stockage, ou le systme de stockage lui-mme, sans ncessiter le
bouleversement de l'organisation de gnrale de Notix ou du contenu des scripts de l'application.
L'API xdb est un dispositif gnrique qui permet d'encapsuler les mthodes concrtes de
communication avec un systme de stockage. L'API est utilise comme interface pour l'accs au
systme de stockage et fournit un ensemble d'outils pour la ralisation d'oprations sur les
documents.
Au niveau du fonctionnement, chaque systme de stockage XML est reprsent par un pilote
spcifique qui implmente une mme classe abstraite nomme Xdb. La classe Xdb est compose
majoritairement de mthodes abstraites qui prescrivent les oprations de base que les pilotes
devront implmenter.
Au niveau de l'utilisation de l'API, une classe nomme XdbManager s'occupe de faire le lien
entre les requtes au systme de stockage faite dans Notix et le pilote appropri.
La cration d'une source Cocoon (comme celle existante pour l'API XMLDB) permet
d'accder aux ressources par la composition d'une URL depuis un script ou un gnrateur Cocoon,
ce qui permet de faciliter l'intgration de l'API.
4.1.1.2 Des patrons d'URL gnriques
La cration d'URL gnriques rpond au besoin d'accder aux documents XML selon une
organisation logique des ressources sans pour autant rester dpendant du systme de stockage
utilis.
Le principe adopt pour la constitution de chemins gnriques est de distinguer des adresses
logiques correspondant des ressources dfinies, et d'encapsuler la logique de composition des
chemins rels en fonction du systme de stockage utilis.
Les URL gnriques d'accs aux documents XML ont t conu pour faciliter les accs par
31
base documentaire. Le patron d'URL est le suivant: "xdb:Unebase/chemin"

Les chemins peuvent tre les suivant:
Une notice: "xdb:Unebase/Unebase-0000001.xml"
Un rapport d'alimentation: "xdb:Unebase/rapport/Unebase-date.xml"
un gabarit de notice: "xdb:Unebase/_Unebase.rdfs"
Une notice rejete non valide: "xdb:Unebase/non-valides/Unebase-0000001.xml"
Une notice rejete en double: "xdb:Unebase/doublons/Unebase-0000001.xml"
Afin d'accder aux ressources ne figurant pas dans une base documentaire, la mention de la
base peut tre omise dans l'URL. Le chemin crit parcourt alors la structure relle de la base partir
de la racine de l'instance par dfaut. Par exemple: "xdb:/Listes/Uneliste.rng".
La logique d'encapsulation des processus de composition de l'URL concrte d'accs aux
ressources permet une grande souplesse dans la varit des chemins. De nouveaux patrons d'URI
peuvent facilement tre implments, sur la base de nouvelles conventions d'URI gnriques.
4.1.1.3 Un dispositif central de configuration
La mise en place d'un dispositif central de configuration du systme de stockage rpond au

besoin de configurer les instances du systme de stockage en vitant la dispersion des paramtres de
configuration, en rendant indpendant de Cocoon le paramtrage des instances, et en permettant la
reproduction des fonctionnalits multi-instances pour des solutions qui ne disposent pas de cette
fonctionnalit nativement.
Le systme de configuration centralise du systme de stockage consiste dclarer
l'ensemble des instances manipules dans Notix dans un fichier de configuration XML unique. Le
fichier de configuration "XDBConfig.xml" permet de dclarer plusieurs instances, mais ajoute aussi
la possibilit de dclarer plusieurs systmes de stockage. Ainsi le systme de configuration permet
de dsigner plusieurs instances dans plusieurs systmes de stockage, et offre ainsi la possibilit de
reproduire la fonctionnalit d'instances multiples d'eXist pour les systmes de stockage qui ne
l'implmentent pas, via la dclaration d'un mme systme de stockage plusieurs fois.
Cette stratgie de configuration du systme de stockage a aussi pour effet de permettre
l'implmentation de systmes de stockage multiples, disposant chacun de paramtres de
configuration propres, ce qui ouvre la possibilit de disposer en mme temps d'un systme de
stockage embarqu et d'un systme de stockage distant. Cette possibilit de configuration permet
32
par ailleurs de se passer du paramtre de configuration des instances du sitemap Cocoon.

Au niveau du fonctionnement, le fichier de configuration permet de dclarer un systme de
stockage en lui associant un pilote de l'API xdb. Lors du dmarrage de Notix, l'API est initialise et
charge les pilotes dclars. Par la suite, chaque pilote peut interprter selon ses besoins le contenu
des lments de configuration restant.
Au dmarrage de Notix, les bases "Groupe" et "Utilisateur" sont cres automatiquement sur
l'instance par dfaut notix. Afin d'encapsuler ce comportement, un paramtre de configuration des
instances permet de dsigner une instance par dfaut, qui sera utilise pour la cration automatique
des bases. La base par dfaut est la base interroge lors de l'omission de la base dans la composition
de l'URL d'une ressource.
L'exemple suivant prsente la configuration de 4 instances eXist utilisant 3 bases eXist
diffrentes et 3 dispositifs de communication: REST, XMLDB embarqu, et XMLDB distant.
<xdb-config>

<xdb-system class="XdbRestExist" url="172.16.33.40:8088">
<xdb-instance name="notix" user="admin" pass="admin"
default="default"/>
</xdb-system>

<xdb-system class="XdbXmldbExistStdl" url="172.16.33.40:8099">
<xdb-instance name="instance2" user="admin" pass="admin">
<xdb-parameter name="create-database">true</xdbparameter>
<xdb-parameter
name="configuration">/home/xmldb/instance2.xml</xdb-parameter>
<xdb-parameter name="database-id">instance2</xdbparameter>
</xdb-instance>
</xdb-system>

<xdb-system class="XdbXmldbExistEmbd" url="embedded">
33
<xdb-parameter name="configuration">/home/notix/WEBINF/xmldb/instance3.xml</xdb-parameter>
</xdb-instance>
<xdb-parameter name="configuration">/home/notix/WEBINF/xmldb/instance4.xml</xdb-parameter>
</xdb-instance>
</xdb-system>
</xdb-config>
4.1.2 Augmenter la lisibilit du dispositif d'accs aux ressources XML

4.1.2.1 Une utilisation plus simple des URL d'accs aux ressources
La mise en place d'un processus plus simple de gestion des URL des ressources XML
rpond aux besoins de simplification du mcanisme de composition des URL, d'amlioration de la
lisibilit de l'application, et d'une sparation claire entre les logiques de communication avec le
systme de stockage et les logiques de traitement de Notix.
La simplification de l'utilisation des URL des ressources est permise par l'utilisation de l'API
xdb. L'emploi des chemins gnriques pour accder aux ressources permet d'encapsuler la logique
concrte de composition des chemins, et permet dans le mme temps d'encapsuler la gestion des
instances et le stockage de la liste des bases de donnes documentaires de Notix.
L'accs aux ressources ne ncessite que le nom de la base, l'identifiant du document, et un
contexte, qui permettent de dduire sans traitements supplmentaires les URI gnriques de l'API
xdb, rendant inutiles l'usage de l'action Cocoon XMLDBURL.
Par exemple, le pipeline suivant:
<map:match pattern="*/schema*">
<map:act type="xsp" src="xsp/xmldbURL.xsp">
<map:generate src="{collection}_{base}.rdfs"/>
34
est simplifi par:

<map:match pattern="*/schema*">
<map:generate src="xdb:{1}/_{1}.rdfs"/>
De la mme manire:
<map:match pattern="Utilisateur/*.xml">
<map:select type="simple">
<map:parameter name="value" value="{global:exist-url}"/>
<map:when test="">
<map:generate src="xmldb:notix:///db/Utilisateur/
{1}.xml"/>
</map:when>
<map:otherwise>
<map:generate src="xmldb:notix://{global:exist-url}/
notix/xmlrpc/db/Utilisateur/{1}.xml"/>
</map:otherwise>
</map:select>
s'crit dsormais:
<map:match pattern="Utilisateur/*.xml">
<map:generate src="xdb:Utilisateur/{1}.xml"/>
4.1.2.2 Une syntaxe alternative en langage java
La disponibilit d'une syntaxe java (alternative l'utilisation d'une source Cocoon) pour les
communications avec le systme de stockage des notices rpond aux besoins de raliser des
oprations complexes, d'accrotre la lisibilit gnrale des scripts de Notix, et d'encapsuler certains
traitements de Notix pour faciliter l'implmentation des volutions du standard XQuery.
La syntaxe java d'accs une ressource XML suit le mme schma que les patrons d'URL
gnriques, en distinguant l'accs par base documentaire de l'accs sur l'instance par dfaut. La
syntaxe est la suivante:
XdbManager xdbm = new XdbManager("Unebase");
Document doc = xdbm.getXml("Unebase-0000001.xml");
Le format d'change de l'API xdb est DOM, car la majorit des besoins d'accder des
documents XML dans les scripts correspond la ncessit de raliser des traitements dans ce
format. Nanmoins, des mthodes permettent de disposer du contenu d'un document en SAX, sous
35
forme de flux (InputStream), ou encore de chanes de caractres. L'implmentation de ces

oprations dans l'API xdb permet d'unifier les mthodes de conversion employes et d'optimiser les
traitements ncessaires en fonction du mode de communication ou du systme de stockage concret.
La classe XdbManager fournit galement des mthodes pour la plupart des oprations sur le
systme de stockage ralis dans Notix comme lister des collections ou des ressources dans une
collection, et les oprations de mise jour et d'effacement d'un document.
L'implmentation des oprations xcutant des requtes XQuery dans les pilotes de systmes
de stockage est justifie par les diffrences existantes d'implmentations du standard dans les
diffrents systmes de stockage XML. L'encapsulation des requtes XQuery permet par ailleurs de
ne pas exclure dfinitivement la possibilit d'utiliser des requtes SQL/XML si la technologie
devenait pertinente pour une utilisation dans Notix.
La liste des oprations courantes disponibles avec la syntaxe java est la suivante:
public Document getXml(String chemin)
public void getXmlAsSAX(String chemin, ContentHandler handler)
public InputStream getXmlAsInputStream(String chemin)
public void putXml(String chemin)
public void deleteXml(String chemin)
void xqueryFavori(String chemin, String query, String ajouter,

String supprimer, String effacer, String utilisateur, String
lucene, Integer count, String favori)
public void xqueryFormat(String chemin, String action, String type,

String name, String newName, String csv, String utilisateur)
public ArrayList<String> xqueryLot(String chemin, String

replaceHref, String property, String replace, String search, String
idCsv, String champ_utilisateur,String champ_modification, String
dateModif, String utilisateur)
public ArrayList<String> xqueryLotCount(String chemin, String

search, String property)
public java.util.Collection<String> listResources(String chemin)
public java.util.Collection<String> listResourcesSorted(String

chemin)
public java.util.Collection<String> listCollections(String chemin)
4.1.2.3 Un dispositif simplifi de gestion des bases documentaires
L'implmentation d'un dispositif simplifi de gestion des bases documentaires rpond aux
besoins de simplifier les scripts de Notix, et d'encapsuler les variations entre les diffrents systmes
36
de stockage.
Le dispositif simplifi de gestion des bases documentaires est un ensemble de mthodes
permettant la cration de bases partir de la syntaxe java. Les principales mthodes sont les
suivantes:
Une mthode de cration de base documentaire. Cette mthode est disponible sans
cration d'instance de l'objet XdbManager.
XdbManager.createDb(NomInstance, Nombase, documentRdfs)
Une mthode de suppression d'une base documentaire. Cette mthode n'efface pas les
index de la base cible, mais supprime simplement le fichier RDFS, conformment au
comportement actuel de Notix.
new XdbManger(Nombase).removeDb()
Un ensemble de mthodes globales permettant d'obtenir des informations sur les bases et
les instances:
XdbManager.getNotixBaseList() // permet d'obtenir une listes des bases

documentaires de Notix
XdbManager.getNotixBaseDefinition() // permet d'obtenir une liste des
caractristiques d'une base
XdbManager.getNotixInstanceList() // permet d'obtenir une liste des
instances configures
Le dispositif simplifi de gestion des bases documentaires excute automatiquement la

rinitialisation de la liste des bases. Cette fonctionnalit permet de soulager les scripts de Notix,
et d'ancrer ces enchanements d'oprations dans l'API pour qu'ils ne soient plus soumis l'erreur.
4.1.3 Factoriser les oprations redondantes

La cration d'une bibliothque java pour regrouper les oprations de conversion de format
est une rponse aux besoins de limiter la rptition des algorithmes redondants dans les scripts, et
d'instaurer une stratgie unique pour chaque opration de conversion, afin d'viter les erreurs et de
faciliter la maintenance de l'application.
Les mthodes contenues dans la bibliothque sont les suivantes:
37
public static Document string2Dom(String s)

public static String dom2String(Document document)
public static InputStream string2InputStream(String string)
public static String inputStream2String (InputStream in)
L'utilisation de mthodes globales java pour accder aux mthodes de conversion permet
leur emploi indistinctement dans l'API xdb, dans les scripts serverpages et les flowscript de Notix.
La mise en place de la bibliothque java pour les oprations de conversion constitue une initiative
d'optimisation des algorithmes dans Notix. A ce titre, la bibliothque constitue un prcdent qui
pourra tre potentiellement reproduit pour d'autres algorithmes de l'application.
4.1.4 Implmentation de HTTP/REST

Le choix d'implmenter une interface HTTP/REST, alors que l'API xdb rend mineurs les
inconvnients lis l'utilisation de l'API XMLDB, correspond une volont de disposer d'une
interface prenne, stable, et standard vers eXist.
La principale motivation pour l'implmentation de HTTP/REST est d'anticiper un abandon
possible de l'API XMLDB par la communaut eXist. L'absence d'activit autour de l'API XMLDB,
et la monte en popularit de l'API XQJ permettent d'envisager ce scnario.
L'implmentation de REST constitue donc d'abord l'assurance de disposer d'une stratgie de
communication pour laquelle le support de la communaut eXist semble prenne.
En second lieu, l'implmentation de HTTP/REST a t choisie pour sa simplicit, sa clart,

et son potentiel de rutilisation.
Le principe de REST consiste employer les verbes HTTP sur une ressource dsigne par
une URL. Les verbes HTTP (GET, PUT, POST, DELETE, HEAD) couvrent les oprations de base
ncessaires la gestion des documents et offre la possibilit d'envoyer des requtes XQuery avec le
verbe POST. A la suite d'une requte, le serveur HTTP renvoie une rponse sous la forme d'un code
HTTP. Par exemple 201:Created; 401:Unauthorize.
L'implmentation d'une interface HTTP/REST consiste donc essentiellement manipuler un
client HTTP, ce qui assure sa simplicit.
38
4.2 L'API xdb

4.2.1 Le patron de conception "stratgie", pour l'implmentation de
nouveaux pilotes
Le patron de conception stratgie consiste "dfinir une famille d'algorithmes, encapsuler
chacun d'eux, et les rendre interchangeable. [Le patron de conception] permet l'algorithme de
varier indpendamment des clients qui l'utilisent"13.
Pour l'API xdb, la famille d'algorithmes cre est celle des pilotes concrets des systmes de
stockage. Lorsqu'une requte est effectue via la classe XdbManger, celle-ci charge le pilote
appropri et confie la ralisation de l'opration demande ce pilote.
Chargement du pilote l'instanciation de la classe XdbManager:
public XdbManager(String base){
//Recherche de la base dans NotixBaseList
TreeMap<String, String> baseMap =
XdbManager.notixBaseList.get(base);
// Initialisation des paramtres de classe
this.base=base;
this.instance=baseMap.get("instance");
this.url=baseMap.get("url");
this.user=baseMap.get("user");
this.pass=baseMap.get("pass");
this.classe=baseMap.get("class");
// Chargement du pilote appropri
this.xdb = getXdb(this.classe, instance, url, this.user,
this.pass);
}
Excution d'une requte:

public Document getXml(String chemin){
return xdb.getDoc(this.instance, this.base, chemin);
}
4.2.2 Une hirarchie de classes qui favorise l'utilisation des standards

Chaque pilote concret de systme de stockage hrite de la classe abstraite xdb. Pour
13
Eric Freeman, Elisabeth Freeman, 2005. Design Patterns Tte la premire. Paris : Editions O'Reilly. 644p.
(page 24)
39
l'implmentation des pilotes une logique d'hritage a t adopte qui permet de favoriser la
rutilisation des mthodes des interfaces de communication indpendamment du systme de
stockage qui les implmente.
Cette hirarchie de classes a pour objectif de favoriser au maximum la rutilisation du code
en exploitant la gnricit des API et des dispositifs de communication.
Pour l'implmentation de HTTP/REST, l'excution des mthodes gnriques du client HTTP
est implmente dans une classe XdbRest hritant de la classe Xdb. A un niveau infrieur, la classe
XdbRestExist hrite de la classe XdbRest et implmente toutes les mthodes spcifiques eXist,
comme par exemple la composition des requtes XQuery, et la composition des chemins d'accs
concrets aux ressources.
Pour l'implmentation de l'API XMLDB, le mme dispositif a t mis en place avec une
premire classe d'hritage XdbXmldb qui se limite l'excution des oprations standards de l'API,
recommandes par la XML:db initiative. Pour l'API XMLDB, un troisime niveau a cependant t
ajout sous la classe XdbXmldbExist (qui hrite de XdbXmldb). Il s'agit de l'implmentation des
deux pilotes pour accder un eXist distant et un eXist embarqu. Les deux pilotes ne se
distinguent que par leurs mcanismes de composition des URL d'accs aux documents. Les deux
classes hritent donc des mmes classes parentes, et se contentent de redfinir la composition des
URL.
Illustration 7: Diagramme descriptif de la hirarchie de classe de l'API xdb
40
4.2.3 Le dispositif de configuration et de chargement des pilotes

L'ensemble des lments de configuration des systmes de stockage se trouve dans le fichier
"XDBConfig.xml". Au dmarrage de Notix l'API xdb est initialise par l'appel de la mthode
globale "XdbManager.initDbs()". L'excution de cette mthode produit les actions suivantes :
Le fichier de configuration XDBConfig.xml est charg en mmoire sous la forme d'un

document DOM. Le document est pars, et pour chaque instance configure les
oprations suivantes sont ralises :
Le nom de l'instance est ajout la liste globale des instances notixInstanceList.
Le nom du pilote dclar dans le fichier de configuration est recueilli et utilis

pour instancier le pilote.
Xdb xdbImpl=null;
/* L'utilisation de Class.forName() permet d'utiliser directement le
nom des classes dans le fichier de configuration*/
try{
Class classe = Class.forName
("fr.gouv.equipement.documentation.xdb.databases."+nomClasse);
java.lang.reflect.Constructor constructeur =
classe.getConstructor(new Class [] {Class.forName("java.lang.String"),
Class.forName("java.lang.String"), Class.forName ("java.lang.String"),
Class.forName("java.lang.String")});
xdbImpl = (Xdb)constructeur.newInstance (new Object []
{instance, url, user, pass});
}catch (Exception e) {
System.out.println("Erreur lors de la tentative de
charger la classe \""+nomClasse+"\" (implmentation de Xdb)");
}
Une instruction d'initialisation de la base de donnes est envoye au pilote avec

les paramtres de configuration de la base (les lments "xdb-parameter").
NodeList xdbInstanceParameters =
xdbInstance.getElementsByTagName("xdb-parameter");
// On recueil les paramtres de configuration de l'instance
for
(int k = 0; k < xdbInstanceParameters.getLength(); k++) {
41
Element xdbInstanceParameter =
((Element)xdbInstanceParameters.item(k));
properties.setProperty(
xdbInstanceParameter.getAttribute( "name"),
xdbInstanceParameter.getFirstChild().getNodeValue() );
}
// On initialise les bases
xdbImpl = getXdb(xdbClass, instName, xdbUrl, instUser, instPass);
// On dmarre les instances avec leurs paramtres
xdbImpl.initInstance(properties);
Une instruction est envoye au pilote pour obtenir la liste des bases
documentaires prsentes dans l'instance. Chaque base renvoye est stocke dans
la liste des bases documentaires notixBaseList avec ses donnes d'identification,
l'instance laquelle elle appartient, et le pilote ncessaire son accs.
La mthode d'initialisation des bases est excute au dmarrage de l'application, la cration

d'une base documentaire, et la suppression d'une base documentaire.
4.2.4 Le mcanisme de composition des URL

Le mcanisme de composition des URL de l'API xdb repose sur 3 lments, le fichier de
configuration XDBConfig.xml qui permet la configuration des instances, le dispositif de
chargement du pilote concret du systme de stockage, et enfin la mthode concrte de composition
du chemin.
Lorsqu'une requte est adresse la classe XdbManager, celle-ci rcupre le nom de la base
et charge le pilote appropri. Une fois le pilote charg, les information suivantes, issues du fichier
de configuration, lui sont envoyes : le nom de l'instance, le nom de la base, le chemin, et les
informations spcifiques l'opration en cours (par exemple un document DOM pour un
enregistrement).
Exemple :
new XdbManager("Unebase").getXml("Unebase-0000001.xml")
Appel le pilote concret avec:

xdb.getDoc("Uneinstance", "Unebase", "Unebase-0000001.xml");
Une fois les informations en sa possession, le pilote concret transforme la requte envoye
42
selon les patrons d'URL qui lui conviennent en appelant des mthodes internes. Ci-dessous le
mcanisme employ par le pilote HTTP/REST pour construire les chemins :
protected String composePath(String instance, String base, String chemin) {
String collection="/rest/db/";
if (base == null || base.equals("")) {
//ne fait rien
} else {
collection = collection + base + "/";
}
// Si on cherche accder une resource
if (chemin.endsWith(".xml")||chemin.endsWith(".rng")||chemin.endsWith(".rdfs")){
// Si on cherche accder une notice
if (chemin.matches(base+"-[0-9]{7}?\\.xml")){
//On ajoute les sous-collections spcifiques eXist +la
resource
collection = collection + chemin.substring(base.length()
+1,base.length()+5) + "/" + chemin;
}else if (chemin.startsWith("non-valides")) {
collection = collection + "_alix/notices-rejetees/nonvalides" +
"/" + chemin.substring(12);
} else if (chemin.startsWith("doublons")) {
collection = collection + "_alix/notices-
rejetees/doublons" + "/"
+ chemin.substring(9);
} else if (chemin.startsWith("rapports")) {
collection = collection + "_alix/rapports" + "/" +
chemin.substring(9);
}else {
//Pour les autres documents on recopie les sous-collections et la
resource.
collection = collection + chemin;
}
}else{
//Sinon on accde une collection: on recopie le chemin
if ( chemin !=null && !chemin.equals("") ){
collection = collection + chemin + "/";
//Sauf si il est vide
} else {
//Ne fait rien
}
}
return "http://"+serveur+ "/" + instance + collection;
}
L'API XMLDB, la diffrence de REST , ncessite la dsignation d'une collection avant

d'atteindre une ressource. La composition du chemin s'excute donc en deux temps avec
getResource() puis seulement dans un second temps composePath().
43
4.3 Intgration Cocoon

4.3.1 L'utilisation d'un pilote unique, la classe XDBSource
Pour permettre une meilleure intgration Cocoon, une source Cocoon a t dveloppe.
Les classes XdbSourceFactory et XdbSource sont dclares dans le fichier cocoon.xconf et
permettent de raliser une requte vers l'API xdb sous la forme d'une URL commenant par le
protocole "xdb:".
Le fonctionnement de la Fabrique de Source Cocoon XdbSourceFactory consiste analyser
l'URL et diviser les diffrentes parties logiques (la base, le chemin) pour les soumettre la Source
qui s'occupera alors d'excuter la requte dans l'API xdb via la syntaxe java.
Extrait de XdbSourceFactory:
//url du type xdb:{base}/{path}
int start = location.indexOf(':');
int end = location.indexOf('/');
base = location.substring(start+1, end);
path = location.substring(end+1);
return new XDBSource(this.getLogger(), base, path, location);
L'intrt de dvelopper une source Cocoon, en dehors des commodits apportes par les
URL d'accs aux ressources, est la possibilit d'exploiter le systme de mise en cache Cocoon. Pour
exploiter le mcanisme de mise en cache d'une source Cocoon, celle-ci doit implmenter la mthode
getValidity() qui renvoie la date de dernire modification d'un document.
public SourceValidity getValidity() {
return new TimeStampValidity((this.getLastModified()));
}
public long getLastModified() {
long result=0;
xdbm.getLastModificationTime(path).getTime();
return result;
}
Le systme de mise en cache des sources Cocoon ne fonctionne cependant que lorsque la source est
appele depuis un composant de sitemap (par exemple FileGenerator).
44
4.3.2 La mise en place d'un systme de cache

Pour conserver un niveau de performance satisfaisant lors des accs aux documents, Cocoon
emploie un systme de cache. Il existe nanmoins une contrainte qui est que ce dispositif n'est
effectif que dans les pipelines du sitemap, et qu'il ne peut donc pas tre utilis dans les scripts de
l'application.
Afin de pallier ce manque, l'API xdb dispose d'un systme de mise en cache des gabarits
RDFS. La fonctionnalit de mise en cache est utilise uniquement pour les gabarits RDFS, d'abord
parce que ceux-ci sont trs souvent sollicits dans le fonctionnement de Notix, ensuite parce qu'ils
sont peu nombreux (un par base).
public Document getXml(String chemin){
Document doc=null;
/* Pour la rcupration des document rdfs en cache, on Procde en 3 tapes:
* - On vrifie d'abord si le fichier demand est un rdfs
* - On vrifie ensuite si la base demande existe
* - On vrifie enfin si la date de modification du rdfs en base est jour par
rapport au rdfs stock
*/
if(chemin.equals("_"+this.base+".rdfs") ){
//Si un rdfs est prsent en cache
45
if(notixBaseRdfs.get(this.base)!=null &&
notixBaseRdfsLastMod.get(this.base).equals(this.getLastModificationTime(chemin).getTime(
))){
// L'enregistrement des documents en cache est ralis chaque
appel d'un document rdfs en base.
return notixBaseRdfs.get(this.base);
}else{
doc= xdb.getDoc(this.instance, this.base, chemin);
if (doc != null){
notixBaseRdfsLastMod.put(this.base,
this.getLastModificationTime(chemin).getTime());
notixBaseRdfs.put(this.base, doc);
}
return doc;
}
} else {
return xdb.getDoc(this.instance, this.base, chemin);
}
}
Le systme de mise en cache est implment directement dans la classe xdbManager. Le

premier accs au gabarit RDFS d'une base provoque l'enregistrement du document au format DOM
et de la date de dernire modification de ce document dans une variable globale de l'application. A
chaque nouvel appel du gabarit la classe xdbManager envoie une requte au systme de stockage
qui contient le document pour connatre la date de dernire modification du gabarit. Si cette date est
diffrente de celle dont il dispose en mmoire, xdbManager transmettra la requte au systme de
stockage, sinon le document en mmoire est envoy en rponse.
46
4.4 Les tests unitaires

Pour diriger le dveloppement de l'API xdb, un ensemble de tests unitaires a t cr. Ils
permettent de tester la majorit des fonctionnalits de la classe xdbManager pour chaque pilote
existant.
Les tests unitaires sont intgrs l'API xdb, et sont amens voluer avec celle-ci. De
manire gnrale, l'emploi des tests unitaires a permis de mieux contrler le processus de
conception de l'API.
Extrait:
@Test
public void testInitXDBs() {
XdbManager.resetStatics();
assertTrue("Initialisation des base", XdbManager.getNotixBaseList()==null );
XdbManager.initXDBs();
assertTrue("Initialisation des base", XdbManager.getNotixBaseList()!=null );
}
@Test
public void testCreateDb() {
XdbManager.createDb("notix", "Testbaserest2", domrdfsTestbaserest2);
XdbManager.createDb("instancenotix", "Testbaserest3", domrdfsTestbaserest3);
XdbManager.createDb("testinstance", "Testbasexmldb", domrdfsTestbasexmldb);
XdbManager xdbm = new XdbManager("Testbaserest2");
assertTrue("rdfs isDocument", xdbm.getXml("_Testbaserest2.rdfs") instanceof
Document);
XdbManager xdbm2 = new XdbManager("Testbasexmldb");
assertTrue("rdfs isDocument", xdbm2.getXml("_Testbasexmldb.rdfs") instanceof
Document);
XdbManager xdbm3 = new XdbManager("Testbaserest3");
assertTrue("rdfs isDocument", xdbm3.getXml("_Testbaserest3.rdfs") instanceof
Document);
}
@Test
public void testGetXml() {
XdbManager xdbm = new XdbManager("Testbaserest2");
assertTrue("rdfs isDocument", xdbm.getXml("_Testbaserest2.rdfs") instanceof
Document);
XdbManager xdbm2 = new XdbManager("Testbasexmldb");
assertTrue("rdfs isDocument", xdbm2.getXml("_Testbasexmldb.rdfs") instanceof
Document);
}
47
4.5 Limites du dveloppement de l'API xdb.

La cration de l'API xdb s'est droule dans la dernire partie de mon stage, et
l'implmentation dans Notix n'tait pas totalement acheve la fin du temps de la mission.
Deux tches notamment ont t envisages sans avoir pu tre accomplies :
Les tests de monte en charge et de performance. Le recours l'API xdb provoque de

nombreuses crations d'instances des pilotes de base de donnes potentiellement
coteuses en mmoire. La ralisation de tests de performance, et l'analyse de la
consommation des ressources de l'application lors de la monte en charge permettrait
d'valuer la pertinence du dispositif actuel et le besoin ventuel d'une gestion plus fine
de la cration des instances de pilotes.
Un dernier cycle de dveloppement ddi l'optimisation du code. Par exemple, l'API

pourrait bnficier de la cration d'une classe d'exceptions ddie.
48
Conclusion:
La mission que j'ai effectue au PANDoc consistait tudier les alternatives envisageables
au systme de stockage XML de Notix. En vue d'amliorer potentiellement les performances
gnrales de l'application.
L'tude de l'offre dans le domaine des solutions de stockage des documents XML d'une part,
et l'analyse de l'utilisation de la base de donnes eXist d'autre part, m'ont progressivement amen
raliser l'valuation des capacits d'volution de Notix dans son mode de gestion des documents
XML.
Le manque de certitudes sur la prennit de l'API XMLDB, et la dpendance existante entre
la base de donnes XML eXist et le reste des composants de Notix, ont justifi le lancement d'un
processus de conception dans Notix d'un dispositif de gestion des documents XML plus gnrique,
et capable d'voluer.
un niveau personnel, ce stage m'a permis de mettre en application en milieu professionnel

une grande partie des enseignements que j'ai reu lors du Master 2 ID.
49
Bibliographie:
Ronald Bourret, 2005. XML and Databases[En ligne]. [Consult en aot 2008].
http://www.rpbourret.com/xml/XMLAndDatabases.htm
Eric Freeman, Elisabeth Freeman, 2005. Design Patterns Tte la premire. Paris : Editions
O'Reilly. 644p.
50
Annexes
ANNEXE 1 : Architecture de Notix...................................................................................................52
ANNEXE 2: Traitement d'un document XML dans un script serverpages........................................53
ANNEXE 3: tude des systmes de stockage XML..........................................................................56
ANNEXE 4: tude des besoins..........................................................................................................69
51
ANNEXE 1 : Architecture de Notix
52
ANNEXE 2: Traitement d'un document XML dans un script

serverpages
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="../../transform/xmldoc/xmldoc.xsl"?>
<xsp:page
language="java"
xmlns:xsp="http://apache.org/xsp"
xmlns:sdx="http://www.culture.gouv.fr/ns/sdx/sdx"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
>
<xsp:structure>
<xsp:include>org.exist.cocoon.XMLDBSource</xsp:include>
<xsp:include>org.w3c.dom.Document</xsp:include>
<xsp:include>org.w3c.dom.Element</xsp:include>
<xsp:include>org.w3c.dom.NodeList</xsp:include>
</xsp:structure>
<xsp:logic>
/* Une mthode pratique pour afficher de l'info sur une exception */

private void toSAX(Exception e) throws ProcessingException, SAXException {
java.io.StringWriter sw = new java.io.StringWriter();
java.io.PrintWriter pw = new java.io.PrintWriter(sw);
e.printStackTrace(pw);
String message=sw.toString();
<div class="erreur"><xsp:expr>e</xsp:expr></div>
<pre class="erreur"><xsp:expr>sw</xsp:expr></pre>
}
public static Document string2dom(String xml)

throws javax.xml.parsers.ParserConfigurationException
, java.io.IOException
, org.xml.sax.SAXException
{
javax.xml.parsers.DocumentBuilderFactory dbf =
javax.xml.parsers.DocumentBuilderFactory.newInstance();
// ne pas oublier
dbf.setNamespaceAware(true);
javax.xml.parsers.DocumentBuilder
db = dbf.newDocumentBuilder();
return db.parse(new org.xml.sax.InputSource(new

java.io.StringReader(xml ) ) );
}
</xsp:logic>
<html>
53
<xsp:logic>
// Le nom de la liste
String name=parameters.getParameter("name", null);
// la source cocoon de laquelle tirer un doc
String url=parameters.getParameter("url", null);
XMLDBSource source=null;
// du DOM
Document doc=null;
Element el=null;
NodeList nl=null;
// si a plante ici, c'est que le paramtre est mal pass ct
sitemap
source=(XMLDBSource)resolver.resolveURI(url);
</xsp:logic>
<head>
<title>
<i18n:text i18n:catalogue="notix" key="listesedit.titre">Notix, Listes</i18n:text>
<xsp:expr>name</xsp:expr>
</title>
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8"/>
<script type="text/javascript"
src="../theme/js/suggest.js">//</script>
</head>
<body>
<a href="."><i18n:text>Listes</i18n:text></a> / <a
href=""><xsp:expr>name</xsp:expr></a>
<h1 id="title">
<small><i18n:text>Liste</i18n:text></small>
: <xsp:expr>name</xsp:expr>
</h1>
<xsp:logic>
try {
doc=org.apache.cocoon.components.source.SourceUtil.toDOM(source);
// l'implmentation DOM Exist pose problme dans
certains cas sur getElements
// doc=source.getContentAsDOM().getOwnerDocument();
} catch (Exception e) {
<div class="erreur">Erreur au chargement de la
liste <xsp:expr>name</xsp:expr></div>
toSAX(e);
}

if (request.getParameter("value") != null) {
String[]
values=request.getParameterValues("value");
String xml="";
54
xml +="<rng:choice
xmlns:rng=\"http://relaxng.org/ns/structure/1.0\">";
for (int i=0; i < values.length ; i++) {
xml +="\n\t<rng:value>" + values[i] +
"</rng:value>";
}
xml +="\n</rng:choice>";
try {
doc=string2dom(xml);
source.setContentAsDOM(doc);
} catch (Exception e) {
<div class="erreur">Problme dans
l'criture de la liste</div>
toSAX(e);
}
}
</xsp:logic>
etc.
</xsp:page>
55
ANNEXE 3: tude des systmes de stockage XML

1 Le stockage des donnes XML:
Trois grandes approches existent14:
les bases de donnes XML natives
les bases de donnes relationnelles (SGBDR) hybrides ou grant un type XML.
les bases de donnes relationnelles permettant de stocker des documents via un
mapping des donnes (XML-Enable) ( ou l'usage de middleware pour faire
le lien entre XML et SGBDRs)
{Porte de cet tat de l'art: Open-Source, multi-platformes, projets en activit}
1.1 Les bases de donnes XML natives:
1.1.1 - Caractristiques gnrales:
Les bases de donnes XML natives se distinguent des SGBDR par 3 caractristiques:
elles prservent la structure physique des documents (lments, attributs, entites, ...)
elles permettent de stocker des documents sans dclaration pralable du schma des documents.
elles permettent d'accder aux documents partir des API spcifiques XML (Xpath,
XQUERY).
Par ailleurs les bases de donnes XML natives permettent la cration de collections
( assimilables des dossiers dans un systme de fichier) .
API Java
Concernant les bases de donnes XML natives, un effort de normalisation a t fait sous la
forme d'une API Java xmldb , par la XML:DB Initiative . Actuellement le groupe de travail
sur ce pseudo protocole ne donne plus aucun signe de vie.
Les discussions autour de la JSR 225 XQJ, XQUERY API for Java semble constituer une
alternatives pour les concepteurs de bases de donnes XML native. Nanmoins l'implmentation
dans les solutions est loin d'tre gnralise ni aboutie.
Standard XML d'accs aux donnes
Pour la consultation des ressources stockes dans les bases de donnes XML natives, les
diffrentes solutions implmentent des standards W3C diffrents niveaux de conformit, ainsi que
des technologies d'accs propres. Les standards les plus couramment implments sont Xpath 1.0 et
XQUERY 1.0, suivis de Xpath 2.0, XQUF (XQUERY Update Facility, pour la mise jour des
donnes), XQFT (XQUERY FullText, pour la recherche en plein texte), et plus rarement
XQUERYD (D pour Distributed: interrogation de plusieurs bases distantes au sein de requtes
XQUERY).
L'implmentation de XQUERY dans les bases de donnes XML est test par la XQUERY
Test Suite (XQTS) du W3C.
14 http://www.rpbourret.com
56
Protocoles de communication
En termes d'intgration, des bases de donnes XML natives, il existe deux modes: les bases
de donnes embarques, et les bases de donnes fonctionnant sur le mode client-serveur; certaines
bases supportant les deux modes de fonctionnement. Pour les bases fonctionnant sur le mode clientserveur, diffrents protocoles de communication sont implments selon les bases de donnes, du
protocole binaire bas via la manipulation de socket, jusqu'aux protocoles orients services web:
SOAP, REST, XML-RPC, ... . noter l'engouement naissant pour le protocole de publication Atom
(APP), quivalent WebDav mais bas sur une architecture REST.
Organisation des ressources
La possibilit d'organiser les documents dans les bases de donnes XML natives varie selon
les solutions: on trouve la notion de base de donnes (unique ou multiple), de collection (unique,
multiple, emboitable), de document (comme unit, ou sous-arbre d'un unique document). Mme
un niveau logique, la cration de collections imbriques n'est pas toujours possible.
1.1.2 Solutions existantes:
Les bases de donnes XML natives cartes:
OrientX (Dveloppe uniquement pour Windows)
Xbird (Solutions non disponible)
Les principales bases de donnes XML natives actives open sources sont les suivantes:
eXist ( http://exist.sourceforge.net/ )
Berkeley DB XML (http://www.oracle.com/technology/products/berkeley-db/xml/index.html )
Xindice ( http://xml.apache.org/xindice/ )
ressources: http://www.ibm.com/developerworks/web/library/wa-xindice.html
BaseX ( http://www.inf.uni-konstanz.de/dbis/basex/ )
Sedna ( http://modis.ispras.ru/sedna/index.htm )
MonetDB/XQUERY ( http://monetdb.cwi.nl/projects/monetdb/XQUERY/index.html )
1.2 Description des solutions:
1.2.1 Exist
Exist a t cr en 2000 par Wolfgang Meier, sur la base d'articles scientifiques dcrivant
des algorithmes performants d'accs aux donnes. Exist est crit en Java. D'abord conu pour l'accs
aux documents( Documentcentric ) la base de donnes XML native se spcialise progressivement
dans l'accs aux donnes ( Data centric ). Actuellement eXist est en version 1.2, et est distribu
sous licence LGPL.
La solution implmente l'API Java XML:DB, et dveloppe actuellement le support de l'API
XQJ.
La solution implmente les standards XML XQUERY 1.0, Xpath 1.0 et 2.0, et XQUERYFT.
Pour la ralisation des mises jour, eXist fait appel XUPDATE, et une extension d'XQUERY en
cours de mise en conformit avec XQUF.
57
Un des point forts d'eXist rside dans la forte activit de sa communaut. La liste de
diffusion est trs active, au moins huit dveloppeurs travaillent rgulirement sur le projet, et la
documentation est exhaustive, et croissante.
eXist fonctionne aussi bien en mode serveur qu'en mode embarqu. Il dispose par ailleurs de
trois modes d'administration, un client java, une administration en ligne de commande, et une
interface web.
1.2.2 Berkeley DB XML
Berkeley DB XML est une base de donnes XML native crite en C. Elle est distribue sous
2 licenses, une libre et une commerciale. Le Produit Berkeley DB XML dvelopp par SleepyCat
t acquis en mme temps que la socit par Oracle en 2006. Le produit est bas sur Berkeley DB,
une base de donne entit-valeur embarque. La version actuelle datant de janvier 2007 est la
2.3.10. La version 2.4 en version bta devrait sortir bientt.
Plusieurs API ont t dveloppes pour permettre l'accs Berkeley DB XML: PHP,
Ruby, .NET, Java, TCL, Ruby, Perl, Python, module apache.
Pour l'accs aux donnes XML, BDBXML implmente xpath 2.0 et XQUERY 1.0, ainsi
qu'un protocole propre de mise jour des donnes dbxml. Pour la version 2.4 venir, la solution
implmentera XQUF, et plus tard sans doute XQJ. Cependant Xml:db API ne sera pas implment
car ne prenant pas en compte la gestion des transactions.
L'activit de la communaut se manifeste par le dveloppement d'APIs et les discussions sur
le Forum, mais le dveloppement de l'application n'est pas ouvert la communaut.
Il existe une version client-serveur de la solution, dveloppe par la communaut sous le
nom de NXQD (Native XMLDB Query Daemon), qui permet d'accder la base via SOAP. Le
projet semble nanmoins peu actif, puisque la dernire version date du 02-09-2006 (
http://sourceforge.net/projects/nxqd ).
1.2.3 Xindice
Xindice est un projet Apache crit en java. Le projet est la reprise de DbXML dont le code
source a t donn la fondation Apache en 2001. Actuellement la solution est en version 1.1.
Xindice est optimis pour la gestion des petits et moyens documents (pour une taille
maximale de 6Mo). La solution permet de grer des hirarchies de collections.
La solution met disposition deux API: XML:DB et Xindice XML-RPC API.
L'implmentation des standards XML pour l'accs aux donnes fait partie des points noirs de
Xindice. La solution implmente Xpath, mais pas XQUERY.
Xindice fonctionne aussi bien en mode embarqu qu'en mode serveur (sous la forme d'une
application web). En mode serveur, les communications client-serveurs sont vhicules par XMLRPC.
La communaut de Xindice semble avoir t importante mais les signes de vie du projet sont
58
rares (la dernire publication sur le site date de aot 2007). La documentation est nanmoins
utilisable et dtaill.
1.2.4 BaseX
BaseX est dvelopp par le Database and Information System Group de l'Universit de
Konstanz en Allemagne. La base de donne xml native est dveloppe en Java. Rcemment, BaseX
a t tudi comme base pour la cration d'un systme de fichier XML, par l'quipe de recherche
DISGUK. BaseX est mis disposition sous licence BSD.
La spcificit de BaseX repose sur son stockage des collections et documents dans un
unique document XML. L'accs aux collections est possible via XQUERY 1.0 et Xpath 1.0, ou par
des fonctions XQUERY de la solution.
En termes de performance, BaseX a optimis Xpath pour tirer au mieux parti des index de la
base de donne. En revanche, XQUERY ne bnficie pas de ces optimisation, et le seul objectif de
l'quipe pour le moment est la conformit au modle du langage de requte (XQTS). XQUERY
n'est donc pas conseill en production.
BaseX dispose d'un outil d'administration graphique des donnes, dont le principal atout est
la multitudes de modes de visualisation. Un outil d'administration en ligne de commande existe
aussi.
1.2.5 Sedna
Sedna est une base de donne XML native conue par une quipe de recherche Russe, le
MODIS (Management Of Data & Information Systems ), du dpartement de l' ISP RAS (Institute
for System Programming of the Russian Academy of Sciences). La solution a t dvelopp partir
de 2003. La dernire version date d'octobre 2007(v 2.2).
La solution Sedna est dveloppe en C/C++, mais des API ont t crites pour Java, Python,
PHP, C, .NET, Scheme. On compte aussi un module apache et l'implmentation de xmldb de
XML:DB Initiative. Par ailleurs 2 modules d'administration graphiques existent.
La solution est organise en une srie de fichiers binaires, dont des fichiers pour la cration
et pour la suppression d'une base de donnes, ce qui semble problmatique pour certains usages.
L'accs aux donnes XML est possible via XQUERY. La base de donne implmente son
propre systme de mise jour des documents XML.
Le projet est gr entirement par l'quipe d'origine, et il n'y a pas de contributeurs
extrieurs pour le coeur de la solution. Par contre, les API sont produites par la communaut. Il
existe une liste de diffusion active mais peu fournie.
Il n'y a aucune information sur les perspectives du projet, mais l'quipe continue d'exploiter
Sedna pour un projet de Content and Knowledge Management Framework15 .
1.2.6 MonetDB/XQUERY
15 http://modis.ispras.ru/projects.html
59
MonetDB est une base de donnes relationnelle. Une version de la base de donnes intgrant
les middlewares path-finder (Traducteur de requte XQUERY vers SQL) et pf/Tijah (moteur de
recherche Plein texte), a t cre pour obtenir une base de donne XML Native, nomme
MonetDB/XQUERY. MonetDB/XQUERY est dvelopp en C et en python. La solution est
distribue sous licence MonetDB Public licence Version 1.1 qui est drive de la licence
Mozilla.
MonetDB/XQUERY implmente les collections, mais pas les hirarchies de collection.
L''implmentation des collections est limite un mode read-only, ou updatable (avec rservation
d'espace la cration). On peut intrroger les ressources via Xpath et XQUERY (en partie
implment), raliser les mises jour via XQUF, et raliser des recherches en plein textes via un
driv de XQFT.
Pour la communication entre le client et le serveur, MonetDB/XQUERY dispose d'un client
en ligne de commande et d'une interface web. Les requtes XQUERY vers le serveur peuvent tre
faites via la ligne de commande, ou via le protocole d'accs SOAP. Dans les enveloppes SOAP, un
protocole xrpc permet de faire des requtes XQUERY distribues (cf. XQUERYD).
eXist
BDB
Xindice
BaseX
Sedna
MonetDB/
XML
XQUERY
Informations
gnrales:
- version
1.2
2.3
- License
GNU
LGPL
- Origine du
projet
Fond par Berkeley

Wolfgang DB (BDB)
Meier en
2000.
- Langage de Java
dveloppeme
nt
- Systme
Oracle
libre
(certifi
OSI)
C/C++
MultiUNIX,
Platformes Win32
1.1
4.0
2.2
Monet4/X
QUERY
0.22
Apache
2.0
MonetDB
Public
licence
Version
1.1 (driv
Mozilla)
Apache
2.0
BSD
Projet
dbXML
donn la
fondation
Apache en
2001
DISG
http://mod MonetDB
(Universit is.ispras.ru
y of
/
http://ww
Konstanz )
w.cwi.nl/
Java
Java
C/C++
C, Python
MultiMultiLinux,
Linux,
Platformes Platformes Windows, Windows,
mod_Apac (32/64)
he
Logiciel
Libre:
- Utilisateurs
***
***
**
**
**
60
eXist
BDB
XML
Xindice
BaseX
Sedna
MonetDB/
XQUERY
Communaut
***
**
***
***
Documentati
on
***
***
***
**
**
- Activit
***
***
**
***
***
- Maturit
***
***
***
**
**
***
- Actualit
***
***
**
**
**
***
Communaut
:
APIs :
- xml:db API oui
non
Oui
Non
Oui
Non
- XQJ (JSR
225)
(en
non
dveloppe
ment)
Non
Non
non
Non
- autres
Non
API Java Non

Java
API:dbxm
l
(quivalen
t xmldb
+ gestion
des
transaction
s), Ruby,
PHP,
.NET
- XUPDATE Oui
(xml:db)
Oui
API Java. Php,

python,
.net,
Scheme,
socketbase
client/serv
er protocol
XRPC(jav
a/javascrip
t), CGI
binding
(.xq),
MAPI
99.3%
(XQTS)
98.8%
(XQTS )
En partie
Oui (1,2)
En partie
Non
(autre)
Oui
Requtes:
- XQUERY
99.4%
(XQTS)
99.5%
(XQTS)
Non
- XPath
Oui(1,2)
Oui (1,2)
Oui
Oui(1)
(Librairie
Xalan) (1,
[2?])
- XQUF
(partiel,
vers un
support
complet)
Non(autre) Non
[ 2.4 :
oui ]
Non
(autre)
61
eXist
- XQUERY
FT
BDB
XML
Xindice
oui
Non
- Hirarchie Oui
de collections
Non
Oui
(Prsence
de
containers:
1 niveau
de
hirarchie.
)
BaseX
Sedna
MonetDB/
XQUERY
Partiel
(ftcont
ains )
Non
(autre)
Non (Pas Non (1

trs clair: niveau)
Collection
s dans
l'API
Java)
Non, 1
niveau
Hirarchie
BDD:
- Instances
multiples de
bases de
donnes
Oui
Oui (cf.
Oui, mais ?
server.xml une bdd =
)
1
document.
Non
Divers:
- Gestion des Non
Transactions
Oui
Non
Non
Oui
- Mode de
Mode
fonctionneme embarqu,
nt
mode
serveur.
(SOAP,
REST,
XMLRPC,
WebDav,
APP)
Embarqu.
Projet
Parallle
(nxqd)
pour le
mode
serveur
Mode
embarqu
et clientServeur
Mode
Serveur:
Socket
Based
Mode
Server:
binary
based
Network
protocol,
http et ftp
via API
- Interface
Oui (Ligne
d'Administrat
de
ion
commande
, Client
Java,
Interface
Web)
Non
Oui (XML
Updates)
- Dispositif
d'indexation
Dispositif
d'indexatio
n
modulaire:
Structural,
Full text,
Range,
Oui
(Client
Java)
Oui (2
clients
java)
SOAP
(XRPC
[XQUER
YD])
Oui
(Interface
Web/javas
cript et
ligne de
commande
)
Noeuds Dispositif Automatiq

textes,
manuel
ue
mots des d'indexatio Nature:?
noeuds
n
textes,
valeur des
attributs,
62
eXist
BDB
XML
Xindice
Ngram,
Spatial
- Facilit
d'utilisation
***
BaseX
Sedna
MonetDB/
XQUERY
**
***
full
text .
Utilisation
des index
pour
Xpath, pas
pour
XQUERY
***
**
1.2 - Les bases de donnes Hybrides ou grant un type XML:

1.2.1 - Caractristiques gnrales:
Certaines bases de donnes relationnelles permettent de grer un format XML, d'autres
proposent une interface similaire une base de donne XML native (On parle de base Hybride).
Actuellement, les bases de donnes hybrides sont des solutions propritaires (dbxml de Oracle et
db2 de IBM).
La gestion des donnes XML dans les bases de donnes relationnelles s'est longtemps
rsume au stockage de chanes de caractres. Actuellement on peut voir au moins deux volutions
dans la gestion de XML:
- Le stockage du XML dans les bases de donnes XML natives fait l'objet d'optimisations
plus adapts, avec la cration d'un type XML propre dans les bases de donnes (Arbres binaires).
- La standardisation de fonctions de gestion du XML dans le langage SQL, ainsi que des
recommandations pour l'implmentation d'XQUERY, via les standards ANSI/ISO SQL/XML:2003
et SQL/XML:2006 commencent tre implment dans les SGBDR.
L'implmentation de fonctionnalits XML reste nanmoins assez limit, et la prochaine
tape attendue reste le support d'XQUERY.
PostgreSQL16 qui implmente un type XML, ainsi qu'une partie des normes SQL/XML
MySQL17 qui implmente des fonctions d'import et d'export XML sur la base d'un type chane
de caractres.
1.2.3 - PostgreSQL
La version 8.3 de PostgreSQL intgre nativement un type XML et des fonctions XML
16 http://docs.postgresqlfr.org/8.3/datatype-xml.html ; http://docs.postgresqlfr.org/8.3/functions-xml.html
17 http://dev.mysql.com/doc/refman/6.0/en/xml-functions.html ; http://dev.mysql.com/tech-resources/articles/xml-inmysql5.1-6.0.html
63
conformes certaines des spcification SQL/XML. Les fonctions XML taient dj prsentent sous
la forme d'un module depuis la version 8.1.
Le type XML implment dans PostgreSQL permet l'import et l'export de documents XML
ou de fraction de documents XML. Il permet par ailleurs une meilleure indexation des contenus
XML, grce des Generalized Search Trees et des B-Trees .
Les fonctions implmentes par PostgreSQL permettent la gnration de XML partir de
tables SQL (xmlcomment, xmlpi, xmlelement, xmlattributes, xmlroot, xmlconcat, xmlforrest), les
requtes xpath sur un arbre ou un type xml (xpath(query, xml)), les exports xml de structures
(table_to_xml, query_to_xml, cursor_to_xml), et le teste d'un arbre (IS DOCUMENT).
Le stockage du XML est rendu possible par la fonction XMLPARSE qui prend une chane
de caractre en argument. L'opration inverse est rendue possible par l'opration XMLSERIALIZE.
L'accs via une API java la base de donne est rendu possible par le pilote JDBC
PostgreSQL. Nanmoins, les optimisations existantes dans la base de donnes sont perdues
l'import des donnes qui sont srialise en chanes de caractres, et non directement traduites en
SAX ou en DOM.
1.2.4 - MySQL
A partir de la version 5.1 MySQL intgre quelques fonctions permettant l'import, l'export et
le traitement du XML. Il n'existe pas de type XML, des Chanes de caractre ou des BLOB (Binary
Long OBjects) sont utiliss pour le stockage du XML.
Trois types de fonctions XML existent:
Sorties XML: il est possible de composer un document partir du contenu des tables via des
instructions de composition d'un document XML (grce l'extension lib_mysqludf_xql).
Chargement d'un fichier: Accs au contenu d'un fichier via LOAD_XML, avec la possiblit de
charger directement le contenus des lments XML dans des colonnes de la base de donne.
Interrogation du XML: Possibilit d'interroger un contenu XML en Xpath ( ExtractValue() ), et
de raliser des mises jour sur un fragment xml ( UpdateXML() ).
MySQL n'est pas entirement conforme Xpath 1.0: certains axes ne sont pas supports
(following, following-sibling, preceding, preceding-sibling), les espaces de nom ne sont pas grs,
mais une recherche exact sur prefix:nom est possible, enfin un certains nombre de fonctions sont
absentes, dont name() et substring-after(), substring-before(), translate().
Un pilote JDBC est utilis pour accder MySQL en Java.
1.2.5 Bilan
Au niveau du type XML, seul PostgreSQL propose une solution optimise avec des arbres
binaires et des index adapts. En termes de fonctions XML, on retrouve peu prs les mmes
fonctionnalits: gnration, import et accs en XPATH au XML. MySQL se distingue tout de mme
par l'apport d'un mcanisme de mise jour des donnes en XPATH.
Pour les deux solutions, il n'existe pas de support de XQUERY, et le langage d'interrogation
demeure SQL.
Pour l'accs aux donnes en mode serveur depuis java, les pilotes JDBC sont utilisables mais
64
ils ne sont pas optimis pour le traitement d'un modle de document XML.
1.3 MiddleWare
1.3.1 Caractristiques gnrales
Dans le domaine du stockage des donnes XML, les middleWares ou applications
intermdiaires sont utiliss pour le stockage des documents XML dans les bases de donnes
relationnelles, ou pour la manipulation du XML sous forme d'objets. Nous nous intressons ici au
premier type uniquement.
Les applications intermdiaires permettent de manipuler les SGBDR de la mme faon que
les bases de donnes XML natives. Les solutions prennent en charges deux aspects: le stockage du
XML dans les tables du SGBDR, et la traduction des requtes en langage XML vers le SQL.
Parmi les solutions existantes on distingue celles qui ne ncessitent pas la dclaration
pralable d'un schma pour le stockage de documents /collections XML, et celles implmentant les
standards XML d'accs aux donnes (XPATH, XQUERY).
Parmi les solutions, la plupart ne sont plus maintenus, et aucune ne bnficie d'une
communaut dveloppe. Les tableaux suivants prsentent les solutions de middlewares en
distinguant les solutions de mapping objet, les solutions qui semblent abandonnes, et la solution
qui semble active et adapte. Malheureusement pour cette dernire, les sources ne sont disponibles
que par l'intermdiaire du projet MonetDB/XQUERY dans lequel elle est implmente.
Mapping Objet (inadapt):
Produit
URL
Dernire activit
XML-DBMS
http://www.rpbourret.com/xmldbms/index.htm
2002
JaxMe
http://ws.apache.org/jaxme/
Octobre 2006
HyperJaxB3
https://hyperjaxb3.dev.java.net/
Mars 2008
Faible activit:
Produit
URL
Dernire activit
Minx
http://sourceforge.net/projects/minx/
Octobre 2002
LegoDB
http://www-db-out.bell-labs.com/legodb/
Juin 2002
XTAS
http://xtas.sourceforge.net/
Fvrier 2003
Xquare
http://xquare.objectweb.org/
Septembre 2005
En lice:
Produit
URL
Dernire activit
Pf/Tijah
http://dbappl.cs.utwente.nl/pftijah/
Fvrier 2008
65
1.3.3 Pf/Tijah
La solution intgre le middleware PathFinder qui permet le stockage en base de donnes de
documents XML, et la traduction de requtes XQUERY et XPath en requtes SQL. Pf/Tijah quand
lui intgre la gestion de la recherche plein texte en XQUERY.
Les fonctionnalits de Pf/Tijah sont actuellement implmente dans MonetDB/XQUERY
(cf. 1.2.6), et aucune facilit n'est faite pour permettre l'intgration dans un autre SGBDR. Seul un
article sur l'intgration dans PostgreSQL paru en 2004, voque la possiblit de le faire; les sources
du middleware ne sont cependant pas accessibles.
1.3.4 Bilan
Pas d'intrt.
2 - Diagnostic
2.1 Observations sur Notix
Performances:
forte utilisation du pseudo protocole cocoon:/ pour le stockage des
donnes: coteux en termes de performance.
systme de stockage en java, pas optimal pour les performances.
Implmentation du systme de stockage:
couplage fort de l'application au systme de stockage:
classes java eXist implmentant le protocole xml:db
design des URI spcifique eXist et diffrent selon le
fonctionnement en mode serveur ou embarqu
prennit douteuse du protocole xml:db:
l'implmentation d'eXIst est une implmentation augment de
l'API
le groupe de travail sur le protocole n'existe plus, et n'a laiss
qu'un brouillon de travail pour spcifications.
En termes d'API, dveloppement en cours de XQJ comme
quivalent JDBC pour XQUERY et alternative XML:DB.
volution de XQUERY avec un langage de mises jour
(XQUF), remise en cause de XUPDATE.
2.2 Bilan sur les solutions observes
En termes de performances, plusieurs solutions semblent intressantes au del

d'eXist: MonetDB/XQuery, Sedna, et Berkeley DB XML. Nanmoins il existe
plusieurs obstacles l'implmentation de ces solutions dans Notix:
au niveaux du fonctionnement en mode serveur ou distant
aux niveau des hierarchies des collections et des capacits multiinstances
Parmi les middleWare, seul Pj/Tijah offre un service intressant en termes de performances
66
et d'implmentation de XQUERY. Nanmoins son implmentation en dehors de MonetDB est

exclue par l'absence des sources.
Plusieurs alternatives sont possibles:
Conserver eXist et implmenter une interface plus gnrique vers le systme de stockage
pour favoriser les volutions venir:
Les motivations pour conserver eXist tiennent essentiellement la qualit de la
solution, en termes d'volution, de communaut d'implmentation des standards,
et d'activit. Il s'agit par ailleurs de la solution en place actuellement pour
laquelle il existe donc dj des comptences. En outre la version 1.2 apporte le
support de APP, un mcanisme d'indexation plus souple et potentiellement plus
performant (modulaire).
L'implmentation d'une interface plus gnrique rpond deux problmes
actuels de l'implmentation du systme de persitance: le couplage fort existant
entre l'application et le systme de persitance, et l'exploitation du protocole
XML:DB. Comme interface possible de remplacement, plusieurs technologies
sont envisageables: l'implmentation de REST d'eXist, de SOAP, de Atom
Publishing Protocol.
L'implmentation d'une interface gnrique permet d'envisager des

modifcations futures du systme de stockage des notices xml, en dveloppant
une interface la plus gnrique possible.
Mettre en place MonetDB en mode serveur. MonetDB apparat avant tout comme une
solution performante. L'implmentation des standards XML est plutt avance (jusqu'
XQUF pour XQuery). La solution est par contre beaucoup moins bien dote en interfaces
HTTP, ne fournissant que deux protocoles internes Mapi et XRPC, le second tant bas sur
SOAP. Pour mettre en place MonetDB, les amnagements suivants seraient ncessaires:
implmenter XRPC via SOAP pour communiquer avec le systme de stockage
Mettre en place une hirarchie un niveau de collections pour le classement des
notices (pas de hirarchie de collections implmentes).
2 - Comparatif:
xmldb, XRDBMS, middleWare
-> performance, communication/requtes, rfrences (stade de dvpt, communaut, documentation*)
3 valuation des solutions:
http://dbs.uni-leipzig.de/en/projekte/XML/XmlBenchmarking.html
Annexe:
Mthodologie d'valuation des logiciels libres:
Les critres sont drivs de la mthodologie de Bull (http://www.novaforge.org/novaforge/frpartager/methodologie), et de la Mthode de Qualification et de Slection de logiciels Open Source
(QSOS http://www.qsos.org/methode.php?lang=fr ).
67
Barme
**
***
Utilisateurs
Pas d'utilisateurs
identifis
Utilisateurs dtectables Communaut

via internet
d'utilisateurs identifis /
Rfrences
Communaut
Groupe de dveloppeur Communaut

clos / Socit
priphrique /
contributeurs
Fonctionnement en
communaut et outils
associs
Documentation
Basique
Utilisateurs et
dveloppeurs
Systmatis, avec
contributions
Activit
0 3 dveloppeurs
4 7 dveloppeurs, ou
fort turn-over
+ de 7 dveloppeurs
Maturit
Encore en
Version(s) stable(s),
dveloppement, pas de utilisable.
version stable
Actualit
Le projet semble
l'abandon
Version prouve.
Roadmap.
Projet actif, mais

Forte participation,
communication/particip nombreuses actualits
ation peu dense
68
ANNEXE 4: tude des besoins

1 - Existant:
Notix est une solution de gestion des notices bibliographiques. Elle a t ralise partir de
plusieurs composants, SDX, Cocoon, et eXist pour le stockage des donnes XML.
1.1 Organisation du stockage:
Le stockage des donnes XML est organis de la manire suivante:
plusieurs instances d'eXist: Pour chaque base documentaire et la gestion des utilisateurs,
plusieurs collections de premier niveau: Pour la gestion des notices, des auteurs moraux, des
listes ,
plusieurs collections de deuxime niveau: pour le stockage des notices en lots de notices, des
fins d'optimisation des accs.
Notix permet de grer le stockage des donnes XML en mode embarqu, ou en mode serveur. La
circulation des instructions entre Notix et une ou plusieurs bases eXist distantes est rendue possible
par l'utilisation d' XML-RPC.
En java, l'interaction entre Notix et eXist est assure par l' API XML:DB, qui a t implmente par
eXist sur le modle de l' XML:DB Initiative.
1.2 - Intgration dans Cocoon:
L'implmentation du systme de stockage est visible dans:
les sitemap cocoon:
indication de l' URL des bases de donnes distantes
implmentation du protocole xmldb dans les gnrateurs
les xsp:
manipulation des collections et documents (Lot.xsp).
les flowscripts:
Cration dynamique des schmas, remplissage des formulaires, modifications par lots.
la configuration de Cocoon (protocole xmldb dans cocoon.xconf)
les classes java (XmlDBURL, NotixBaseList)
Par ailleurs, un systme de mise en cache des requtes eXist t mis en place dans l' API
XML:DB. Cette implmentation est importante pour les performances gnrales de l'application.
1.3 Accs aux donnes, et modifications des documents:
L'accs aux donnes et la modification des documents est rendue possible par l'utilisation de
langages de requte XML:
XQuery : Pour les modifications par lots, et la slection de documents
Xpath : Pour l'accs aux donnes des documents
XQuery Full Text : Pour les requtes de modification et de recherche (dans XQuery)
Un dialecte eXist de mise jour des donnes intgr XQuery.
1.4 - Tches ponctuelles lies aux systme de stockage:
Lancement de l'indexation de la base
excution d'une requte sur la base (en lecture, ou en criture)
Lancement d'une sauvegarde des bases eXist
Pour ces tches, est utilis un client java fonctionnant en ligne de commande ou avec une interface
69
graphique fourni par eXist.

1.5 En chiffres
Volume de donnes global:

Volume de donnes moyen par bases:
Taille moyenne (maximum) d'un document:
Nombre d'accs simultans moyen (maximum):
2 - Qualification des besoins pour le stockage des documents XML dans Notix
De manire gnrale, l'tude du systme de stockage de Notix est motiv par les besoins suivants:
Prendre connaissance des solutions alternatives de stockage des donnes XML qui existent ou
mergent, afin de rester avis des volutions en cours dans le domaine.
valuer les solutions alternatives et notamment les gains en terme de performance dans Notix.
valuer la prennit et la performance des technologies et protocoles utiliss dans Notix.
2.1 - Accs au systme de stockage:
Fonctionnement en mode embarqu.
Fonctionnement en mode serveur.
Possibilit d'utiliser une API Java pour accder la base et grer les donnes.
Possibilit de raliser des tches d'administration partir d'un client extrieur Notix pour:
l'indexation
l'excution de requtes sur les bases
la planification/ralisation de sauvegardes des bases de donnes.
Prfrence pour l'adoption d'un protocole standard pour la communication entre Notix et une ou
plusieurs bases distantes:
actuellement XML-RPC
intrt pour REST
2.2 - Accs aux documents et aux donnes:
Fonctionnalits d'ajout, de suppression, de mise jour et de lecture des documents:
via l' API Java.
via un client autonome.
Prfrence pour l'utilisation de standards pour l'accs aux donnes XML:
XQuery (XQuery FullText, XQuery Update Facility)
Xpath 2
Conformit maximale au XQuery 1.0 and XPath 2.0 Data Model (XDM)
Possibilit de mettre en cache les rponses du systme de stockage:
soit une implmentation existe
soit les dispositif de stockage permettnet l'accs aux mtadonnes pour la cration d'un
systme de mise en cache.
2.3 - Stockage des documents:
Pour le stockage des documents, une hirarchie similaire l'existant doit pouvoir tre reproduite sur
la base des mmes outils ou non (instances de bases de donnes, collections, sous collections,
contenus mixtes des collections). Au minimum l'organisation des documents devra contenir:
Plusieurs bases documentaires (bases par site, et base d'utilisateurs)
Plusieurs collections documentaires (distinctions des notices, des auteurs moraux, des listes)
70
Un ensemble de sous collections documentaires pour le stockage des notices. Cet aspect est
moins fondamental, mais correspond l'existant.
2.4 Environnement:
La recherche d'une solution de stockage des donnes XML devra tenir compte de l'environnement
actuel, et de la compatibilit des licences. La porte de l'tude se limitera donc:
Aux solutions libres mettant disposition les sources de l'application
Aux solutions dveloppes au moins pour Windows et Linux
71

Master Informatique

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Master Informatique

Hochgeladen von

Copyright:

Verfügbare Formate

Rmy Delmotte

tude des capacits d'volution du systme de gestion des documents

Sous la direction de:

Soutenu le 15 septembre l'UFR MSES

Aprs avoir prsent l'environnement du stage et la mission, nous prsenterons les

Le PANDoc est un service du Ministre de l'cologie, de l'nergie, du dveloppement

1.1.2 Notix, une solution de gestion des notices bibliographiques

Oprations sur chaque base

Cration et modification d'un gabarit de notice via un formulaire

Cration, suppression, modification et duplication des notices via un formulaire

Modification d'un champ par lot de notice

Historique de recherche, gestion des favoris pour la recherche

Gestion de listes de valeurs pour les champs de formulaire

Cration et suppression de bases documentaires

Rinitialisation des instances, rindexation, optimisation des index

Gestion des groupes et des utilisateurs

Exportation et importation de notices en masse

Notix a t livre au PANDoc en 2007. La solution est en production et fait l'objet de

1.1.3 La gestion des documents XML avec eXist

contenant des notices telles que "/db/Unebase/0001/Unebase-0001001.xml".

1.1.3.7 Les instances multiples

Pour une base embarque: "xmldb:nomInstance:///chemin"

Pour une base distante: "xmldb:nomInstance://adresseDuServeur/nomInstance/xmlrpc/chemin"

Illustration 1: Organisation du stockage des donnes XML de Notix dans eXist

1.1.4 La communication entre Notix et eXist

L'obtention d'une liste des instances configures.

L'interrogation d'eXist directement par le protocole "xmldb:", grce au mcanisme des

1.1.4.2 La configuration d'un serveur eXist distant

1.1.4.3 Le mcanisme de composition des URL

Le mcanisme de composition des URL de Notix est ralis en plusieurs tapes.

url", et adopte un patron d'URL adapt un eXist embarqu ou distant.

Trois stratgies sont utilises pour l'accs la base de donnes XML:

En utilisant un composant cocoon (FileGenerator) qui rcupre directement le contenu

En utilisant 2 composants Cocoon. Le premier excute le mcanisme de composition de

En utilisant des scripts serverpages ou flowscript. Dans ce cas, les informations

<map:generate type="xsp" src="xsp/lists-edit.xsp">

<map:parameter name="url" value="xmldb:notix:///db/Listes/

<map:parameter name="base" value="{1}"/>

Puis dans la xsp, manipulation de la source Cocoon9:

1.1.5 XML:db initiative, une tentative de normalisation des bases XML

1.2 Droulement de la mission

Une qualification des besoins permettant de dfinir le primtre de l'tude.

Une analyse dtaille de l'implmentation d'eXist dans Notix et l'implmentation d'un

La conception et l'implmentation d'un dispositif gnrique de gestion du stockage des

1.2.2 La gestion de projet

tude/Veille sur les solutions de stockage des documents XML

tude des besoins et de l'existant

Implmentation d'une interface HTTP REST entre Notix et eXist

Recensement des stratgies, mthodes et outils lis au systme de stockage XML.

tude des dpendances lies aux systmes de Stockage dans Notix

Optimisation de l'implmentation en termes de couplage, performances, et d'ouverture aux

valuation des amliorations possibles, conception de l'API xdb

Dveloppement de l'API xdb

Implmentation des amliorations dans Notix

Implmentation d'une interface HTTP REST

Veille sur les solutions de stockage XML

Illustration 2: Droulement de la mission par lot de tches

Veille sur les solutions de stockage

tude des besoins

Illustration 3: Droulement de la mission (dtail)

L'valuation des diffrentes solutions a t guide par 3 types de barme:

La distance avec l'existant.

L'valuation du logiciel "open source".

10 cf. Annexes 4: tude des besoins