MASTER 2 ID (Informatique et Document) RAPPORT-MÉMOIRE DE STAGE Mission effectuée du 18 février 2008 au 18 août 2008

Transcription

1 Rémy Delmotte MASTER 2 ID (Informatique et Document) RAPPORT-MÉMOIRE DE STAGE Mission effectuée du 18 février 2008 au 18 août 2008 au CéTé Nord Picardie 2 rue de Bruxelles, Lille. Étude des capacités d'évolution du système 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 , Villeneuve d'ascq cedex Année universitaire 2007/2008

2 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

3 Sommaire Introduction: Présentation Environnement du stage Le Point d'appui national documentaire (PANDoc) Notix, une solution de gestion des notices bibliographiques La gestion des documents XML avec exist La communication entre Notix et exist XML:db initiative, une tentative de normalisation des bases XML Déroulement de la mission Les évolutions de la mission La gestion de projet Méthodologie La recherche d'informations et l'évaluation Les cycles de développement L'étude des systèmes de stockage XML Les types de solution Les bases de données XML Les bases de données relationnelles Une pluralité de formats, standards et protocoles Les API java Les formats de communication Les dialectes XQuery Organisation des ressources Besoins et critique de l'existant Un avenir incertain pour l'api XMLDB Une dépendance de Notix avec exist Mélange des logiques de traitement et de stockage Répétitions des algorithmes dans l'application Préconisations et réalisations Diagnostic Masquer le système de stockage utilisé pour réduire les dépendances Augmenter la lisibilité du dispositif d'accès aux ressources XML Factoriser les opérations redondantes Implémentation de HTTP/REST L'API xdb Le patron de conception "stratégie", pour l'implémentation de nouveaux pilotes Une hiérarchie de classes qui favorise l'utilisation des standards Le dispositif de configuration et de chargement des pilotes Le mécanisme de composition des URL Intégration à Cocoon L'utilisation d'un pilote unique, la classe XDBSource La mise en place d'un système de cache Les tests unitaires Limites du développement de l'api xdb...48 Conclusion:...49 Bibliographie:...50 Annexes

4 Introduction: Le stockage et l'interrogation des documents XML constitue un domaine d'activité qui connaît des évolutions. Les outils de stockage et les langages disponibles pour l'interrogation d'un corpus de documents XML sont déjà nombreux, et des processus de normalisation sont en cours. La base de données XML exist comme les autres solutions de stockage des documents XML évolue au gré des standards, en réaction aux solutions concurrentes, et selon des dynamiques internes. Le Point d'appui National Documentaire développe Notix, une application de gestion des notices bibliographiques dont le stockage des documents XML repose sur exist. L'objectif de mon stage consistait à déterminer quelles étaient les alternatives envisageables au système de stockage des documents XML actuel de Notix, qui permettrait d'améliorer les performances générales de l'application. Au delà des aspects d'évaluation des solutions et de comparaison de leurs performances, les questions liées à 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 systèmes de stockage XML, quelles stratégies peut-on adopter pour garantir la capacité d'évolution et de réutilisation des composants d'une solution, lors de l'intégration d'un système de stockage XML? Après avoir présenté l'environnement du stage et la mission, nous présenterons les principales évolutions actuelles des systèmes de stockage de documents XML "open source", et les principaux dysfonctionnements et besoins rencontrés dans Notix concernant le système de stockage des documents XML. Enfin nous terminerons par la présentation des préconisations en termes d'organisation logicielle qui ont été faites, et les réalisations qui les ont suivies. 4

5 1 Présentation 1.1 Environnement du stage Le Point d'appui national documentaire (PANDoc) Le PANDoc est un service du Ministère de l'écologie, de l'énergie, du développement durable et de l'aménagement du territoire (MEDAT). Ses locaux sont situés au Centre d'étude techniques de l'équipement (CéTé) Nord-Pas de Calais Picardie. Le PANDoc réalise des missions d'ordre documentaire pour le compte du MEDAT, et parfois pour d'autres ministères. Une des spécificités du service est la composition mixte de documentalistes et d'informaticiens, qui permet la mobilisation du service sur des missions requérant cette double compétence. Le PANDoc est en charge de plusieurs bases documentaires qu'il héberge, administre et alimente, telle que Urbamet 1, ou Temis 2. Le PANdoc s'occupe aussi de réaliser des applications documentaires Notix, une solution de gestion des notices bibliographiques Présentation générale Notix est une application de gestion des notices bibliographiques publiée sous licence libre. La solution a été développée par la société AJLSM, suite à un appel d'offre du PANDoc. Notix permet d'administrer des bases documentaires composées de notices au format XML. Les principales fonctionnalités de Notix sont les suivantes: Opérations sur chaque base Création et modification d'un gabarit de notice via un formulaire Création, suppression, modification et duplication des notices via un formulaire Moteur de recherche Modification d'un champ par lot de notice

6 Fonctionnalités transversales Panier de notices Historique de recherche, gestion des favoris pour la recherche Gestion de listes de valeurs pour les champs de formulaire Administration Création et suppression de bases documentaires Réinitialisation des instances, réindexation, optimisation des index Gestion des groupes et des utilisateurs Exportation et importation de notices en masse Notix a été livrée au PANDoc en La solution est en production et fait l'objet de développements constants, qu'il s'agisse de maintenance ou d'ajouts de fonctionnalités. Lors de mon stage deux développeurs travaillaient sur Notix. Par ailleurs la solution a été publiée sur la plateforme de développement coopérative adminsource Architecture de l'application Notix est une application web java qui fonctionne sur le serveur d'application Tomcat. Trois applications libres ont été utilisées pour sa réalisation, Cocoon, SDX et exist 4. La plate-forme de publication Cocoon constitue le squelette de Notix. Elle fournit un système de "pipelines" permettant une gestion simplifiée de l'application à travers des patrons d'url situés dans des sitemaps. Chaque pipeline de l'application délivre un contenu, la plupart du temps après une série de transformations XSLT. Cocoon fournit par ailleurs un système de cache performant et une gestion avancée des formulaires avec les formulaires Cocoon (CFORMS). La plate-forme SDX permet la gestion de toutes les opérations liées à la recherche et à l'indexation en offrant une interaction facilitée avec le moteur de recherche Lucene. Elle est basée sur Cocoon et fournit une "taglib 5 " qui permet des développements rapides et fins. Les documents pris en charge par SDX sont au format XML. La base de donnée XML native 6 exist est utilisée pour la gestion des documents XML et cf. annexe 1: Architecture de Notix 5 Littéralement, une bilbiothèque de balises. 6 Ronald Bourret, XML and Databases[En ligne]. [Consulté en août 2008]. 6

7 l'exécution de requêtes XQuery sur les corpus de notices. Elle permet le stockage des documents dans une hiérarchie 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 caractéristiques de Notix est de reposer sur le format et les technologies XML. Dans son fonctionnement l'application exploite XSLT, DOM, SAX, Xpath et XQuery La gestion des documents XML avec exist Fonctionnement de exist EXist est une base de données XML native. Elle permet le stockage de documents et de portions de documents XML. Les documents peuvent être récupérés ou interrogés à travers les langages de requête XML XPath et XQuery. L'organisation d'une base exist peut exploiter un ensemble de collections, similaire à des dossiers dans un système de fichier pour stocker les documents XML. Une ressource dans une base de donnée XML peut être représentée par un chemin. Dans la base exist la racine de chaque ressource est la collection "/db" Les bases documentaires Pour constituer une base de donnée documentaire, Notix crée une collection à la racine d'une base exist, et crée un gabarit de notice sous la forme d'un fichier RDFS 7 placé dans la collection. Pour Notix, une base documentaire existe si ces deux conditions sont vraies. Par exemple la présence d'une collection "/db/unebase" et son gabarit "/db/unebase/_unebase.rdfs" produira une représentation de la base documentaire "Unebase" dans Notix 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 requêtes 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 utilisés pour répartir 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

8 contenant des notices telles que "/db/unebase/0001/unebase xml". Dans Notix la génération de l'identifiant d'une notice est réalisé automatiquement à partir d'un compteur stocké à la racine de la base. A chaque création de notice, "/db/unebase/counter.xml" est consulté puis incrémenté L'importation automatique Lors des opérations d'importation automatique de notices, Notix examine le contenu d'un dossier et enregistre les notices présentes dans une base documentaire désignée. Lors de cette opération Notix génère un rapport d'alimentation de la base. Ce rapport est stocké dans une sous collection "rapport" située elle-même dans une sous collection "_alix", du nom de l'application gérant les conversions de notices: "/db/unebase/_alix/rapports/unebase-date.xml". Les notices trouvées lors de l'importation sont examinées pour déterminer 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 importées sont stockées pour pouvoir être modifiées par la suite, respectivement dans "/db/unebase/_alix/notice rejetees/non valides/" et "/db/unebase/_alix/notice rejetees/doublons/" 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 décrivent les groupes et utilisateurs sont, comme pour les notices, décrits par un gabarit RDFS, et regroupés dans une base documentaire. Néanmoins les documents "groupe" et "utilisateur" obéissent à une organisation différente en étant stocké directement à la racine de la collection. Leur nom et identifiant est celui du groupe ou de l'utilisateur décrit par le fichier XML. Par exemple "/db/utilisateur/utilisateur1.xml" La gestion des listes Les listes sont disponibles pour toutes les bases documentaires de Notix. Elle représentent un ensemble de termes qui pourront être utilisés comme champ liste dans les formulaires de création de notices. Les listes sont constituées dans une interface séparée dans Notix et sont stockées dans exist dans une collection "Liste" qui n'est pas associée à une base documentaire, c'est à dire sans gabarit RDFS. Les documents de la collection liste sont au format RNG 8. Ils sont enregistrés à la racine de la sous collection, et ils sont identifiés et nommés par la désignation donnée 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 schéma XML 8

9 Les instances multiples Notix peut utiliser plusieurs instances d'une même base exist. Par défaut, Notix utilise une instance exist nommée "notix", dans laquelle elle crée systématiquement, si elles n'existent pas, les bases "Groupe" et "Utilisateur", et la collection Liste. Par la suite, Notix permet la création de bases documentaires sur une instance choisie, pourvu qu'elle soit déclarée dans la configuration de Notix. La base exist qui fournira les instances à Notix peut être disponible sous la forme d'une base embarquée (stockée comme archive java dans les bibliothèques de Cocoon) ou sous la forme d'un serveur d'application distant disposant de exist Les URL d'accès aux ressources Pour accéder aux ressources d'exist depuis Cocoon, Notix emploie l'api XMLDB qui permet de désigner les ressources par des URL. L'ensemble des accès aux documents XML est assuré par la désignation des emplacements dans exist. Les URL sont constituées selon deux formats, selon que la base est embarquée ou distante. Les patrons des URL sont les suivants: Pour une base embarquée: "xmldb:nominstance:///chemin" Pour une base distante: "xmldb:nominstance://adresseduserveur/nominstance/xmlrpc/chemin" 9

