Rmy Delmotte

MASTER 2 ID(Informatique et Document)

RAPPORT-MMOIRE DE STAGEMission effectue du 18 fvrier 2008 au 18 aot 2008

auCT 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 MSESUniversit 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.

2

SommaireIntroduction:.........................................................................................................................................41 Prsentation....................................................................................................................................5

1.1 Environnement du stage..........................................................................................................51.1.1 Le Point d'appui national documentaire (PANDoc)........................................................51.1.2 Notix, une solution de gestion des notices bibliographiques..........................................51.1.3 La gestion des documents XML avec eXist....................................................................71.1.4 La communication entre Notix et eXist........................................................................101.1.5 XML:db initiative, une tentative de normalisation des bases XML.............................13

1.2 Droulement de la mission...................................................................................................151.2.1 Les volutions de la mission.........................................................................................151.2.2 La gestion de projet.......................................................................................................16

1.3 Mthodologie........................................................................................................................181.3.1 La recherche d'informations et l'valuation..................................................................181.3.2 Les cycles de dveloppement........................................................................................19

2 L'tude des systmes de stockage XML.......................................................................................212.1 Les types de solution.............................................................................................................21

2.1.1 Les bases de donnes XML..........................................................................................212.1.2 Les bases de donnes relationnelles..............................................................................21

2.2 Une pluralit de formats, standards et protocoles.................................................................242.2.1 Les API java..................................................................................................................242.2.2 Les formats de communication.....................................................................................242.2.3 Les dialectes XQuery....................................................................................................252.2.3 Organisation des ressources..........................................................................................26

3 Besoins et critique de l'existant....................................................................................................273.1 Un avenir incertain pour l'API XMLDB..............................................................................273.2 Une dpendance de Notix avec eXist...................................................................................273.3 Mlange des logiques de traitement et de stockage..............................................................283.4 - Rptitions des algorithmes dans l'application......................................................................29

4 Prconisations et ralisations........................................................................................................314.1 Diagnostic.............................................................................................................................31

4.1.1 - Masquer le systme de stockage utilis pour rduire les dpendances..........................314.1.2 Augmenter la lisibilit du dispositif d'accs aux ressources XML...............................344.1.3 Factoriser les oprations redondantes...........................................................................374.1.4 Implmentation de HTTP/REST...................................................................................38

4.2 L'API xdb..............................................................................................................................394.2.1 Le patron de conception "stratgie", pour l'implmentation de nouveaux pilotes........394.2.2 Une hirarchie de classes qui favorise l'utilisation des standards.................................394.2.3 Le dispositif de configuration et de chargement des pilotes.........................................414.2.4 Le mcanisme de composition des URL.......................................................................42

4.3 Intgration Cocoon.............................................................................................................444.3.1 L'utilisation d'un pilote unique, la classe XDBSource..................................................444.3.2 La mise en place d'un systme de cache.......................................................................45

4.4 Les tests unitaires..................................................................................................................474.5 Limites du dveloppement de l'API xdb...............................................................................48

Conclusion:.........................................................................................................................................49Bibliographie:.....................................................................................................................................50Annexes..............................................................................................................................................51

3

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.

4

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 gnraleNotix 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 notice1 http://urbamet.documentation.developpement-durable.gouv.fr2 http://temis.documentation.equipement.gouv.fr

5

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 http://admisource.gouv.fr/4 cf. annexe 1: Architecture de Notix5 Littralement, une bilbiothque de balises.6 Ronald Bourret, 2005. XML and Databases[En ligne]. [Consult en aot 2008].

http://www.rpbourret.com/xml/XMLAndDatabases.htm

6

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 documentairesPour 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 noticesL'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

7

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 automatiqueLors 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 listesLes 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

8

1.1.3.7 Les instances multiplesNotix 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 ressourcesPour 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"

9

1.1.4 La communication entre Notix et eXist

1.1.4.1 La configuration des instances eXistPour 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.

notix true

10

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

xmldb/notix.xml instance2 true xmldb/instance2.xml

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 distantLa 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.

172.16.41.5:8088

1.1.4.3 Le mcanisme de composition des URLLe 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 "exist-

11

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.

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.

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.

12

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

16

Illustration 2: Droulement de la mission par lot de tches

fvrier mars avril mai juin juillet aot

Implmentation d'une interface HTTP REST

Veille sur les solutions de stockage XML Optimisation de l'implmentation

Dmarche exploratoire

17

Illustration 3: Droulement de la mission (dtail)

fvrier mars avril mai juin juillet aot

tude des besoins

Dmarche exploratoire

Veille sur les solutions de stockage XML

Conception API xdb

valuation des solutions et bilan

de l'tudePrconisations

Dveloppement API xdb

tude des besoins: seconde analyse de Notix, dveloppement

interface RESTImplmentation dans

Notix

1.3 Mthodologie

1.3.1 La recherche d'informations et l'valuationPour 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

identifisUtilisateurs dtectables via internet

Communaut d'utilisateurs identifis / Rfrences

10 cf. Annexes 4: tude des besoins11 http://www.qsos.org/methode.php?lang=fr12 http://www.novaforge.org/novaforge/fr-partager/methodologie

18

Barme * ** ***Communaut Groupe de dveloppeurs

clos / SocitCommunaut 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 dveloppement, pas de version stable

Version(s) stable(s), utilisable.

Version prouve. Roadmap.

Actualit Le projet semble l'abandon

Projet actif, mais communication/participation peu dense

