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, 59000 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 60 149, 59 653 Villeneuve d'ascq cedex Année universitaire 2007/2008
Je tiens à remercier: Fabien Torre pour ses enseignements, sa disponibilité et ses encouragements, André Davignon pour sa disponibilité et ses conseils, enfin toutes les personnes du PANDoc pour leur accueil. 2
Sommaire Introduction:...4 1 Présentation...5 1.1 Environnement du stage...5 1.1.1 Le Point d'appui national documentaire (PANDoc)...5 1.1.2 Notix, une solution de gestion des notices bibliographiques...5 1.1.3 La gestion des documents XML avec exist...7 1.1.4 La communication entre Notix et exist...10 1.1.5 XML:db initiative, une tentative de normalisation des bases XML...13 1.2 Déroulement de la mission...15 1.2.1 Les évolutions de la mission...15 1.2.2 La gestion de projet...16 1.3 Méthodologie...18 1.3.1 La recherche d'informations et l'évaluation...18 1.3.2 Les cycles de développement...19 2 L'étude des systèmes de stockage XML...21 2.1 Les types de solution...21 2.1.1 Les bases de données XML...21 2.1.2 Les bases de données relationnelles...21 2.2 Une pluralité de formats, standards et protocoles...24 2.2.1 Les API java...24 2.2.2 Les formats de communication...24 2.2.3 Les dialectes XQuery...25 2.2.3 Organisation des ressources...26 3 Besoins et critique de l'existant...27 3.1 Un avenir incertain pour l'api XMLDB...27 3.2 Une dépendance de Notix avec exist...27 3.3 Mélange des logiques de traitement et de stockage...28 3.4 - Répétitions des algorithmes dans l'application...29 4 Préconisations et réalisations...31 4.1 Diagnostic...31 4.1.1 - Masquer le système de stockage utilisé pour réduire les dépendances...31 4.1.2 Augmenter la lisibilité du dispositif d'accès aux ressources XML...34 4.1.3 Factoriser les opérations redondantes...37 4.1.4 Implémentation de HTTP/REST...38 4.2 L'API xdb...39 4.2.1 Le patron de conception "stratégie", pour l'implémentation de nouveaux pilotes...39 4.2.2 Une hiérarchie de classes qui favorise l'utilisation des standards...39 4.2.3 Le dispositif de configuration et de chargement des pilotes...41 4.2.4 Le mécanisme de composition des URL...42 4.3 Intégration à Cocoon...44 4.3.1 L'utilisation d'un pilote unique, la classe XDBSource...44 4.3.2 La mise en place d'un système de cache...45 4.4 Les tests unitaires...47 4.5 Limites du développement de l'api xdb...48 Conclusion:...49 Bibliographie:...50 Annexes...51 3
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
1 Présentation 1.1 Environnement du stage 1.1.1 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. 1.1.2 Notix, une solution de gestion des notices bibliographiques 1.1.2.1 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 1 http://urbamet.documentation.developpement-durable.gouv.fr 2 http://temis.documentation.equipement.gouv.fr 5
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 2007. 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 3. 1.1.2.2 Architecture de l'application Notix est une application web java qui fonctionne sur le serveur d'application Tomcat. Trois applications libres ont été 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 3 http://admisource.gouv.fr/ 4 cf. annexe 1: Architecture de Notix 5 Littéralement, une bilbiothèque de balises. 6 Ronald Bourret, 2005. XML and Databases[En ligne]. [Consulté en août 2008]. http://www.rpbourret.com/xml/xmlanddatabases.htm 6
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. 1.1.3 La gestion des documents XML avec exist 1.1.3.1 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". 1.1.3.2 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. 1.1.3.3 L'alimentation en notices L'ajout de notices à une base documentaire se fait dans des sous-collections contenant 1000 notices. Ce nombre de notices a été choisi pour permettre d'optimiser les index lors des 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
contenant des notices telles que "/db/unebase/0001/unebase-0001001.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é. 1.1.3.4 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/". 1.1.3.5 Les bases "Groupe" et "Utilisateur" La gestion des groupes et des utilisateurs dans Notix est identique au dispositif de gestion des bases documentaires. Les documents qui 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". 1.1.3.6 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
1.1.3.7 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. 1.1.3.8 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
Illustration 1: Organisation du stockage des données XML de Notix dans exist 1.1.4 La communication entre Notix et exist 1.1.4.1 La configuration des instances exist Pour pouvoir disposer de plusieurs instances d'une base exist dans Notix, une 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
<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. 1.1.4.2 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>172.16.41.5:8088</exist-url> </global-variables> 1.1.4.3 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
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-0002001.xml". 1.1.4.4 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
</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(); 1.1.5 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
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
1.2 Déroulement de la mission 1.2.1 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
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. 1.2.2 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
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
1.3 Méthodologie 1.3.1 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 11 http://www.qsos.org/methode.php?lang=fr 12 http://www.novaforge.org/novaforge/fr-partager/methodologie 18
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 1.3.2 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
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
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 2.1.1 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 2.1.2 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
2.1.2.1 - 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. 2.1.2.2 - 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
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
2.2 Une pluralité de formats, standards et protocoles 2.2.1 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 2008. 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 2.2.2 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
(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 2.2.3 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
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 2.2.3 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
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-0001001.xml Dans cet exemple, plusieurs caractéristiques propres à exist apparaissent : 27
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
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. 3.4 - 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
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
4 Préconisations et réalisations 4.1 Diagnostic 4.1.1 - Masquer le système de stockage utilisé pour réduire les dépendances 4.1.1.1 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. 4.1.1.2 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
base documentaire. Le patron d'url est le suivant: "xdb:unebase/chemin" Les chemins peuvent être les suivant: Une notice: "xdb:unebase/unebase-0000001.xml" Un rapport d'alimentation: "xdb:unebase/rapport/unebase-date.xml" un gabarit de notice: "xdb:unebase/_unebase.rdfs" Une notice rejetée non valide: "xdb:unebase/non-valides/unebase-0000001.xml" Une notice rejetée en double: "xdb:unebase/doublons/unebase-0000001.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. 4.1.1.3 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