10 Illustration 1: Organisation du stockage des données XML de Notix dans exist La communication entre Notix et exist La configuration des instances exist Pour pouvoir disposer de plusieurs instances d'une base exist dans Notix, une déclaration préalable est nécessaire dans le fichier de configuration de Cocoon cocoon.xconf. Les instances sont déclarées avec un certain nombre de paramètres de configuration nécessaires à 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

11 <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 déclarées comme pilotes de base de donnée, et associées au pseudo-protocole "xmldb:". Cette déclaration des instances autorise plusieurs manipulations dans Cocoon: L'obtention d'une liste des instances configurées. L'interrogation d'exist directement par le protocole "xmldb:", grâce au mécanisme des sources Cocoon et à l'api XMLDB La configuration d'un serveur exist distant La configuration d'un serveur exist distant se traduit par la déclaration d'une variable globale dans un sitemap Cocoon. Au démarrage de Notix, la présence du paramètre est détectée, et une variable globale prend pour valeur l'adresse du serveur distant. Lors du fonctionnement de l'application, l'ensemble des requêtes sera adressé au serveur distant grâce au dispositif de composition des URL de Notix. <global-variables> <exist-url> :8088</exist-url> </global-variables> Le mécanisme de composition des URL Le mécanisme de composition des URL de Notix est réalisé en plusieurs étapes. Lorsqu'une requête est adressée à Notix pour réaliser une opération sur un document, le pipeline en charge de la réalisation de cette opération reçoit 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 recensées dans les instances exist, et établit quelle instance d'exist sera interrogée, par exemple "xmldb:notix/". Dans un second temps, Cocoon vérifie l'état de configuration de la variable "exist- 11

12 url", et adopte un patron d'url adapté à un exist embarqué ou distant. Lorsque la ressource interrogée est une notice de base documentaire, la sous-collection dans laquelle est rangée la notice est déduite de l'identifiant donné en argument, par exemple "0002" pour le document "Base xml" Implémentation dans Notix Trois stratégies sont utilisées pour l'accès à la base de données XML: En utilisant un composant cocoon (FileGenerator) qui récupère directement le contenu d'une source en SAX. Cette stratégie est utilisée seulement pour la lecture des documents. Elle est utilisée pour les opérations dans l'instance par défaut "notix" pour accéder aux listes, aux groupes et aux utilisateurs. <map:generate src="xmldb:notix:///db/listes/"/> En utilisant 2 composants Cocoon. Le premier exécute le mécanisme de composition de l'url à atteindre (Action XMLDBURL), le second est un FileGenerator qui produit un flux SAX à partir des informations recueillies. Cette stratégie est utilisée pour l'accès 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 nécessaires à l'identification du document à traiter sont passées en paramètre au script. L'action XMLDBURL peut être utilisée ou non, si elle ne l'est pas, le mécanisme de composition des URL est réalisé dans les scripts. Cette stratégie est la plus couramment utilisée dans Notix car elle permet l'exécution d'opérations complexes, notamment les opérations d'écriture et de requêtes 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

13 </map:generate> <map:act type="xsp" src="xsp/xmldburl.xsp"> <map:parameter name="base" value="{1}"/> <map:generate type="xsp" src="xsp/supprimer-panier.xsp"> value="{global:path-sdxapp}" /> value="{collection}"/> <map:parameter name="pj" value="{global:pj}" /> <map:parameter name="path-sdxapp" <map:parameter name="base" value="{../1}"/> <map:parameter name="collection" </map:generate> Puis dans la xsp, manipulation de la source Cocoon 9 : Source notice=resolver.resolveuri(collection + folder + "/" + id + ".xml"); ((XMLDBSource)notice).delete(); XML:db initiative, une tentative de normalisation des bases XML XML:db initiative est un groupe d'intérêt autour des technologies XML qui a pour objectif le développement de technologies standardisées dans le domaine des bases de données XML, et plus généralement la promotion des bases de données XML. L'association, active de 2000 à 2004, avait pour vocation de proposer des standards sous licence "open source" dans le domaine des bases de données XML. La motivation de cette démarche était d'éviter la multiplication des technologies concurrentes, et l'apport rapide de technologies attendues telle que l'extension de XQuery pour les opérations 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 méthodes d'accès, de configuration et d'interrogation d'une base de donnée 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é implémentée dans exist et constitue le mode de communication actuel de Notix avec la base de donnée. Xupdate est une extension au langage de requête 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

14 possibilité d'éditer des documents XML existants en s'intégrant à la syntaxe de XQuery. Le langage est apparu en 2003 sous la forme d'une recommandation inachevée (un "brouillon"), mais a néanmoins été implémenté par exist puisqu'il constituait alors la seule tentative de normalisation des opérations d'écriture en XQuery. Notix utilise ces opérations d'écriture pour la correction des notices par lots, l'édition des listes et des documents utilisateurs. 14

15 1.2 Déroulement de la mission Les évolutions de la mission La mission de stage qui m'a été proposée consistait à étudier les performances du système de stockage des notices de Notix. L'objectif de cette étude était de réévaluer la pertinence du choix actuel de système 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 définir le périmètre de l'étude. La mise en place d'un dispositif de veille et d'évaluation des solutions de stockage XML. La conception d'une série de tests de performance adaptés aux usages dans Notix. Les bénéfices attendus de la mission étaient une meilleure connaissance de l'offre pour les systèmes 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é réalisés qui ont orienté davantage la mission vers la recherche d'une implémentation pérenne et générique du système de stockage XML. Une meilleure connaissance de la constitution des principales solutions de stockage des documents XML m'a amené à considérer les limites qu'impliquaient la conception actuelle des communications avec le système 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 développement. 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 implémentation la plus générique possible au regard des différentes solutions de stockage des documents XML existantes. Cette phase du projet s'est déroulée en trois étapes: Un recueil des principales variations qui existaient entre les différents systèmes de stockage XML. Une analyse détaillée de l'implémentation d'exist dans Notix et l'implémentation d'un nouveau mode de communication entre exist et Notix à travers des requêtes HTTP (REST). 15

16 La conception et l'implémentation d'un dispositif générique de gestion du stockage des documents XML dans Notix, en vue d'améliorer l'intégration du nouveau dispositif de communication et de favoriser les évolutions futures La gestion de projet Lots de Tâches: Démarche 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 préconisations Implémentation d'une interface HTTP REST entre Notix et exist Recensement des stratégies, méthodes et outils liés au système de stockage XML. Implémentation de REST Étude des dépendances liées aux systèmes de Stockage dans Notix Optimisation de l'implémentation en termes de couplage, performances, et d'ouverture aux standards Évaluation des améliorations possibles, conception de l'api xdb Développement de l'api xdb Implémentation des améliorations dans Notix février mars avril mai juin juillet août Démarche exploratoire Implémentation d'une interface HTTP REST Veille sur les solutions de stockage XML Optimisation de l'implémentation Illustration 2: Déroulement de la mission par lot de tâches 16

17 février mars avril mai juin juillet août Démarche exploratoire Veille sur les solutions de stockage XML Conception API xdb Étude des besoins Évaluation des solutions et bilan de l'étude Préco nisati ons Développement API xdb Étude des besoins: seconde analyse de Notix, développement interface REST Implémentation dans Notix Illustration 3: Déroulement de la mission (détail) 17

18 1.3 Méthodologie La recherche d'informations et l'évaluation Pour mener à bien la comparaison des solutions, une première étude des fonctionnalités d'exist utilisées dans Notix a été réalisée 10. L'objectif était d'établir un étalon pour l'évaluation des fonctionnalités des autres solutions. Cette description des besoins a permis de découvrir progressivement les variations existantes entre les différentes solutions, et les aménagements qui seraient nécessaires dans la conception de Notix pour pouvoir considérer ces solutions comme des alternatives possibles à exist. Trois critères définissaient le périmètre de la recherche. Les solutions devaient être utilisables sur les systèmes d'exploitation Windows et Mandriva, et les sources disponibles sous licence open-source. Enfin si les solutions nécessitaient l'usage d'une base de données relationnelle, celles-ci devaient être utilisables avec PostgreSQL qui constitue le standard au PANDoc. Par ailleurs, des essais avaient déjà été effectués par le PANDoc et l'ajlsm sur un stockage direct des documents XML sur système de fichier. La solution était donc exclue de la recherche d'information. L'évaluation des différentes solutions a été guidée par 3 types de barème: 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 évaluées. La méthode d'évaluation des logiciels "open source" employée est un arrangement à partir des barèmes de la méthode de qualification et de sélection de logiciels open source 11 (QSOS), et de la méthodologie de création du guide bull de l'open source 12. La barème était le suivant: Barème * ** *** Utilisateurs Pas d'utilisateurs identifiés Utilisateurs détectables via internet Communauté d'utilisateurs identifiés / Références 10 cf. Annexes 4: étude des besoins

19 Barème * ** *** Communauté Groupe de développeurs clos / Société Communauté périphérique / contributeurs Documentation Basique Utilisateurs et développeurs Activité 0 à 3 développeurs 4 à 7 développeurs, ou fort turn-over Maturité Actualité Encore en développement, pas de version stable Le projet semble à l'abandon Version(s) stable(s), utilisable. Projet actif, mais communication/partici pation peu dense Fonctionnement en communauté et outils associés Systématisé, avec contributions + de 7 développeurs Version éprouvée. Roadmap. Forte participation, nombreuses actualités Les cycles de développement Lors de la seconde phase de la mission de stage, il a été décidé d'implémenter une nouvelle interface de communication entre Notix et la base exist. La réalisation de ce projet s'est déroulée en plusieurs étapes, en suivant un principe de développement par itérations. Le premier objectif de développement était de reproduire le fonctionnement de Notix avec HTTP/REST, sans chercher d'optimisations particulières du fonctionnement. Il s'agissait d'abord d'assurer la reproduction des fonctionnalités de l'application. Une seconde étape a consisté à rechercher les optimisations possibles de l'implémentation réalisée, en termes d'organisation, de pérennité et de lisibilité. Cette étape a conduit à la création d'une API java dédiée à la communication avec le système de stockage. La dernière étape a été l'implémentation 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'implémentation, mais aussi de réaliser des optimisations, cette fois au niveau des performances. Ce déroulement en trois étapes a permis de distinguer des logiques de travail et d'appréhender séparément les difficultés du projet. La première étape m'a permis de m'approprier le fonctionnement de l'application, d'établir la logique des traitement effectués, et de recenser les différentes stratégies d'accès au système de 19