Forte participation, nombreuses actualits

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 XMLLes 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 relationnellesIl 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 javaLa 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/XQUERY

- xml:db API oui non Oui Non Oui Non- XQJ (JSR 225)

(en dveloppement)

non Non Non non Non

- autres Non API Java dbxml, Ruby, PHP, .NET

Non API Java.

C, Php, python, .net, Scheme.

XRPC(java/javascript), CGI binding (.xq), MAPI

Illustration 4: Revue des API utilises dans les bases de donnes XML

2.2.2 Les formats de communicationIl 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 fonctionnement

Mode embarqu, mode serveur.

Mode embarqu

Mode embarqu et client-Serveur

Mode Serveur

Mode Serveur

Mode Serveur

"socket-based" Non - Non Oui Oui NonXML-RPC Oui (via

XMLDB)- Oui Non Non Non

SOAP Oui - Non Non Non OuiREST Oui - Non Non Non NonAPP Oui - Non Non Non NonWebdav Oui - Non Non Non NonXRPC/XqueryD Non - Non Non Non Oui

Illustration 5: Implmentation des statgies de communication par base de donnes XML

2.2.3 Les dialectes XQueryPour 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 Xindice BaseX Sedna MonetDB/XQUERY

- XUPDATE (xml:db)

Oui Non Oui Non Oui Non

- XQUERY 99.4% (XQTS)

99.5% (XQTS) Non 99.3% (XQTS)

98.8% (XQTS )

En partie

- XPath Oui(1,2) Oui (1,2) Oui (1) Oui(1) Oui (1,2) En partie- XQUF (partiel, vers

un support complet)

Non(autre)(en dveloppement)

Non Non (autre) Non (autre) Oui

- XQUERY FT

oui Non Non Partiel Non Non (autre)

Illustration 6: Implmentation de XQuery par base de donnes XML

2.2.3 Organisation des ressourcesLa 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 MonetDB/XQUERY

- Hirarchie de collections

Oui Non (Prsence de "containers":1 niveau de hirarchie.)

Oui Non Non (1 niveau)

Non, 1 niveau

- Instances multiples de bases de donnes

Oui Non Oui Oui, mais une bdd = 1 document.

Non Non

26

3 Besoins et critique de l'existant

3.1 Un avenir incertain pour l'API XMLDBL'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 sous-

collections 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'applicationUn 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 xdbLa 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 gnriquesLa 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 configurationLa 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.

true/home/xmldb/instance2.xmlinstance2

true

33

/home/notix/WEB-INF/xmldb/instance3.xml

instance3

true

/home/notix/WEB-INF/xmldb/instance4.xml

instance4

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 ressourcesLa 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:

34

est simplifi par:

De la mme manire:

s'crit dsormais:

4.1.2.2 Une syntaxe alternative en langage javaLa 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 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 xqueryLotCount(String chemin, String search, String property)

public java.util.Collection listResources(String chemin) public java.util.Collection listResourcesSorted(String

chemin) public java.util.Collection 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 NotixXdbManager.getNotixBaseDefinition() // permet d'obtenir une liste des caractristiques d'une baseXdbManager.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 redondantesLa 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/RESTLe 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 NotixBaseListTreeMap baseMap = XdbManager.notixBaseList.get(base);// Initialisation des paramtres de classethis.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 approprithis.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 standardsChaque 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.

40

Illustration 7: Diagramme descriptif de la hirarchie de classe de l'API xdb

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 basesxdbImpl = getXdb(xdbClass, instName, xdbUrl, instUser, instPass);// On dmarre les instances avec leurs paramtresxdbImpl.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 URLLe 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/non-

valides" + "/" + 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 XDBSourcePour 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 cachePour 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 unitairesPour 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

AnnexesANNEXE 1 : Architecture de Notix...................................................................................................52ANNEXE 2: Traitement d'un document XML dans un script serverpages........................................53ANNEXE 3: tude des systmes de stockage XML..........................................................................56ANNEXE 4: tude des besoins..........................................................................................................69

51

ANNEXE 1 : Architecture de Notix

52

ANNEXE 2: Traitement d'un document XML dans un script serverpages

org.exist.cocoon.XMLDBSourceorg.w3c.dom.Documentorg.w3c.dom.Elementorg.w3c.dom.NodeList

/* 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(); esw

}

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 oublierdbf.setNamespaceAware(true);javax.xml.parsers.DocumentBuilder db = dbf.newDocumentBuilder();return db.parse(new org.xml.sax.InputSource(new

java.io.StringReader(xml ) ) );}

53

// Le nom de la listeString name=parameters.getParameter("name", null);// la source cocoon de laquelle tirer un docString url=parameters.getParameter("url", null);XMLDBSource source=null;// du DOMDocument doc=null;Element el=null;NodeList nl=null;// si a plante ici, c'est que le paramtre est mal pass ct

sitemapsource=(XMLDBSource)resolver.resolveURI(url);

Notix, Listesname

//

Listes / name

Liste: name

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) {Erreur au chargement de la

liste nametoSAX(e);

}

if (request.getParameter("value") != null) {

String[] values=request.getParameterValues("value");

String xml="";

54

xml +="";

for (int i=0; i < values.length ; i++) {xml +="\n\t" + values[i] +

"";}xml +="\n";try {

doc=string2dom(xml);source.setContentAsDOM(doc);

} catch (Exception e) {Problme dans

l'criture de la listetoSAX(e);

}}

etc.

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 fonctionna