20 stockage. La deuxième étape s'est davantage amorcée comme une revue critique de l'implémentation, nourrie par l'étude des systèmes de stockage existants. Il s'agissait de concevoir des critères de généricité, et d'évaluer quelles technologies dans Notix pouvaient être considérées comme pérennes. Le travail consistait donc à distinguer les éléments changeants et à adopter une organisation permettant de faire face à ces changements. La dernière étape, restée de peu inachevée, a été un mélange des deux logiques de développement précédentes : l'implémentation du nouveau dispositif, l'ajout de fonctionnalités omises, la rectification d'algorithmes, et la recherche d'optimisations des performances appelaient une vision pragmatique et un souci du détail. 20

21 2 L'étude des systèmes de stockage XML Cette partie présente les principales conclusions et constats qui ont suivi la veille sur les systèmes de stockage des documents XML. 2.1 Les types de solution Les bases de données XML Les bases de données XML natives se distinguent des systèmes de stockage XML fonctionnant avec des bases de données relationnelles par 3 caractéristiques: elles préservent la structure physique des documents (éléments, attributs, entités,...) elles permettent de stocker des documents sans déclaration préalable du schéma des documents. elles permettent d'accéder aux documents à partir des API spécifiques à XML (Xpath, XQuery). Par ailleurs les bases de données XML natives permettent la création de collections ( assimilables à des dossiers dans un système de fichier) Les principales bases de données 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 néerlandais Centrum Wiskunde & Informatica Les bases de données relationnelles Il existe deux manières d'exploiter les bases de données relationnelles pour le stockage des documents XML, les bases de données acceptant un type XML, et l'utilisation de middlewares. 21

22 Les bases de données Hybrides ou gérant un type XML Certaines bases de données relationnelles permettent de gérer un format XML, d'autres proposent une interface similaire à une base de donnée XML native (On parle de base hybride). Actuellement, les bases de données hybrides sont des solutions propriétaires (dbxml de Oracle et db2 de IBM). La gestion des données XML dans les bases de données relationnelles s'est longtemps résumée au stockage de chaînes de caractères. Actuellement on peut voir au moins deux évolutions dans la gestion de XML: - Le stockage du XML dans les bases de données relationnelles fait l'objet d'optimisations plus adaptées, avec la création d'un type XML propre dans les bases de données (Arbres binaires). - La standardisation de fonctions de gestion du XML dans le langage SQL, ainsi que des recommandations pour l'implémentation de XQuery, via les standards ANSI/ISO, SQL/XML:2003 et SQL/XML:2006 commencent à être développées dans les SGBDR. L'implémentation de fonctionnalités XML reste néanmoins assez limitée, et la prochaine étape attendue reste le support de XQuery. Au niveau du type XML, seul PostgreSQL propose une solution optimisée avec une structure de données (des arbres binaires) et des index adaptés. En termes de fonctions XML, on retrouve à peu près les mêmes fonctionnalités dans MySQL et PostgreSQL: génération, importation et accès en XPath au XML. MySQL se distingue néanmoins par l'apport d'un mécanisme de mise à jour des données en XPath. Pour les deux solutions, il n'existe pas de support de XQuery, et le langage d'interrogation demeure SQL. Pour l'accès aux données depuis java, les pilotes JDBC sont utilisables mais ils ne sont pas optimisés pour le traitement d'un modèle de document XML. De manière générale, la gestion de documents XML par l'intermédiaire d'une base de données relationnelle n'est pas adaptée à l'utilisation des API XML Les middlewares Les middlewares ou applications intermédiaires sont utilisés pour le stockage des documents XML dans les bases de données relationnelles, ou pour la manipulation du XML sous forme 22

23 d'objets. Nous nous intéressons ici au premier type uniquement. Les applications intermédiaires permettent de manipuler les SGBDR de la même façon que les bases de données XML natives. Les solutions prennent en charges deux aspects: le stockage du XML dans les tables du SGBDR, et la traduction des requêtes en langage XML vers le SQL. Parmi les solutions existantes on distingue celles qui ne nécessitent pas la déclaration préalable d'un schéma pour le stockage de documents /collections XML, et celles implémentant les standards XML d'accès aux données (XPATH, XQuery). Dans ce domaine, seul pf/tijah permet de se passer d'une déclaration préalable du schéma des documents XML. La solution intègre le middleware PathFinder qui permet le stockage en base de données de documents XML, et la traduction de requêtes XQuery et XPath en requêtes SQL. Pf/ Tijah quand à lui intègre la gestion de la recherche plein texte en XQuery. Les fonctionnalités de Pf/Tijah sont actuellement implémentées dans MonetDB/XQuery, et aucune facilité n'est faite pour permettre l'intégration dans un autre SGBDR. Seul un article sur l'intégration 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é étudiée plus avant. Néanmoins l'étude de MonetDB/XQuery a été réalisée parmi les solutions de bases de données XML, l'intégration de pf/tijah étant transparente. 23

24 2.2 Une pluralité de formats, standards et protocoles Les API java La première API java à avoir été développée à des fins de standardisation des accès aux bases de données XML était l'api XMLDB. Depuis l'arrêt des travaux de XML:db initiative, l'évolution du standard est arrêtée et les API spécifiques aux solutions se développent. Pour les solutions qui ont implémenté l'api XMLDB, comme exist, des évolutions ont été apportées 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 données XML natives. Le projet de recommandation est supporté par les principaux concepteurs de bases de données XML propriétaires. La recommandation définitive date du mois de mars Dans les solutions "open source" l'implémentation est cependant loin d'être généralisée. Pour les principales solutions étudiées: exist BDB XML Xindice BaseX Sedna MonetDB/X QUERY - xml:db API oui non Oui Non Oui Non - XQJ (JSR 225) (en développem ent) - autres Non API Java dbxml, Ruby, PHP,.NET non Non Non non Non Non API Java. Illustration 4: Revue des API utilisées dans les bases de données XML C, Php, python,.net, Scheme. XRPC(java/j avascript), CGI binding (.xq), MAPI Les formats de communication Il existe deux modes possibles pour l'utilisation d'une base de donnée XML : les bases de données embarquées, et les bases de données fonctionnant sur le mode client-serveur; certaines bases supportant les deux modes de fonctionnement. Pour les bases de données embarquées seule une API permet d'effectuer des transmissions de données. Pour les bases fonctionnant sur le mode client-serveur, différentes approches existent. Du protocole binaire basé sur la manipulation de "sockets", aux protocoles orientés services web : SOAP, REST, XML-RPC... À noter l'engouement naissant pour le protocole de publication Atom 24

25 (APP), équivalent à WebDav mais basé sur une architecture REST. Le tableau suivant établit les implémentations des différentes stratégies de communication en fonction des solutions étudiées: - Mode de fonctionnement exist Mode embarqué, mode serveur. BDB XML Mode embarqué Xindice BaseX Sedna MonetDB/ XQUERY Mode embarqué et client-serveur Mode Serveur Mode 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: Implémentation des statégies de communication par base de données XML Les dialectes XQuery Pour la consultation des ressources stockées dans les bases de données XML natives, les différentes solutions implémentent des standards W3C à différents niveaux de conformité, ainsi que des technologies d'accès et de modification propres. Les standards les plus couramment implémentés 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 récemment l'objet de brouillons du W3C, enfin des solutions spécifiques aux applications. Un langage de recherche en texte intégral a été recommandé par le W3C, mais les recommandations n'ont pas encore abouti. Selon les solutions des dialectes spécifiques ont été mis au point, ou les premières recommandations sont déjà implémentées. Des dialectes encore marginaux dans les bases de données XML tendent à se développer pour résoudre des situations variées, tel XQueryP(Procedural XQuery) ou XQueryD (D pour Distributed: interrogation de plusieurs bases distantes au sein de requêtes XQuery). 25

26 L'implémentation de XQuery dans les bases de données XML est testé par la XQuery Test Suite (XQTS) du W3C. - XUPDATE (xml:db) - XQUERY 99.4% (XQTS) exist BDB XML Xindice BaseX Sedna MonetDB/X QUERY Oui Non Oui Non Oui Non 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) - XQUERY FT Non(autre) (en développement) Non Non (autre) Non (autre) Oui oui Non Non Partiel Non Non (autre) Illustration 6: Implémentation de XQuery par base de données XML Organisation des ressources La possibilité d'organiser les documents dans les bases de données XML natives varie selon les solutions : on trouve la notion de base de données (unique ou multiple), de collection (unique, multiple, emboîtable), de document (comme unité, ou sous-arbre d'un unique document). Pour les solutions étudiées: - Hiérarchie de collections - Instances multiples de bases de données Oui exist BDB XML Xindice BaseX Sedna MonetDB/X QUERY Non (Présence de "containers": 1 niveau de hiérarchie.) Oui Non Non (1 niveau) Oui Non Oui Oui, mais une bdd = 1 document. Non Non, 1 niveau Non 26

27 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 données XML. Différents constats ont pu être faits lors de l'analyse des systèmes de stockage des documents XML: La faible présence de l'api parmi les solutions étudiées ne permet plus de garantir les ambitions de réalisation d'une interface standardisée pour les différentes bases de données XML. La mise en place d'une API concurrente XQJ, appelée à devenir une référence pour l'exécution du XQuery dans les applications java, semble constituer une alternative plus consensuelle car elle favorise davantage l'utilisation des technologies XML. L'arrêt des activités de l'xml:db initiative a entraîné un arrêt 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 dernière caractéristique n'est pas très répandue dans les bases de données XML natives. La tendance générale de normalisation des communications semble s'orienter vers les protocoles et architectures de services web au dépend des API java. On remarque notamment la forte présence de SOAP qui a été normalisé par le W3C, et REST basé sur le protocole HTTP. 3.2 Une dépendance de Notix avec exist L'organisation des ressources dans exist utilise une répartition des documents en souscollections imbriquées. Au niveau de Cocoon, cette organisation se traduit par l'utilisation de chemins reflétant cette structure logique. On a par exemple: xmldb:notix/db/base/0001/base xml Dans cet exemple, plusieurs caractéristiques propres à exist apparaissent : 27

28 La désignation d'une instance de base de données "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 données correspond à un simple "/" ou au nom d'un conteneur. L'imbrication des collections "Base" et "0001". L'implémentation des collections est toujours assez peu répandu parmi les solutions libres, et l'imbrication de collections est une spécificité de exist. La répartition des notices par collection de 1000 unités est une organisation des documents qui vise à optimiser les performances d'exist. Ce type d'organisation n'est pas nécessaire, ni parfois même conseillé, dans les autres bases de données. L'utilisation de chemins pour accéder aux ressources XML stockées dans exist produit une dépendance de Notix vis à vis du système de stockage XML exist. Alors que l'ensemble des opérations 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 système de stockage nécessitent de manipuler explicitement l'arborescence des collections propres à un système. Le mécanisme général de composition des URL nécessite de déclarer à de nombreux endroits dans Notix les patrons d'url établissant la conversion entre les requêtes de l'utilisateur et l'accès à un document dans exist en vue de son traitement. La multiplication de ces opérations constitue un frein important aux projets d'évolution de la solution du système de stockage des documents XML. 3.3 Mélange des logiques de traitement et de stockage Chaque pipeline de Notix qui exécute une opération sur un ou plusieurs documents XML réalise avant chaque traitement le mécanisme de composition des URL d'accès aux ressources. Ce mécanisme est partiellement factorisé par l'intermédiaire de l'action XMLDBURL, mais pas pour tous les pipelines. La composition des URL est alors intégrée aux scripts serverpages ou flowscript. Dans ce cas de figure, les scripts combinent globalement trois rôles: 28

29 La composition des URL. Les opération d'accès et de stockage des notices. Les traitements et la génération de contenus. Cette démarche est insatisfaisante car elle produit des scripts complexes et difficiles à appréhender. La gestion des URL dans l'application s'ajoute aux opérations de traitements ce qui réduit la lisibilité des scripts. Par ailleurs, le dispositif de composition des URL est globalement dispersé, et rend difficile le projet d'implémentation d'un autre système de stockage que exist. L'usage du fichier cocoon.xconf d'une part, et de la variable globale de sitemap d'autre part, génère une multiplication des opérations nécessaires à la composition des URL vers les ressources XML, et rend nécessaire ces opérations avant chaque traitement, ce qui entraîne un manque de lisibilité et une fermeture aux évolutions Répétitions des algorithmes dans l'application Un certain nombre d'opérations élémentaires sont exécutées de manière récurrente 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 réciproquement. 29

30 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 chaînes de caractères 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 opération d'énumération des collections et des ressources d'une collection. La création d'une base documentaire. Etc. Ces opérations sont exécutées 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'intermédiaire de la définition de fonctions. Cette organisation produit une répétition des algorithmes qui rend la maintenance difficile, favorise les risques d'erreur et rend difficile l'harmonisation générale des stratégies de l'application. Notix ayant été développé par plusieurs personnes, et dans des périodes de temps successives, on rencontre aussi des algorithmes réalisant des tâches similaires avec des stratégies différentes, notamment pour les opérations de conversion des données. 30

31 4 Préconisations et réalisations 4.1 Diagnostic Masquer le système de stockage utilisé pour réduire les dépendances Création d'un pilote intermédiaire: l'api xdb La création de l'api xdb répond au besoin de garder la capacité de modifier l'interface de communication vers un système de stockage, ou le système de stockage lui-même, sans nécessiter le bouleversement de l'organisation de générale de Notix ou du contenu des scripts de l'application. L'API xdb est un dispositif générique qui permet d'encapsuler les méthodes concrètes de communication avec un système de stockage. L'API est utilisée comme interface pour l'accès au système de stockage et fournit un ensemble d'outils pour la réalisation d'opérations sur les documents. Au niveau du fonctionnement, chaque système de stockage XML est représenté par un pilote spécifique qui implémente une même classe abstraite nommée Xdb. La classe Xdb est composée majoritairement de méthodes abstraites qui prescrivent les opérations de base que les pilotes devront implémenter. Au niveau de l'utilisation de l'api, une classe nommée XdbManager s'occupe de faire le lien entre les requêtes au système de stockage faite dans Notix et le pilote approprié. La création d'une source Cocoon (comme celle existante pour l'api XMLDB) permet d'accéder aux ressources par la composition d'une URL depuis un script ou un générateur Cocoon, ce qui permet de faciliter l'intégration de l'api Des patrons d'url génériques La création d'url génériques répond au besoin d'accéder aux documents XML selon une organisation logique des ressources sans pour autant rester dépendant du système de stockage utilisé. Le principe adopté pour la constitution de chemins génériques est de distinguer des adresses logiques correspondant à des ressources définies, et d'encapsuler la logique de composition des chemins réels en fonction du système de stockage utilisé. Les URL génériques d'accès aux documents XML ont été conçu pour faciliter les accès par 31

32 base documentaire. Le patron d'url est le suivant: "xdb:unebase/chemin" Les chemins peuvent être les suivant: Une notice: "xdb:unebase/unebase xml" Un rapport d'alimentation: "xdb:unebase/rapport/unebase-date.xml" un gabarit de notice: "xdb:unebase/_unebase.rdfs" Une notice rejetée non valide: "xdb:unebase/non-valides/unebase xml" Une notice rejetée en double: "xdb:unebase/doublons/unebase xml" Afin d'accéder 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 réelle de la base à partir de la racine de l'instance par défaut. Par exemple: "xdb:/listes/uneliste.rng". La logique d'encapsulation des processus de composition de l'url concrète d'accès aux ressources permet une grande souplesse dans la variété des chemins. De nouveaux patrons d'uri peuvent facilement être implémentés, sur la base de nouvelles conventions d'uri génériques Un dispositif central de configuration La mise en place d'un dispositif central de configuration du système de stockage répond au besoin de configurer les instances du système de stockage en évitant la dispersion des paramètres de configuration, en rendant indépendant de Cocoon le paramétrage des instances, et en permettant la reproduction des fonctionnalités multi-instances pour des solutions qui ne disposent pas de cette fonctionnalité nativement. Le système de configuration centralisée du système de stockage consiste à déclarer l'ensemble des instances manipulées dans Notix dans un fichier de configuration XML unique. Le fichier de configuration "XDBConfig.xml" permet de déclarer plusieurs instances, mais ajoute aussi la possibilité de déclarer plusieurs systèmes de stockage. Ainsi le système de configuration permet de désigner plusieurs instances dans plusieurs systèmes de stockage, et offre ainsi la possibilité de reproduire la fonctionnalité d'instances multiples d'exist pour les systèmes de stockage qui ne l'implémentent pas, via la déclaration d'un même système de stockage plusieurs fois. Cette stratégie de configuration du système de stockage a aussi pour effet de permettre l'implémentation de systèmes de stockage multiples, disposant chacun de paramètres de configuration propres, ce qui ouvre la possibilité de disposer en même temps d'un système de stockage embarqué et d'un système de stockage distant. Cette possibilité de configuration permet 32

33 par ailleurs de se passer du paramètre de configuration des instances du sitemap Cocoon. Au niveau du fonctionnement, le fichier de configuration permet de déclarer un système de stockage en lui associant un pilote de l'api xdb. Lors du démarrage de Notix, l'api est initialisée et charge les pilotes déclarés. Par la suite, chaque pilote peut interpréter selon ses besoins le contenu des éléments de configuration restant. Au démarrage de Notix, les bases "Groupe" et "Utilisateur" sont créées automatiquement sur l'instance par défaut notix. Afin d'encapsuler ce comportement, un paramètre de configuration des instances permet de désigner une instance par défaut, qui sera utilisée pour la création automatique des bases. La base par défaut est la base interrogée lors de l'omission de la base dans la composition de l'url d'une ressource. L'exemple suivant présente la configuration de 4 instances exist utilisant 3 bases exist différentes et 3 dispositifs de communication: REST, XMLDB embarqué, et XMLDB distant. <xdb-config> <!-- exist-rest --> <xdb-system class="xdbrestexist" url=" :8088"> <xdb-instance name="notix" user="admin" pass="admin" default="default"/> </xdb-system> <!-- exist-xmldb distant--> <xdb-system class="xdbxmldbexiststdl" url=" :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> <!-- exist-xmldb embarquée--> <xdb-system class="xdbxmldbexistembd" url="embedded"> <xdb-instance name="instance3" user="admin" pass="admin"> <xdb-parameter name="create-database">true</xdbparameter> 33

34 <xdb-parameter name="configuration">/home/notix/web- INF/xmldb/instance3.xml</xdb-parameter> <xdb-parameter name="database-id">instance3</xdbparameter> </xdb-instance> <xdb-instance name="instance4" user="admin" pass="admin"> <xdb-parameter name="create-database">true</xdbparameter> <xdb-parameter name="configuration">/home/notix/web- INF/xmldb/instance4.xml</xdb-parameter> <xdb-parameter name="database-id">instance4</xdbparameter> </xdb-instance> </xdb-system> </xdb-config> Augmenter la lisibilité du dispositif d'accès aux ressources XML Une utilisation plus simple des URL d'accès aux ressources La mise en place d'un processus plus simple de gestion des URL des ressources XML répond aux besoins de simplification du mécanisme de composition des URL, d'amélioration de la lisibilité de l'application, et d'une séparation claire entre les logiques de communication avec le système 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 génériques pour accéder aux ressources permet d'encapsuler la logique concrète de composition des chemins, et permet dans le même temps d'encapsuler la gestion des instances et le stockage de la liste des bases de données documentaires de Notix. L'accès aux ressources ne nécessite que le nom de la base, l'identifiant du document, et un contexte, qui permettent de déduire sans traitements supplémentaires les URI génériques 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:parameter name="base" value="{1}"/> <map:generate src="{collection}_{base}.rdfs"/> 34

35 est simplifié par: <map:match pattern="*/schema*"> <map:generate src="xdb:{1}/_{1}.rdfs"/> De la même manière: <map:match pattern="utilisateur/*.xml"> {1}.xml"/> <map:select type="simple"> <map:parameter name="value" value="{global:exist-url}"/> <map:when test=""> </map:when> <map:generate src="xmldb:notix:///db/utilisateur/ <map:otherwise> <map:generate src="xmldb:notix://{global:exist-url}/ notix/xmlrpc/db/utilisateur/{1}.xml"/> </map:select> s'écrit désormais: </map:otherwise> <map:match pattern="utilisateur/*.xml"> <map:generate src="xdb:utilisateur/{1}.xml"/> Une syntaxe alternative en langage java La disponibilité d'une syntaxe java (alternative à l'utilisation d'une source Cocoon) pour les communications avec le système de stockage des notices répond aux besoins de réaliser des opérations complexes, d'accroître la lisibilité générale des scripts de Notix, et d'encapsuler certains traitements de Notix pour faciliter l'implémentation des évolutions du standard XQuery. La syntaxe java d'accès à une ressource XML suit le même schéma que les patrons d'url génériques, en distinguant l'accès par base documentaire de l'accès sur l'instance par défaut. La syntaxe est la suivante: XdbManager xdbm = new XdbManager("Unebase"); Document doc = xdbm.getxml("unebase xml"); Le format d'échange de l'api xdb est DOM, car la majorité des besoins d'accéder à des documents XML dans les scripts correspond à la nécessité de réaliser des traitements dans ce format. Néanmoins, des méthodes permettent de disposer du contenu d'un document en SAX, sous 35

36 forme de flux (InputStream), ou encore de chaînes de caractères. L'implémentation de ces opérations dans l'api xdb permet d'unifier les méthodes de conversion employées et d'optimiser les traitements nécessaires en fonction du mode de communication ou du système de stockage concret. La classe XdbManager fournit également des méthodes pour la plupart des opérations sur le système de stockage réalisé dans Notix comme lister des collections ou des ressources dans une collection, et les opérations de mise à jour et d'effacement d'un document. L'implémentation des opérations éxécutant des requêtes XQuery dans les pilotes de systèmes de stockage est justifiée par les différences existantes d'implémentations du standard dans les différents systèmes de stockage XML. L'encapsulation des requêtes XQuery permet par ailleurs de ne pas exclure définitivement la possibilité d'utiliser des requêtes SQL/XML si la technologie devenait pertinente pour une utilisation dans Notix. La liste des opérations 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) Un dispositif simplifié de gestion des bases documentaires L'implémentation d'un dispositif simplifié de gestion des bases documentaires répond aux besoins de simplifier les scripts de Notix, et d'encapsuler les variations entre les différents systèmes 36

37 de stockage. Le dispositif simplifié de gestion des bases documentaires est un ensemble de méthodes permettant la création de bases à partir de la syntaxe java. Les principales méthodes sont les suivantes: Une méthode de création de base documentaire. Cette méthode est disponible sans création d'instance de l'objet XdbManager. XdbManager.createDb(NomInstance, Nombase, documentrdfs) Une méthode de suppression d'une base documentaire. Cette méthode n'efface pas les index de la base cible, mais supprime simplement le fichier RDFS, conformément au comportement actuel de Notix. new XdbManger(Nombase).removeDb() Un ensemble de méthodes 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 caractéristiques d'une base XdbManager.getNotixInstanceList() // permet d'obtenir une liste des instances configurées Le dispositif simplifié de gestion des bases documentaires exécute automatiquement la réinitialisation de la liste des bases. Cette fonctionnalité permet de soulager les scripts de Notix, et d'ancrer ces enchaînements d'opérations dans l'api pour qu'ils ne soient plus soumis à l'erreur Factoriser les opérations redondantes La création d'une bibliothèque java pour regrouper les opérations de conversion de format est une réponse aux besoins de limiter la répétition des algorithmes redondants dans les scripts, et d'instaurer une stratégie unique pour chaque opération de conversion, afin d'éviter les erreurs et de faciliter la maintenance de l'application. Les méthodes contenues dans la bibliothèque sont les suivantes: 37

38 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 méthodes globales java pour accéder aux méthodes 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 bibliothèque java pour les opérations de conversion constitue une initiative d'optimisation des algorithmes dans Notix. A ce titre, la bibliothèque constitue un précédent qui pourra être potentiellement reproduit pour d'autres algorithmes de l'application Implémentation de HTTP/REST Le choix d'implémenter une interface HTTP/REST, alors que l'api xdb rend mineurs les inconvénients liés à l'utilisation de l'api XMLDB, correspond à une volonté de disposer d'une interface pérenne, stable, et standard vers exist. La principale motivation pour l'implémentation 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 montée en popularité de l'api XQJ permettent d'envisager ce scénario. L'implémentation de REST constitue donc d'abord l'assurance de disposer d'une stratégie de communication pour laquelle le support de la communauté exist semble pérenne. En second lieu, l'implémentation de HTTP/REST a été choisie pour sa simplicité, sa clarté, et son potentiel de réutilisation. Le principe de REST consiste à employer les verbes HTTP sur une ressource désignée par une URL. Les verbes HTTP (GET, PUT, POST, DELETE, HEAD) couvrent les opérations de base nécessaires à la gestion des documents et offre la possibilité d'envoyer des requêtes XQuery avec le verbe POST. A la suite d'une requête, le serveur HTTP renvoie une réponse sous la forme d'un code HTTP. Par exemple 201:Created; 401:Unauthorize. L'implémentation d'une interface HTTP/REST consiste donc essentiellement à manipuler un client HTTP, ce qui assure sa simplicité. 38

39 4.2 L'API xdb Le patron de conception "stratégie", pour l'implémentation de nouveaux pilotes Le patron de conception stratégie consiste à "définir une famille d'algorithmes, encapsuler chacun d'eux, et les rendre interchangeable. [Le patron de conception] permet à l'algorithme de varier indépendamment des clients qui l'utilisent" 13. Pour l'api xdb, la famille d'algorithmes créée est celle des pilotes concrets des systèmes de stockage. Lorsqu'une requête est effectuée via la classe XdbManger, celle-ci charge le pilote approprié et confie la réalisation de l'opération demandée à ce pilote. Chargement du pilote à l'instanciation de la classe XdbManager: public XdbManager(String base){ this.pass); //Recherche de la base dans NotixBaseList TreeMap<String, String> basemap = XdbManager.notixBaseList.get(base); // Initialisation des paramètres 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, } Exécution d'une requête: public Document getxml(string chemin){ return xdb.getdoc(this.instance, this.base, chemin); } Une hiérarchie de classes qui favorise l'utilisation des standards Chaque pilote concret de système de stockage hérite de la classe abstraite xdb. Pour 13 Eric Freeman, Elisabeth Freeman, Design Patterns Tête la première. Paris : Editions O'Reilly. 644p. (page 24) 39

40 l'implémentation des pilotes une logique d'héritage a été adoptée qui permet de favoriser la réutilisation des méthodes des interfaces de communication indépendamment du système de stockage qui les implémente. Cette hiérarchie de classes a pour objectif de favoriser au maximum la réutilisation du code en exploitant la généricité des API et des dispositifs de communication. Pour l'implémentation de HTTP/REST, l'exécution des méthodes génériques du client HTTP est implémentée dans une classe XdbRest héritant de la classe Xdb. A un niveau inférieur, la classe XdbRestExist hérite de la classe XdbRest et implémente toutes les méthodes spécifiques à exist, comme par exemple la composition des requêtes XQuery, et la composition des chemins d'accès concrets aux ressources. Pour l'implémentation de l'api XMLDB, le même dispositif a été mis en place avec une première classe d'héritage XdbXmldb qui se limite à l'exécution des opérations standards de l'api, recommandées par la XML:db initiative. Pour l'api XMLDB, un troisième niveau a cependant été ajouté sous la classe XdbXmldbExist (qui hérite de XdbXmldb). Il s'agit de l'implémentation des deux pilotes pour accéder à un exist distant et un exist embarqué. Les deux pilotes ne se distinguent que par leurs mécanismes de composition des URL d'accès aux documents. Les deux classes héritent donc des mêmes classes parentes, et se contentent de redéfinir la composition des URL. Illustration 7: Diagramme descriptif de la hiérarchie de classe de l'api xdb 40

41 4.2.3 Le dispositif de configuration et de chargement des pilotes L'ensemble des éléments de configuration des systèmes de stockage se trouve dans le fichier "XDBConfig.xml". Au démarrage de Notix l'api xdb est initialisée par l'appel de la méthode globale "XdbManager.initDbs()". L'exécution de cette méthode produit les actions suivantes : Le fichier de configuration XDBConfig.xml est chargé en mémoire sous la forme d'un document DOM. Le document est parsé, et pour chaque instance configurée les opérations suivantes sont réalisées : Le nom de l'instance est ajouté à la liste globale des instances notixinstancelist. Le nom du pilote déclaré 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+"\" (implémentation de Xdb)"); } Une instruction d'initialisation de la base de données est envoyée au pilote avec les paramètres de configuration de la base (les éléments "xdb-parameter"). NodeList xdbinstanceparameters = xdbinstance.getelementsbytagname("xdb-parameter"); // On recueil les paramètres de configuration de l'instance for (int k = 0; k < xdbinstanceparameters.getlength(); k++) { 41

42 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 démarre les instances avec leurs paramètres xdbimpl.initinstance(properties); Une instruction est envoyée au pilote pour obtenir la liste des bases documentaires présentes dans l'instance. Chaque base renvoyée est stockée dans la liste des bases documentaires notixbaselist avec ses données d'identification, l'instance à laquelle elle appartient, et le pilote nécessaire à son accès. La méthode d'initialisation des bases est exécutée au démarrage de l'application, à la création d'une base documentaire, et à la suppression d'une base documentaire Le mécanisme de composition des URL Le mécanisme de composition des URL de l'api xdb repose sur 3 éléments, le fichier de configuration XDBConfig.xml qui permet la configuration des instances, le dispositif de chargement du pilote concret du système de stockage, et enfin la méthode concrète de composition du chemin. Lorsqu'une requête est adressée à la classe XdbManager, celle-ci récupère 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 envoyées : le nom de l'instance, le nom de la base, le chemin, et les informations spécifiques à l'opération en cours (par exemple un document DOM pour un enregistrement). Exemple : new XdbManager("Unebase").getXml("Unebase xml") Appel le pilote concret avec: xdb.getdoc("uneinstance", "Unebase", "Unebase xml"); Une fois les informations en sa possession, le pilote concret transforme la requête envoyée 42

43 selon les patrons d'url qui lui conviennent en appelant des méthodes internes. Ci-dessous le mécanisme 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 à accéder à une resource if (chemin.endswith(".xml") chemin.endswith(".rng") chemin.endswith(".rdfs")){ // Si on cherche à accéder à une notice if (chemin.matches(base+"-[0-9]{7}?\\.xml")){ //On ajoute les sous-collections spécifiques à 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/noticesrejetees/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 accède à une collection: on recopie le chemin if ( chemin!=null &&!chemin.equals("") ){ collection = collection + chemin + "/"; //Sauf si il est vide } else { //Ne fait rien } } return " "/" + instance + collection; } L'API XMLDB, à la différence de REST, nécessite la désignation d'une collection avant d'atteindre une ressource. La composition du chemin s'exécute donc en deux temps avec getresource() puis seulement dans un second temps composepath(). 43

44 4.3 Intégration à Cocoon L'utilisation d'un pilote unique, la classe XDBSource Pour permettre une meilleure intégration à Cocoon, une source Cocoon a été développée. Les classes XdbSourceFactory et XdbSource sont déclarées dans le fichier cocoon.xconf et permettent de réaliser une requête vers l'api xdb sous la forme d'une URL commençant par le protocole "xdb:". Le fonctionnement de la Fabrique de Source Cocoon XdbSourceFactory consiste à analyser l'url et à diviser les différentes parties logiques (la base, le chemin) pour les soumettre à la Source qui s'occupera alors d'exécuter la requête 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'intérêt de développer une source Cocoon, en dehors des commodités apportées par les URL d'accès aux ressources, est la possibilité d'exploiter le système de mise en cache Cocoon. Pour exploiter le mécanisme de mise en cache d'une source Cocoon, celle-ci doit implémenter la méthode getvalidity() qui renvoie la date de dernière 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 système de mise en cache des sources Cocoon ne fonctionne cependant que lorsque la source est appelée depuis un composant de sitemap (par exemple FileGenerator). 44

45 4.3.2 La mise en place d'un système de cache Pour conserver un niveau de performance satisfaisant lors des accès aux documents, Cocoon emploie un système de cache. Il existe néanmoins 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 système de mise en cache des gabarits RDFS. La fonctionnalité de mise en cache est utilisée uniquement pour les gabarits RDFS, d'abord parce que ceux-ci sont très souvent sollicités 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 récupération des document rdfs en cache, on Procède en 3 étapes: * - On vérifie d'abord si le fichier demandé est un rdfs * - On vérifie ensuite si la base demandée existe * - On vérifie 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 présent en cache 45

46 if(notixbaserdfs.get(this.base)!=null && notixbaserdfslastmod.get(this.base).equals(this.getlastmodificationtime(chemin).gettime( ))){ // L'enregistrement des documents en cache est réalisé à 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 système de mise en cache est implémenté directement dans la classe xdbmanager. Le premier accès au gabarit RDFS d'une base provoque l'enregistrement du document au format DOM et de la date de dernière modification de ce document dans une variable globale de l'application. A chaque nouvel appel du gabarit la classe xdbmanager envoie une requête au système de stockage qui contient le document pour connaître la date de dernière modification du gabarit. Si cette date est différente de celle dont il dispose en mémoire, xdbmanager transmettra la requête au système de stockage, sinon le document en mémoire est envoyé en réponse. 46

47 4.4 Les tests unitaires Pour diriger le développement de l'api xdb, un ensemble de tests unitaires a été créé. Ils permettent de tester la majorité des fonctionnalités de la classe xdbmanager pour chaque pilote existant. Les tests unitaires sont intégrés à l'api xdb, et sont amenés à évoluer avec celle-ci. De manière générale, l'emploi des tests unitaires a permis de mieux contrôler le processus de conception de l'api. public void testinitxdbs() { XdbManager.resetStatics(); asserttrue("initialisation des base", XdbManager.getNotixBaseList()==null ); XdbManager.initXDBs(); asserttrue("initialisation des base", XdbManager.getNotixBaseList()!=null ); 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); 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

48 4.5 Limites du développement de l'api xdb. La création de l'api xdb s'est déroulée dans la dernière partie de mon stage, et l'implémentation dans Notix n'était pas totalement achevée à la fin du temps de la mission. Deux tâches notamment ont été envisagées sans avoir pu être accomplies : Les tests de montée en charge et de performance. Le recours à l'api xdb provoque de nombreuses créations d'instances des pilotes de base de données potentiellement coûteuses en mémoire. La réalisation de tests de performance, et l'analyse de la consommation des ressources de l'application lors de la montée en charge permettrait d'évaluer la pertinence du dispositif actuel et le besoin éventuel d'une gestion plus fine de la création des instances de pilotes. Un dernier cycle de développement dédié à l'optimisation du code. Par exemple, l'api pourrait bénéficier de la création d'une classe d'exceptions dédiée. 48

49 Conclusion: La mission que j'ai effectuée au PANDoc consistait à étudier les alternatives envisageables au système de stockage XML de Notix. En vue d'améliorer potentiellement les performances générales 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 données exist d'autre part, m'ont progressivement amené à réaliser l'évaluation des capacités d'évolution de Notix dans son mode de gestion des documents XML. Le manque de certitudes sur la pérennité de l'api XMLDB, et la dépendance existante entre la base de données 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 générique, 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 reçu lors du Master 2 ID. 49

50 Bibliographie: Ronald Bourret, XML and Databases[En ligne]. [Consulté en août 2008]. Eric Freeman, Elisabeth Freeman, Design Patterns Tête la première. Paris : Editions O'Reilly. 644p. 50

51 Annexes ANNEXE 1 : Architecture de Notix...52 ANNEXE 2: Traitement d'un document XML dans un script serverpages...53 ANNEXE 3: Étude des systèmes de stockage XML...56 ANNEXE 4: Étude des besoins

52 ANNEXE 1 : Architecture de Notix 52

53 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=" xmlns:sdx=" xmlns=" xmlns:i18n=" > <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 méthode 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

54 <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 paramètre est mal passé côté 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'implémentation DOM Exist pose problème 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); } <!-- S'il y a des modifications --> if (request.getparameter("value")!= null) { String[] values=request.getparametervalues("value"); String xml=""; 54

55 xml +="<rng:choice xmlns:rng=\" 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">problème dans l'écriture de la liste</div> tosax(e); } } </xsp:logic> etc. </xsp:page> 55

56 ANNEXE 3: Étude des systèmes de stockage XML 1 Le stockage des données XML: Trois grandes approches existent 14 : les bases de données XML natives les bases de données relationnelles (SGBDR) hybrides ou gérant un type XML. les bases de données relationnelles permettant de stocker des documents via un «mapping» des données (XML-Enable) ( ou l'usage de «middleware» pour faire le lien entre XML et SGBDRs) {Portée de cet état de l'art: Open-Source, multi-platformes, projets en activité} 1.1 Les bases de données XML natives: Caractéristiques générales: Les bases de données XML natives se distinguent des SGBDR par 3 caractéristiques: elles préservent la structure physique des documents (éléments, attributs, entitées,...) elles permettent de stocker des documents sans déclaration préalable du schéma des documents. elles permettent d'accéder aux documents à partir des API spécifiques à XML (Xpath, XQUERY). Par ailleurs les bases de données XML natives permettent la création de collections ( assimilables à des dossiers dans un système de fichier). API Java Concernant les bases de données 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 données XML native. Néanmoins l'implémentation dans les solutions est loin d'être généralisée ni aboutie. Standard XML d'accès aux données Pour la consultation des ressources stockées dans les bases de données XML natives, les différentes solutions implémentent des standards W3C à différents niveaux de conformité, ainsi que des technologies d'accès propres. Les standards les plus couramment implémentés sont Xpath 1.0 et XQUERY 1.0, suivis de Xpath 2.0, XQUF (XQUERY Update Facility, pour la mise à jour des données), XQFT (XQUERY FullText, pour la recherche en plein texte), et plus rarement XQUERYD (D pour Distributed: interrogation de plusieurs bases distantes au sein de requêtes XQUERY). L'implémentation de XQUERY dans les bases de données XML est testé par la XQUERY Test Suite (XQTS) du W3C

57 Protocoles de communication En termes d'intégration, des bases de données XML natives, il existe deux modes: les bases de données embarquées, et les bases de données fonctionnant sur le mode client-serveur; certaines bases supportant les deux modes de fonctionnement. Pour les bases fonctionnant sur le mode clientserveur, différents protocoles de communication sont implémentés selon les bases de données, du protocole binaire basé via la manipulation de socket, jusqu'aux protocoles orientés 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 données XML natives varie selon les solutions: on trouve la notion de base de données (unique ou multiple), de collection (unique, multiple, emboitable), de document (comme unité, ou sous-arbre d'un unique document). Même à un niveau logique, la création de collections imbriquées n'est pas toujours possible Solutions existantes: Les bases de données XML natives écartées: OrientX (Développée uniquement pour Windows) Xbird (Solutions non disponible) Les principales bases de données XML natives actives open sources sont les suivantes: exist ( ) Berkeley DB XML ( ) Xindice ( ) ressources: BaseX ( ) Sedna ( ) MonetDB/XQUERY ( ) 1.2 Description des solutions: Exist Exist a été créé en 2000 par Wolfgang Meier, sur la base d'articles scientifiques décrivant des algorithmes performants d'accès aux données. Exist est écrit en Java. D'abord conçu pour l'accès aux documents(«documentcentric») la base de données XML native se spécialise progressivement dans l'accès aux données («Data centric»). Actuellement exist est en version 1.2, et est distribué sous licence LGPL. XQJ. La solution implémente l'api Java XML:DB, et développe actuellement le support de l'api La solution implémente les standards XML XQUERY 1.0, Xpath 1.0 et 2.0, et XQUERYFT. Pour la réalisation des mises à jour, exist fait appel à XUPDATE, et à une extension d'xquery en cours de mise en conformité avec XQUF. 57

58 Un des point forts d'exist réside dans la forte activité de sa communauté. La liste de diffusion est très active, au moins huit développeurs travaillent régulièrement 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 Berkeley DB XML Berkeley DB XML est une base de données XML native écrite en C. Elle est distribuée sous 2 licenses, une libre et une commerciale. Le Produit Berkeley DB XML développé par SleepyCat à été acquis en même temps que la société par Oracle en Le produit est basé sur Berkeley DB, une base de donnée entité-valeur embarquée. La version actuelle datant de janvier 2007 est la La version 2.4 en version bêta devrait sortir bientôt. Plusieurs API ont été développées pour permettre l'accès à Berkeley DB XML: PHP, Ruby,.NET, Java, TCL, Ruby, Perl, Python, module apache. Pour l'accès aux données XML, BDBXML implémente xpath 2.0 et XQUERY 1.0, ainsi qu'un protocole propre de mise à jour des données dbxml. Pour la version 2.4 à venir, la solution implémentera XQUF, et plus tard sans doute XQJ. Cependant Xml:db API ne sera pas implémenté car ne prenant pas en compte la gestion des transactions. L'activité de la communauté se manifeste par le développement d'apis et les discussions sur le Forum, mais le développement de l'application n'est pas ouvert à la communauté. Il existe une version client-serveur de la solution, développée par la communauté sous le nom de NXQD (Native XMLDB Query Daemon), qui permet d'accéder à la base via SOAP. Le projet semble néanmoins peu actif, puisque la dernière version date du ( ) 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 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 gérer des hiérarchies de collections. La solution met à disposition deux API: XML:DB et Xindice XML-RPC API. L'implémentation des standards XML pour l'accès aux données fait partie des points noirs de Xindice. La solution implémente 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 véhiculées par XML- RPC. La communauté de Xindice semble avoir été importante mais les signes de vie du projet sont 58

59 rares (la dernière publication sur le site date de août 2007). La documentation est néanmoins utilisable et détaillé BaseX BaseX est développé par le Database and Information System Group de l'université de Konstanz en Allemagne. La base de donnée xml native est développée en Java. Récemment, BaseX a été étudié comme base pour la création d'un système de fichier XML, par l'équipe de recherche DISGUK. BaseX est mis à disposition sous licence BSD. La spécificité de BaseX repose sur son stockage des collections et documents dans un unique document XML. L'accès 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 donnée. En revanche, XQUERY ne bénéficie pas de ces optimisation, et le seul objectif de l'équipe pour le moment est la conformité au modèle du langage de requête (XQTS). XQUERY n'est donc pas conseillé en production. BaseX dispose d'un outil d'administration graphique des données, dont le principal atout est la multitudes de modes de visualisation. Un outil d'administration en ligne de commande existe aussi Sedna Sedna est une base de donnée XML native conçue par une équipe de recherche Russe, le MODIS (Management Of Data & Information Systems ), du département de l' ISP RAS (Institute for System Programming of the Russian Academy of Sciences). La solution a été développé à partir de La dernière version date d'octobre 2007(v 2.2). La solution Sedna est développée en C/C++, mais des API ont été écrites pour Java, Python, PHP, C,.NET, Scheme. On compte aussi un module apache et l'implémentation de xmldb de XML:DB Initiative. Par ailleurs 2 modules d'administration graphiques existent. La solution est organisée en une série de fichiers binaires, dont des fichiers pour la création et pour la suppression d'une base de données, ce qui semble problématique pour certains usages. L'accès aux données XML est possible via XQUERY. La base de donnée implémente son propre système de mise à jour des documents XML. Le projet est géré entièrement par l'équipe d'origine, et il n'y a pas de contributeurs extérieurs 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 Framework 15» MonetDB/XQUERY

60 MonetDB est une base de données relationnelle. Une version de la base de données intégrant les middlewares «path-finder»(traducteur de requête XQUERY vers SQL) et pf/tijah (moteur de recherche Plein texte), a été créée pour obtenir une base de donnée XML Native, nommée MonetDB/XQUERY. MonetDB/XQUERY est développé en C et en python. La solution est distribuée sous licence «MonetDB Public licence Version 1.1» qui est dérivée de la licence Mozilla. MonetDB/XQUERY implémente les collections, mais pas les hiérarchies de collection. L''implémentation des collections est limitée à un mode read-only, ou updatable (avec réservation d'espace à la création). On peut intérroger les ressources via Xpath et XQUERY (en partie implémenté), réaliser les mises à jour via XQUF, et réaliser des recherches en plein textes via un dérivé 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 requêtes XQUERY vers le serveur peuvent être faites via la ligne de commande, ou via le protocole d'accès SOAP. Dans les enveloppes SOAP, un protocole «xrpc» permet de faire des requêtes XQUERY distribuées (cf. XQUERYD). Informations générales: exist BDB XML Xindice BaseX Sedna MonetDB/ XQUERY - version Monet4/X QUERY License GNU LGPL - Origine du projet - Langage de développeme nt Fondé par Wolfgang Meier en Système Multi- Platformes Logiciel Libre: Oracle libre (certifié OSI) Berkeley DB (BDB) Apache 2.0 Projet dbxml donné à la fondation Apache en 2001 BSD DISG (Universit y of Konstanz ) Apache is.ispras.ru / MonetDB Public licence Version 1.1 (dérivé Mozilla) MonetDB w.cwi.nl/ Java C/C++ Java Java C/C++ C, Python UNIX, Win32 Multi- Platformes Multi- Platformes Linux, Windows, mod_apac he Linux, Windows, (32/64) - Utilisateurs *** *** ** * ** ** 60

61 - Communauté - Documentati on exist BDB XML Xindice BaseX Sedna MonetDB/ XQUERY *** ** *** * * *** *** *** *** * ** ** - Activité ***? *** ** *** *** - Maturité *** *** *** ** ** *** - Actualité *** *** ** ** ** *** Communauté : APIs : - xml:db API oui non Oui Non Oui Non - XQJ (JSR 225) (en développe ment) - autres Non API Java Java API:dbxm l (équivalen t à xmldb + gestion des transaction s), Ruby, PHP,.NET non Non Non non Non Non API Java. Php, python,.net, Scheme, socketbase client/serv er protocol XRPC(jav a/javascrip t), CGI binding (.xq), MAPI Requêtes: - XUPDATE (xml:db) Oui - XQUERY 99.4% (XQTS) 99.5% (XQTS) Oui Non 99.3% (XQTS) - XPath Oui(1,2) Oui (1,2) Oui (Librairie Xalan) (1, [2?]) - XQUF (partiel, vers un support complet) Non(autre) [ 2.4 : oui ] Non 98.8% (XQTS ) En partie Oui(1) Oui (1,2) En partie Non (autre) Non (autre) Oui 61

62 - XQUERY FT Hiérarchie BDD: - Hiérarchie de collections - Instances multiples de bases de données Divers: - Gestion des Transactions - Mode de fonctionneme nt - Interface d'administrat ion - Dispositif d'indexation exist BDB XML oui Non Partiel (ftcont ains ) Oui Oui Non (Présence de containers: 1 niveau de hiérarchie. ) Xindice BaseX Sedna MonetDB/ XQUERY Oui Oui (cf. server.xml ) Non (Pas très clair: Collection s dans l'api Java) Oui, mais une bdd = 1 document. Non Oui Non Non Oui Mode embarqué, mode serveur. (SOAP, REST, XML- RPC, WebDav, APP) Oui (Ligne de commande, Client Java, Interface Web) Dispositif d'indexatio n modulaire: Structural, Full text, Range, Embarqué. Projet Parallèle (nxqd) pour le mode serveur Non Mode embarqué et client- Serveur Oui (XML Updates) Mode Serveur: Socket Based Oui (Client Java) Noeuds textes, mots des noeuds textes, valeur des attributs, Non (1 niveau) Non (autre) Non, 1 niveau? Non Mode Server: binary based Network protocol, http et ftp via API Oui (2 clients java) Dispositif manuel d'indexatio n SOAP (XRPC [XQUER YD]) Oui (Interface Web/javas cript et ligne de commande ) Automatiq ue Nature:? 62

63 - Facilité d'utilisation exist Ngram, Spatial BDB XML Xindice BaseX Sedna MonetDB/ XQUERY «full text». Utilisation des index pour Xpath, pas pour XQUERY *** *** * ** ** *** Les bases de données Hybrides ou gérant un type XML: Caractéristiques générales: Certaines bases de données relationnelles permettent de gérer un format XML, d'autres proposent une interface similaire à une base de donnée XML native (On parle de base Hybride). Actuellement, les bases de données hybrides sont des solutions propriétaires (dbxml de Oracle et db2 de IBM). La gestion des données XML dans les bases de données relationnelles s'est longtemps résumée au stockage de chaînes de caractères. Actuellement on peut voir au moins deux évolutions dans la gestion de XML: - Le stockage du XML dans les bases de données XML natives fait l'objet d'optimisations plus adaptés, avec la création d'un type XML propre dans les bases de données (Arbres binaires). - La standardisation de fonctions de gestion du XML dans le langage SQL, ainsi que des recommandations pour l'implémentation d'xquery, via les standards ANSI/ISO SQL/XML:2003 et SQL/XML:2006 commencent à être implémenté dans les SGBDR. L'implémentation de fonctionnalités XML reste néanmoins assez limité, et la prochaine étape attendue reste le support d'xquery Solutions existantes: PostgreSQL 16 qui implémente un type XML, ainsi qu'une partie des normes SQL/XML MySQL 17 qui implémente des fonctions d'import et d'export XML sur la base d'un type chaîne de caractères PostgreSQL La version 8.3 de PostgreSQL intègre nativement un type XML et des fonctions XML 16 ; ; 63

64 conformes à certaines des spécification SQL/XML. Les fonctions XML étaient déjà présentent sous la forme d'un module depuis la version 8.1. Le type XML implémenté 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, grâce à des «Generalized Search Trees» et des «B-Trees». Les fonctions implémentées par PostgreSQL permettent la génération de XML à partir de tables SQL (xmlcomment, xmlpi, xmlelement, xmlattributes, xmlroot, xmlconcat, xmlforrest), les requêtes 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 chaîne de caractère en argument. L'opération inverse est rendue possible par l'opération XMLSERIALIZE. L'accès via une API java à la base de donnée est rendu possible par le pilote JDBC PostgreSQL. Néanmoins, les optimisations existantes dans la base de données sont perdues à l'import des données qui sont sérialisée en chaînes de caractères, et non directement traduites en SAX ou en DOM MySQL A partir de la version 5.1 MySQL intègre quelques fonctions permettant l'import, l'export et le traitement du XML. Il n'existe pas de type XML, des Chaînes de caractère ou des BLOB (Binary Long OBjects) sont utilisés 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 (grâce à l'extension lib_mysqludf_xql). Chargement d'un fichier: Accès au contenu d'un fichier via LOAD_XML, avec la possiblité de charger directement le contenus des éléments XML dans des colonnes de la base de donnée. Interrogation du XML: Possibilité d'interroger un contenu XML en Xpath ( ExtractValue() ), et de réaliser des mises à jour sur un fragment xml ( UpdateXML() ). MySQL n'est pas entièrement conforme Xpath 1.0: certains axes ne sont pas supportés (following, following-sibling, preceding, preceding-sibling), les espaces de nom ne sont pas gérés, 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 accéder à MySQL en Java Bilan Au niveau du type XML, seul PostgreSQL propose une solution optimisée avec des arbres binaires et des index adaptés. En termes de fonctions XML, on retrouve à peu près les mêmes fonctionnalités: génération, import et accès en XPATH au XML. MySQL se distingue tout de même par l'apport d'un mécanisme de mise à jour des données en XPATH. Pour les deux solutions, il n'existe pas de support de XQUERY, et le langage d'interrogation demeure SQL. Pour l'accès aux données en mode serveur depuis java, les pilotes JDBC sont utilisables mais 64

65 ils ne sont pas optimisé pour le traitement d'un modèle de document XML. 1.3 MiddleWare Caractéristiques générales Dans le domaine du stockage des données XML, les middlewares ou applications intermédiaires sont utilisés pour le stockage des documents XML dans les bases de données relationnelles, ou pour la manipulation du XML sous forme d'objets. Nous nous intéressons ici au premier type uniquement. Les applications intermédiaires permettent de manipuler les SGBDR de la même façon que les bases de données XML natives. Les solutions prennent en charges deux aspects: le stockage du XML dans les tables du SGBDR, et la traduction des requêtes en langage XML vers le SQL. Parmi les solutions existantes on distingue celles qui ne nécessitent pas la déclaration préalable d'un schéma pour le stockage de documents /collections XML, et celles implémentant les standards XML d'accès aux données (XPATH, XQUERY) Solutions existantes: Parmi les solutions, la plupart ne sont plus maintenus, et aucune ne bénéficie d'une communauté développée. Les tableaux suivants présentent les solutions de middlewares en distinguant les solutions de mapping objet, les solutions qui semblent abandonnées, et la solution qui semble active et adaptée. Malheureusement pour cette dernière, les sources ne sont disponibles que par l'intermédiaire du projet MonetDB/XQUERY dans lequel elle est implémentée. Mapping Objet (inadapté): Produit URL Dernière activité XML-DBMS JaxMe Octobre 2006 HyperJaxB3 Mars 2008 Faible activité: Produit URL Dernière activité Minx Octobre 2002 LegoDB Juin 2002 XTAS Février 2003 Xquare Septembre 2005 En lice: Produit URL Dernière activité Pf/Tijah Février

66 1.3.3 Pf/Tijah La solution intègre le middleware PathFinder qui permet le stockage en base de données de documents XML, et la traduction de requêtes XQUERY et XPath en requêtes SQL. Pf/Tijah quand à lui intègre la gestion de la recherche plein texte en XQUERY. Les fonctionnalités de Pf/Tijah sont actuellement implémentée dans MonetDB/XQUERY (cf ), et aucune facilité n'est faite pour permettre l'intégration dans un autre SGBDR. Seul un article sur l'intégration dans PostgreSQL paru en 2004, évoque la possiblité de le faire; les sources du middleware ne sont cependant pas accessibles. Pas d'intérêt Bilan 2 - Diagnostic 2.1 Observations sur Notix Performances: forte utilisation du pseudo protocole cocoon:/ pour le stockage des données: coûteux en termes de performance. système de stockage en java, pas optimal pour les performances. Implémentation du système de stockage: couplage fort de l'application au système de stockage: classes java exist implémentant le protocole xml:db design des URI spécifique à exist et différent selon le fonctionnement en mode serveur ou embarqué pérennité douteuse du protocole xml:db: l'implémentation d'exist est une implémentation augmenté de l'api le groupe de travail sur le protocole n'existe plus, et n'a laissé qu'un brouillon de travail pour spécifications. En termes d'api, développement 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 observées En termes de performances, plusieurs solutions semblent intéressantes au delà d'exist: MonetDB/XQuery, Sedna, et Berkeley DB XML. Néanmoins il existe plusieurs obstacles à l'implémentation de ces solutions dans Notix: au niveaux du fonctionnement en mode serveur ou distant aux niveau des hierarchies des collections et des capacités multiinstances Parmi les middleware, seul Pj/Tijah offre un service intéressant en termes de performances 66

67 et d'implémentation de XQUERY. Néanmoins son implémentation en dehors de MonetDB est exclue par l'absence des sources. Plusieurs alternatives sont possibles: Conserver exist et implémenter une interface plus générique vers le système 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'implémentation des standards, et d'activité. Il s'agit par ailleurs de la solution en place actuellement pour laquelle il existe donc déjà des compétences. En outre la version 1.2 apporte le support de APP, un mécanisme d'indexation plus souple et potentiellement plus performant (modulaire). L'implémentation d'une interface plus générique répond à deux problèmes actuels de l'implémentation du système de persitance: le couplage fort existant entre l'application et le système de persitance, et l'exploitation du protocole XML:DB. Comme interface possible de remplacement, plusieurs technologies sont envisageables: l'implémentation de REST d'exist, de SOAP, de Atom Publishing Protocol. L'implémentation d'une interface générique permet d'envisager des modifcations futures du système de stockage des notices xml, en développant une interface la plus générique possible. Mettre en place MonetDB en mode serveur. MonetDB apparaît avant tout comme une solution performante. L'implémentation des standards XML est plutôt avancée (jusqu'à XQUF pour XQuery). La solution est par contre beaucoup moins bien dotée en interfaces HTTP, ne fournissant que deux protocoles internes Mapi et XRPC, le second étant basé sur SOAP. Pour mettre en place MonetDB, les aménagements suivants seraient nécessaires: implémenter XRPC via SOAP pour communiquer avec le système de stockage Mettre en place une hiérarchie à un niveau de collections pour le classement des notices (pas de hiérarchie de collections implémentées). 2 - Comparatif: xmldb, XRDBMS, middleware -> performance, communication/requêtes, références (stade de dvpt, communauté, documentation*) 3 Évaluation des solutions: Annexe: Méthodologie d'évaluation des logiciels libres: Les critères sont dérivés de la méthodologie de Bull ( et de la Méthode de Qualification et de Sélection de logiciels Open Source (QSOS ). 67

68 Barème * ** *** Utilisateurs Communauté Pas d'utilisateurs identifiés Groupe de développeur clos / Société Utilisateurs détectables via internet Communauté périphérique / contributeurs Documentation Basique Utilisateurs et développeurs Activité 0 à 3 développeurs 4 à 7 développeurs, ou fort turn-over Maturité Actualité Encore en développement, pas de version stable Le projet semble à l'abandon Version(s) stable(s), utilisable. Projet actif, mais communication/particip ation peu dense Communauté d'utilisateurs identifiés / Références Fonctionnement en communauté et outils associés Systématisé, avec contributions + de 7 développeurs Version éprouvée. Roadmap. Forte participation, nombreuses actualités 68

69 ANNEXE 4: Étude des besoins 1 - Existant: Notix est une solution de gestion des notices bibliographiques. Elle a été réalisée à partir de plusieurs composants, SDX, Cocoon, et exist pour le stockage des données XML. 1.1 Organisation du stockage: Le stockage des données XML est organisé de la manière 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 deuxième niveau: pour le stockage des notices en lots de notices, à des fins d'optimisation des accès. Notix permet de gérer le stockage des données 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 assurée par l' API XML:DB, qui a été implémentée par exist sur le modèle de l' XML:DB Initiative Intégration dans Cocoon: L'implémentation du système de stockage est visible dans: les sitemap cocoon: indication de l' URL des bases de données distantes implémentation du protocole xmldb dans les générateurs les xsp: manipulation des collections et documents (Lot.xsp). les flowscripts: Création dynamique des schémas, remplissage des formulaires, modifications par lots. la configuration de Cocoon (protocole xmldb dans cocoon.xconf) les classes java (XmlDBURL, NotixBaseList) Par ailleurs, un système de mise en cache des requêtes à exist à été mis en place dans l' API XML:DB. Cette implémentation est importante pour les performances générales de l'application. 1.3 Accès aux données, et modifications des documents: L'accès aux données et la modification des documents est rendue possible par l'utilisation de langages de requête XML: XQuery : Pour les modifications par lots, et la sélection de documents Xpath : Pour l'accès aux données des documents XQuery Full Text : Pour les requêtes de modification et de recherche (dans XQuery) Un dialecte exist de mise à jour des données intégré à XQuery Tâches ponctuelles liées aux système de stockage: Lancement de l'indexation de la base exécution d'une requête sur la base (en lecture, ou en écriture) Lancement d'une sauvegarde des bases exist Pour ces tâches, est utilisé un client java fonctionnant en ligne de commande ou avec une interface 69

70 graphique fourni par exist. 1.5 En chiffres Volume de données global: Volume de données moyen par bases: Taille moyenne (maximum) d'un document: Nombre d'accès simultanés moyen (maximum): 2 - Qualification des besoins pour le stockage des documents XML dans Notix De manière générale, l'étude du système de stockage de Notix est motivé par les besoins suivants: Prendre connaissance des solutions alternatives de stockage des données 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 pérennité et la performance des technologies et protocoles utilisés dans Notix Accès au système de stockage: Fonctionnement en mode embarqué. Fonctionnement en mode serveur. Possibilité d'utiliser une API Java pour accéder à la base et gérer les données. Possibilité de réaliser des tâches d'administration à partir d'un client extérieur à Notix pour: l'indexation l'exécution de requêtes sur les bases la planification/réalisation de sauvegardes des bases de données. Préférence pour l'adoption d'un protocole standard pour la communication entre Notix et une ou plusieurs bases distantes: actuellement XML-RPC intérêt pour REST Accès aux documents et aux données: Fonctionnalités d'ajout, de suppression, de mise à jour et de lecture des documents: via l' API Java. via un client autonome. Préférence pour l'utilisation de standards pour l'accès aux données 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 réponses du système de stockage: soit une implémentation existe soit les dispositif de stockage permettnet l'accès aux métadonnées pour la création d'un système de mise en cache Stockage des documents: Pour le stockage des documents, une hiérarchie similaire à l'existant doit pouvoir être reproduite sur la base des mêmes outils ou non (instances de bases de données, 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

71 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 données XML devra tenir compte de l'environnement actuel, et de la compatibilité des licences. La portée de l'étude se limitera donc: Aux solutions libres mettant à disposition les sources de l'application Aux solutions développées au moins pour Windows et Linux 71