II. La structure d`accueil - C`est fermé. Jusqu`à nouvel ordre.

Rapport de Stage
Création d’un Module pour l’archivage de flux XML en
Base de Données Relationnelle
Jean-Sylvain Granier
IUT de Montpellier 2
DUT Intomatique Année Spéciale
Promotion 2010 – 2011
Tuteur : Mr Olivier Prat
Professeur responçable : Mme Salmon
I
REMERCIEMENTS
Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance aux
personnes suivantes, pour l’expérience enrichissante en plein d’intérêt qu’elles m’ont
permis de vivre durant ces deux mois dans le Centre Informatique National de
l’Enseignement Supérieur :






II
Monsieur Philippe Prat, mon tuteur de stage, pour l’intérêt du sujet de stage
qu’il m’a confié, sa confiance, ses conseils et le temps qu’il m’a accordé.
Monsieur Theron Jean-Pierre, qui a assuré le suivi du projet en absence de Mr
Prat
Monsieur Rouchon Olivier, responsable du Département Archivage et Diffusion
du CINES, pour sa disponibilité, et pour m’avoir accueilli dans son
département.
Monsieur Pontillon Marcel, Secrétaire Général du CINES, pour m’avoir permis
de faire mon stage au CINES.
Monsieur Daumas Francis, directeur du CINES.
Tous les membres de l’équipe du CINES que j’ai pu côtoyer pendant cette
période, et qui n’ont jamais hésité à se mettre à ma disposition lorsque je les
sollicitais.
Sommaire
Remerciements ............................................................................................................. II
Glossaire...................................................................................................................... V
Table des figures ........................................................................................................ VI
I. Introduction ................................................................................................................ 1
II. La structure d’accueil ................................................................................................ 2
II.1. Le CINES ........................................................................................................... 2
II.1.1. Le calcul numérique intensif: ....................................................................... 2
II.1.2. La diffusion : ................................................................................................ 2
II.2. Les Départements .............................................................................................. 2
II.2.1. DCI .............................................................................................................. 2
II.2.2. DSII .............................................................................................................. 3
II.2.3. DARH .......................................................................................................... 3
II.2.4. DAD ............................................................................................................. 3
II.3. Le projet ISAAC.................................................................................................. 4
II.4. Le sujet du stage ................................................................................................ 5
III. Analyse des Besoins................................................................................................ 6
IV. Matériel & Méthodes................................................................................................ 8
IV.1. Phases de conception....................................................................................... 8
IV.1.1. Recherche des solutions existantes pour traiter le problème ..................... 8
IV.1.2. Elaboration d’une stratégie d’intégration .................................................. 10
IV.2. Outils et environnement de développement .................................................... 12
IV.2.1. Ordinateur ................................................................................................ 12
IV.2.2. Environnement de développement ........................................................... 12
IV.2.3. SVN .......................................................................................................... 13
IV.2.4. Répertoire commun du projet ................................................................... 13
IV.3. Phase de développement ............................................................................... 13
IV.3.1. Le contrôleur XGDB ................................................................................. 13
IV.3.2. La feuille de style xml2hbm.xsl ................................................................. 16
IV.4. Phase de tests ................................................................................................ 20
IV.4.1. Tests indépendants, classes par classes ................................................. 20
IV.4.2. Test de la feuille de style xml2hbm.xml .................................................... 21
IV.4.3. Tests de l’ensemble du module XGDB ..................................................... 21
V. Résultats ................................................................................................................ 22
V.1. Les recherches préalables ............................................................................... 22
III
V.2. La stratégie élaborée ....................................................................................... 22
V.3. Développement du module XGDB .................................................................. 22
VI. Discussion ............................................................................................................ 23
VI.1. Un modèle relationnel pour stocker des données hiérarchiques. Quel intérêt ?
...................................................................................................................................... 23
VI.2. XSLT pour fransformer le fichier XSD ............................................................ 23
VI.3. Presque tout est à terminer. Pourquoi ? ......................................................... 23
VII. Conclusion ........................................................................................................... 25
Annexes ....................................................................................................................... 1
Annexe I. Diagramme de GANTT : Planning de stage ............................................. 2
Annexe II. Organigramme du CINES ........................................................................ 3
Annexe III. L’Archivage Pérenne .............................................................................. 4
Annexe IV. Veille technologique portant sur le stockage XML .................................. 5
Annexe V. Diagramme de XGDB : Interactions entre l’application métier, XGDB,
Hibernate et Postgre SQL. .............................................................................................. 6
Annexe VI. Diagramme des Classes de XGDB ........................................................ 7
Résumé ........................................................................................................................ 9
Abstract ........................................................................................................................ 9
IV
GLOSSAIRE
Lorem, 1, 3, 5, 7, 9, 10, 13, 15, 18, 20
V
TABLE DES FIGURES
Figure 1 : JADE, supercalculateur d’une puissance crête de 267 Tflop/s ...................................................................... 3
Figure 2 : La baie de stockage SUN Storagetek ST6140-4G (40 To).............................................................................. 4
Figure 3 : La Robothèque StorageTek STK 9310 .......................................................................................................... 4
Figure 4 : Exemple modélisation XML vers CLOB ......................................................................................................... 8
Figure 5 : Exemple d'une transition Schémas XML vers Modèle Physique de Données Relationnelles ........................ 9
Figure 6 : Diagramme d'action de stockage XML par persistance d'objets................................................................. 10
Figure 7 : Processus de transformation d'un fichier avec XSLT .................................................................................. 17
Figure 8 : Table prête à recevoir les données d'un fichier XML ayant pour schéma le fichier XSD pris en exemple. .. 19
VI
Jean-Sylvain Granier - DUT Info. AS 2010/2011
I. INTRODUCTION
Pour terminer mon DUT Informatique de Gestion en un an, j’ai souhaité effectuer
mon stage de fin d’année au Centre Informatique National de l’Enseignement Supérieur
(CINES), à Montpellier.
Parmi ses projets, le CINES élabore une plateforme d’archivage intermédiaire de
données scientifiques. Lorsque la plateforme reçoit des données scientifiques, celles-ci
sont accompagnées de métadonnées qui sont essentielles pour comprendre les
données scientifiques, et pour effectuer des recherches. C’est le projet ISAAC.
Ces métadonnées, transmises au format XML, respectent une structure bien
particulière, qui est propre à la méthode employée pour décrire une donnée
scientifique. L’ambition du projet ISAAC est d’être capable de stocker et de traiter ces
métadonnées, quelque soit la méthode de description employée, et donc quelque soit la
structure des métadonnées.
L’objectif de mon stage était donc d’élaborer une stratégie permettant à la
plateforme ISAAC de travailler avec des données XML dont la structure n’est pas
connue d’avance. Puis de mettre en application cette stratégie.
Dans ce rapport, je présenterais dans un premier temps le CINES, en expliquant le
projet ISAAC. Je détaillerais ensuite le sujet de mon stage.
Puis je présenterais les exigences que je dois prendre en compte dans ma
participation à ce projet, puis ma démarche de travail, ainsi que certains points
techniques bien spécifiques au traitement de données XML.
Ensuite, je décrirais les résultats que j’ai réussi à atteindre en 10 semaines de
stage, et j’expliquerais certains choix au travers du chapitre Discussions.
Pour terminer, je conclurai sur cette expérience au CINES.
1
Rapport de Stage - CINES, Montpellier
II. LA STRUCTURE D’ACCUEIL
II.1. Le
CINES
Le CINES, Centre Informatique National de l’Enseignement Supérieur basé sur
Montpellier (Hérault) a été créé en 1999. Succédant au CNUSC (Centre National
Universitaire Sud de Calcul) créé en 1980.
C’est une EPA (établissement public à caractère administratif) sous la tutelle de la
DGRI (Direction Générale de la Recherche et de l’Innovation) et de la DGESIP
(Direction Générale pour l’Enseignement Supérieur et l’Insertion Professionnelle) du
Ministère de l’Enseignement Supérieur et de la Recherche.
Les principales missions du CINES sont:
II.1.1. Le
calcul numérique intensif:
Le CINES possède la 28e machine mondiale de calcul, qui est utilisée par les
scientifiques demandant des calculs de grandes importances et demandant une grande
capacité de calcul.
II.1.2. L’archivage pérenne de documents électroniques :
Depuis 2004, le CINES a une mission nationale d’archivage du patrimoine
scientifique. Pour remplir cette mission, il a mis en place le projet PAC qui dote le
CINES d’une plate-forme et d’un service d’archivage numérique pérenne.
II.1.3. La diffusion :
Le CINES héberge plusieurs services de diffusion (via Internet) de l’information
scientifique et technique : grandes bases de données, diffusion vidéo multimédia,
serveurs web.
II.2. Les
Départements
Le CINES est composé de 4 départements : DCI (Département Calcul Intensif),
DSII (Département Services Informatiques et Infrastructures), DARH (Département
Administration et Ressources Humaines) et le DAD (Département Archivage et
Diffusion).
Un organigramme du CINES est disponible en annexe II.
II.2.1. DCI
Le CINES possède de puissantes machines à architecture parallèle (SGI Altix Ice,
IBM P1600, cluster Bull avec GPU, ferme expérimentale Cell). Ces machines servent à
effectuer les calculs des équipes de chercheurs des Universités et des organismes de
recherche publics qui travaillent avec lui. En France, il existe 3 centres de calcul : le
CINES, l’IDRIS et le CCRT.
Le Département Calcul Intensif a donc pour but de mettre à disposition des
moyens matériels et logiciels aux chercheurs. Ainsi les chercheurs utilisent les
machines de calculs à travers différents procédés crées par le DCI. Les projets
déposés nécessitent généralement 1 million d’heures, cela peut aussi aller à 20 millions
pour les gros projets.
Pour cela, les utilisateurs procèdent généralement à une Demande d’Attribution de
Ressources Informatiques (DARI) gérer par l’application DARI, où ils déposeront leurs
dossiers. Ces demandes peuvent être attribués à un ou plusieurs des 3 centres de
calculs de France.
2
Jean-Sylvain Granier - DUT Info. AS 2010/2011
Il existe aussi un serveur PRACE qui lui peut prendre des dossiers au niveau
européen et qui utilise des machines de tiers 0, soit les plus puissantes. À savoir que le
CINES possède la 27e puissance de calcul au niveau mondial (2e national) et
qu’environ 600 dossiers par an environ sont gérés par les 3 centres de calcul, dont
environ 300 par le CINES.
Figure 1 : JADE, supercalculateur d’une puissance crête de 267 Tflop/s
II.2.2. DSII
Le Département Services Informatiques et Infrastructure est en charge de
l’infrastructure informatique sur lesquelles s’appuient les équipements des autres
départements.
Il est donc en charge de veiller à la disponibilité des ressources et à la sécurité des
données. Il assure également le centre d’appel de premier niveau.
Il s’occupe donc des machines comme Jade, les met à jour, les configure et
s’assure aussi de leur sécurité.
II.2.3. DARH
Le Département Administration et Ressources Humaines est chargé de la gestion
financière et administrative du centre. Il s’occupe aussi des relations avec les
fournisseurs, prépare les marchés et veille à leur exécution.
Le DARH s’occupe aussi des relations humaines du CINES.
II.2.4. DAD
Le DAD définit et met en place les outils et les procédures qui permettent de
garantir la pérennité des données et documents numériques qui sont confiés au CINES
pour un archivage à très long terme. Il apporte conseil et expertise dans le domaine et
participe à des projets nationaux et internationaux. Les données stockées sont
généralement scientifiques, patrimoniales (pédagogiques, publications…) et
administratives (archives intermédiaires).
Il s’occupe donc de l’archivage numérique pérenne qui est la conservation à long
terme de données numériques (au-delà de 10 ans). Pour cela, il existe une Plateforme
d’Archive au CINES (PAC) servant pour le dépôt et l’archivage des thèses
électroniques.
Cette plateforme est actuellement appelée PAC v2.0. Elle est exploitée depuis
printemps 2008. Elle privilégie une approche généraliste des données à archiver afin
d’éviter de gérer au cas par cas les projets d’archives.
Le DAD se charge aussi d’une veille technologique afin de suivre l’évolution des
technologies et s’assurer que les données puissent les supporter.
3
Rapport de Stage - CINES, Montpellier
Figure 2 : La baie de stockage SUN Storagetek ST6140-4G (40 To)
Figure 3 : La Robothèque StorageTek STK 9310
II.3. Le
projet ISAAC
C’est au sein du département DAD qu’est né le projet ISAAC (Informations
Scientifiques Archivées au CINES) en juin 2010, intégrant la notion d’archivage
intermédiaire
L’archivage intermédiaire consiste à conserver des données pendant 3 ou 4 ans.
Ces données pourront ensuite être transférées en données définitives et ainsi rejoindre
l’archivage pérenne. Cependant, une grande partie des données ne le sera pas, car ils
n’en auront pas la nécessité. L’archivage intermédiaire permet ainsi de filtrer ce type de
données. Il permet aussi de faciliter le passage de données à un archivage pérenne,
sur la plateforme PAC.
Afin qu’une donnée archivée ne reste pas simplement en ensemble de valeur sans
sens, et que seul l’auteur pourrait comprendre plusieurs années après la rédaction, les
archivistes joignent aux données des métadonnées. Ces métadonnées permettent de
décrire et de renseigner sur le contenu d’un document. On distingue trois types de
métadonnées :
1. les métadonnées de gestion, pour l’accès au document
2. les métadonnées de description, pour comprendre le contenu du document
3. les métadonnées de préservation, pour garantir la compréhension du
document au travers du temps.
4
Jean-Sylvain Granier - DUT Info. AS 2010/2011
Les métadonnées constituent donc une carte d’identité d’un document. Elles
permettent de l’identifier, de le décrire, d’expliquer pourquoi ce document a été créé,
pour quel objectif, quels sont les auteurs, et quels sont les destinataires.
Sans tous ces éléments, un document peut vite devenir incompréhensible et donc
inexploitable.
En effet, comment comprendre une succession de chiffres dans un tableau, s’il
n’est pas précisé ce que représentent les valeurs en abscisses et en ordonnées, qui a
fait ce document, pour qui, dans quel but ou encore à quelle date.
Pour aider à la description de documents à l’aide de métadonnées, les archivistes
utilisent généralement un standard de description à base de XML, le plus classique
étant le Dublin Core Metadata Initiative.
Quoi qu'il en soit, le projet ISAAC doit être capable de gérer simultanément
plusieurs standards de métadonnées, selon les choix faits par les archivistes et
personnes qui accèderont au service d’archivage intermédiaire.
Pour de plus amples informations sur la problématique d’archivage, et des
métadonnées, vous pouvez consulter l’annexe III
II.4. Le
sujet du stage
Comme il a été vu plus tôt dans la description du projet ISAAC, l’équipe chargée de
son développement est à la recherche d’une solution capable de stocker et de traiter
des données au format XML. Ces flux de données respectent des schémas XML, qui
ne sont pas tous définis initialement, lors de la phase de développement du projet
ISAAC
Ma mission lors de ce stage fut donc de rechercher les solutions existantes pour
gérer une telle situation, et de mettre en place cette solution.
5
Rapport de Stage - CINES, Montpellier
III. ANALYSE DES BESOINS
Afin de mener à bien ma mission, des exigences ont été fixées pour définir les
actions et les traitements que la solution à élaborer doit prendre en charge.



















6
Mettre en place une solution qui permette de stocker une quantité
importante de données (De l’ordre de plusieurs de téraoctets.).
L’utilisation de cette solution doit être le plus transparente possible.
La solution doit être développée en Java.
Si possible, la solution doit fonctionner avec un serveur de base de données
relationnelle Postgre
La vitesse de fonctionnement de la solution développée doit rester correcte
même en présence de beaucoup de données enregistrées.
La solution à développer se fait dans la cadre du projet ISAAC, mais si elle
peut être développée de façon suffisamment générique pour s’adapter à
d’autres projets ayant des besoins similaires, c’est un plus. Il faut donc
garder un certain niveau d’abstraction.
La solution à développer doit venir s’imbriquer dans un autre logiciel en
Java. Aucun élément graphique à destination de l’utilisateur final ne doit être
produit. La solution doit interagir avec le programme appelant via des
résultats de méthodes, et des exceptions, et des interagir directement avec
le SGBD.
La solution doit pouvoir fonctionner avec plusieurs configurations en même
temps dans un même programme.
Les données à stocker sont fournies au format XML.
La structure de ces documents XML n’est pas définie à l’avance (Au moment
de la programmation/mise en place de la solution).
La solution doit prendre en charge la création de la structure qui va recevoir
les données. Pour se faire, le programme appelant fournira dans un premier
temps un fichier XSD (Schéma XML), puis le fichier XML contenant des
données à archiver.
La solution doit prendre en charge l’enregistrement des données importées
en XML vers la nouvelle structure.
La solution doit aussi prendre en charge la recherche de données déjà
importées, et la restitution de ces données.
Éventuellement, la solution doit permettre de restituer les données qui sont
présentes en base de données sous la forme d’un flux XML.
Il est impératif que la solution soit capable de gérer un ensemble de
structure XML, et de données respectant ces structures.
Lorsqu’un ensemble de données sont archivées en base de données, il faut
conserver un lien logique avec le schéma XML que cet ensemble de
données respectait au moment où cet ensemble était présenté sous le
formalise XML.
La solution à mettre en place doit permettre de modifier les flux de données
déjà importés en base de données.
Les données présentées à la solution à des fins d’archivage peuvent se
présenter comme un fichier dans un système de fichier, mais aussi comme
un flux de données simple.
La solution à mettre place doit être Open Source.
Jean-Sylvain Granier - DUT Info. AS 2010/2011
Par ailleurs, des spécifications fonctionnelles ont été rédigées, et sont
accessibles en annexe VII
7
Rapport de Stage - CINES, Montpellier
IV. MATERIEL & METHODES
À présent que le projet ISAAC et que mon rôle dans ce projet vous ont été
présentés, voici la démarche que j’ai adopté pour résoudre le problème.
IV.1. Phases
de conception
IV.1.1. Recherche des solutions existantes pour traiter le problème
La problématique de stockage de flux XML est quelque chose de courant dans le
domaine informatique. D’autant plus que ce format de données est de plus en plus
utilisé. Une fois que les besoins ont été définis, j’ai donc cherché quelles solutions déjà
existantes pourraient s’intégrer dans le projet, pour répondre à nos besoins. Vous
pourrez trouver cette veille technologique complète en annexe IV, mais en voici
l’essentiel :
D’après les recherches que j’ai effectuées, il existe plusieurs façons d’aborder le
problème du stockage XML dans une base de données :
IV.1.1.a. Stocker l’intégralité du flux XML en tant que CLOB
Cette technique consiste à stocker le flux XML comme une simple chaine de
caractères. Au niveau de la base de données, cette chaine de caractères constitue un
seul et même champ, prévu pour recevoir des textes particulièrement grands : le CLOB
(Caracter Large OBject).
Cette technique s’apparente plus à du stockage brut, et rend tout traitement
ultérieur extrêmement fastidieux.
Figure 4 : Exemple modélisation XML vers CLOB
IV.1.1.b. Gestionnaire de base de données avec capacités XML
L’approche est similaire à la précédente : on stocke l’ensemble d’un flux XML dans
un seul et même champ en base de données. La différence, c’est que le type de champ
utilisé est spécifique au format XML. Et sur ce champ-là, le SGBD propose des
fonctions pour exécuter des requêtes dans un langage propre au XML (tel que le XPath
ou le XQuery).
En comparaison avec la méthode précédente, il est possible d’exprimer des
requêtes plus précises, en exprimant des critères à appliquer sur la partie XML.
IV.1.1.c. Correspondance entre le schéma XML avec le schéma du SGBD
8
Jean-Sylvain Granier - DUT Info. AS 2010/2011
Dans cette façon de procéder, on utilise le schéma XML pour composer un modèle
physique de données applicable dans un système de gestion de base de données
relationnelle.
Il existe quelques outils qui permettent de générer le MPD à partir d’un fichier XSD.
Mais cette technique complexifie l’accès aux données dans la base de données :
chaque valeur unaire est placée dans un champ, et chaque relation (qui en XLM est
induite par une notion d’héritage ou de type complexe) est traduite par une jointure et
des clefs référentielles en base de données relationnelle. Donc, côté programmation, il
faut connaitre précisément le modèle physique de données qu’a généré un fichier XSD,
pour pouvoir reconstituer les données et effectuer des traitements sur ces données.
Figure 5 : Exemple d'une transition Schémas XML vers Modèle Physique de Données Relationnelles
Dans cet exemple, la déclaration d’un type complexe a engendré la création de
cinq tables avec des relations entre chacune de ces tables.
IV.1.1.d. Gestionnaire de base de données XML.
Cette méthode constitue une approche totalement différente, puisqu’elle consiste à
utiliser un système de gestion de base de données non pas relationnelle, mais
spécifique à l’usage de flux XML. Il n’utilise donc pas de tables.
Cette méthode permet de s’affranchir totalement du problème de structure qu’il y a
entre le formalisme XML et le formalisme relationnel des bases de données.
Ce pendant, les performances que procure ce genre de solution sont rarement
comparables à celles d’un SGBDR classique.
IV.1.1.e. La persistance de données
Cette façon de fonctionner comporte plusieurs phases. À l’aide d’une librairie de
mappage, on créé des classes Java à partir des schémas XML. Ces classes sont
destinées ensuite à recevoir les données des flux XML correspondant aux schémas qui
ont servi à créer la classe.
9
Rapport de Stage - CINES, Montpellier
Enfin, une librairie de persistance de données se charge de faire la transition entre
les objets instanciés en mémoire, et les données qui sont en base de données. Cette
librairie de persistance fonctionne généralement à l’aide d’un fichier de mappage, qui
établit la correspondance entre les variables présentes dans les objets Java, et
l’ensemble des tables et attributs en base de données.
Figure 6 : Diagramme d'action de stockage XML par persistance d'objets
De plus, la majorité de ces librairies sont capables de créer la structure de la base
de données une fois que le fichier de mappage est établi.
d’une stratégie d’intégration
Suite aux résultats de la veille technologique, mon tuteur et moi avons décidé de
nous engager dans la voie de la persistance de données. Cette solution était la plus
satisfaisante puisqu’elle permet d’avoir un haut niveau d’abstraction, elle supporte
l’ajout de nouvelles structures des données pendant la vie du produit, et elle procure la
stabilité et la rapidité de traitement des systèmes de gestion de base de données
relationnelle.
IV.1.2. Élaboration
Notre première approche fut d’utiliser JAXB (Java API for XML Binding) pour la
transition entre le flux XML et les classes Java, et d’utiliser Hibernate pour la transition
classes Java vers le SGBDR.
10
Jean-Sylvain Granier - DUT Info. AS 2010/2011
Après quelque temps de travail sur cette méthode, j’ai été confronté à de nombreux
problèmes pour la génération de classes Java à partir de fichiers XSD, et ensuite à des
problèmes d’interprétation par la librairie qui devait s’occuper de générer un fichier de
mappage Hibernate à partir des classes Java.
Les classes générées par JAXB nécessitaient des corrections pour pouvoir recevoir
correctement les données des fichiers XML.
De même, lorsque j’utilisais l’outil de génération d’un fichier de mappage, inclus
dans Hibernate, j’obtenais un résultat qui nécessitait d’être corrigé à son tour.
À ce stade-là, ce qui représente la moitié de mon stage, nous nous sommes
concertés avec mon tuteur de stage, pour savoir s’il fallait approfondir cette voie, ou
changer d’approche. Dans un même temps, nous avons eu connaissance d’une
nouvelle capacité de Hibernate. À partir d’un objet dom4j (un objet qui contient l’arbre
XML), Hibernate est capable, en appliquant toujours un ensemble de règles de
mappage, d’effectuer directement une transition d’un arbre XML vers un schéma
relationnel d’une base de données.
Avec une telle approche, le transfert entre un fichier XML vers une base de
données est facilité. J’ai alors élaboré la stratégie de fonctionnement suivante.
À partir des fichiers XSD, je créé un fichier de mappage Hibernate.
À partir d’un flux XML, j’instancie un objet dom4j. Une fois cet objet instancié, je
peux déterminer le nœud racine, qui doit correspondre à l’un des éléments définis dans
un fichier de mappage. Lorsque qu’il est nécessaire d’envoyer les données de cet objet
dom4j en base de données, j’indique à la session d’Hibernate le nœud racine, et donc
en quelque sorte la classe que respectent les données présentes dans cet arbre XML.
Avec ces informations-là, Hibernate se charge de prendre tous les nœuds de l’arbre
XML et de répartir les données en BDD, conformément aux instructions du fichier de
mappage associé à la classe indiquée.
En annexe V, vous trouvez un diagramme qui détaille pour chaque acteur de cette
solution, son rôle en fonction des requêtes de l’application métier.
Pour le nom du module, nous avons choisis XGDB pour XML Goes in Data Base
(en français, XML va dans une base de données).
Dans cette approche, les éléments suivants restent donc à être développés :

Le contrôleur
Sa fonction est de recevoir les instructions envoyées par l’application métier,
puis de déclencher les actions intermédiaires pour l’ajout d’une nouvelle
structure de données XML, l’ajout d’un flux XML de données, ou encore la
récupération de données présentes en BDD.
11
Rapport de Stage - CINES, Montpellier

La transition schéma XSD vers fichier de mappage Hibernate.
Le but de cette partie est de créer un fichier de mappage Hibernate en
utilisant un fichier XSD. Ce processus est obligatoire sans quoi Hibernate ne
peut établir de correspondance entre la structure des données XML et le
gestionnaire de bases de données relationnelles. Des recherches que j’ai
effectuées, il n’existe qu’une solution déjà développée qui permette une telle
transformation. Cette solution se base sur le fait qu’un fichier XSD comme
un fichier de mappage Hibernate sont tous les deux rédigés en XML. En
partant de ce constat, une feuille de transformation XML (XSLT) permet de
générer un fichier de mappage Hibernate à partir d’un fichier XSD. Le
problème est que la personne qui a rédigé cette feuille de transformation
XML n’avait pas comme impératif de transposer la structure d’un fichier XML
vers une structure équivalente, mais en base de données relationnelle. La
feuille de transformation que je me suis procurée ne fait que créer des tables
pour chaque élément décrit par un fichier XSD. Mais étant novice dans ce
domaine, cela constituait un point de départ pour apprendre le XSLT.
IV.2. Outils
et environnement de développement
En corrélation directe avec les outils utilisés au CINES, les choix qui ont été faits
pour le projet ISAAC mais aussi en fonction de la stratégie adoptée pour le stockage de
flux XML en base de données, voici l’environnement de développement dans lequel j’ai
mis au point le module XGDB.
IV.2.1. Ordinateur
Un PC Core 2 Duo @ 2.66Ghz, avec 2Go de RAM et un disque dur de 128 Go, sur
Microsoft Windows XP. Il s’agit là de l’environnement de développement.
L’environnement de production étant autrement mieux équipé, et sur Linux. ###
IV.2.2. Environnement
de développement
IV.2.2.a. Eclipse Java EEIDE ( Hélios Services 2 )
Environnement de développement intégré très connu, c’est aussi celui qui est
utilisé dans mon département du CINES dans le cadre de projets en Java.
IV.2.2.b. UMLet
Logiciel gratuit sous licence GNU. Il peut s’intégrer à Eclipse en tant que plug-in, ou
être lancé en tant qu’application autonome. Comme son nom le laisse supposer, il
permet de dessiner des diagrammes UML.
IV.2.2.c. SyncRo Soft oXygen
C’est un logiciel que j’ai utilisé de ma propre initiative. Il propose de nombreux
outils pour travailler avec des documents XML, et m’a été d’une très grande utilité pour
mettre au point la feuille de transformation XSLT. Il propose une très bonne complétion
du code lors de la saisie, et permet de voir rapidement le résultat de l’exécution de la
feuille de style sur un fichier d’exemple. Il possède aussi un excellent débogueur, ainsi
qu’une validation du code à la volée.
Cet outil est payant avec une version de démonstration de 30 jours.
IV.2.2.d. Base de données Postgre SQL 9
Pour effectuer des tests sur mon poste de développement, j’ai utilisé Postgre SQL
9 pour Windows. Sur l’ensemble du projet ISAAC, c’est aussi le SGBDR qui est utilisé.
12
Jean-Sylvain Granier - DUT Info. AS 2010/2011
IV.2.2.e. Le langage de programmation : Java
L’équipe du département DAD étant déjà très familiarisée avec ce langage, il était
naturellement privilégié pour la réalisation du projet ISAAC.
De plus, le fait d’être indépendant de la plateforme logicielle était aussi un atout
déterminant.
Au sein même de mon module de transition XML vers SGBDR, j’ai notamment
utilisé :




Hibernate 3.6.5 pour la persistance de données
Log4j 1.2.16 pour la génération de messages à l’intention d’un journal
d’activité, mais aussi au débogage.
Un pilote de connexion sur une base de Donen Postgre (postgresql-9.0801.jdbc4.jar)
JDom 1.1.1, solution en Java pour manipuler des flux XML.
IV.2.3. SVN
Un serveur Subversion est en place au CINES. J’ai donc eu l’occasion d’utiliser
SVN dans Eclipse. Pour ce faire, j’ai utilisé Subversive SVN 1.6 SVN Kit Connector.
IV.2.4. Répertoire commun du projet
Un espace disque en réseau est mis en commun au niveau du CINES. Il contient
notamment tous les documents relatifs au projet ISAAC, des recherches sur les formats
de métadonnées, ainsi que bien d’autres documents qui m’ont aidé à comprendre
l’organisation du CINES et les objectifs du projet ISAAC.
IV.3. Phase
de développement
Le développement du module dont j’ai la charge comporte deux parties
essentielles : la partie contrôleur, qui est en Java, et la partie génération du fichier de
mappage Hibernate, qui est faite avec une feuille de transformation XSLT. C’est donc
tout naturellement que mon développement s’est axé en deux parties que vous allez
découvrir plus bas. Le diagramme des classes correspondant au module XGDB est
disponible en annexe VI.
IV.3.1. Le contrôleur XGDB
Dans la solution que j’ai développée, le contrôleur tient une place centrale. Il est à
l’écoute des instructions génériques de l’application métier qu’est ISAAC, et exécute
d’autres actions en conséquence sur les classes qui composent le module XGDB, et
sur Hibernate. Ces instructions génériques peuvent être regroupées en trois
catégories :
IV.3.1.a. Instanciation du contrôleur XGDB
Lorsque l’application métier doit manipuler des données, cela se fait forcément par
un moyen technique. C’est la logique de programmation objet qui implique cela. Dans
certains cas, il s’agit d’un accès aux données via un fichier, dans d’autres cas, un accès
via une connexion à une base de données. Le module que je développe doit donc
fournir un moyen technique d’accès. J’ai créé la classe XgdbSession dans ce but. C’est
l’objet de base, qui sera le pivot communiquant entre l’application métier, et les autres
classes qui composent le module XDGB.
Cette classe est dans le paquet
fr.cines.pac.xgdb.
13
Rapport de Stage - CINES, Montpellier
L’instanciation du contrôleur se fait en précisant deux fichiers de configuration : Le
premier est un fichier ‘properties’, et correspond à la configuration directe de XGDB,
tandis que le second correspond à la configuration de base de Hibernate :
XgdbSession s = new XgdbSession(new File("conf/xgdb.properties"),new
File("conf/hibernate.cfg.xml") );
La configuration de base d’Hibernate comprend des éléments tels que les
informations de connexion à la base de données, le dialecte de la base de données
(des différences syntaxiques existent entre MySQL, PostGre, Oracle…). Ce fichier peut
aussi contenir une référence vers un/plusieurs fichiers de mappage.
Lors de cette initialisation, le fichier de configuration XGDB est chargé en mémoire,
et la préparation de Hibernate est lancée automatiquement.
L’initialisation d’Hibernate se fait avec un mécanisme de configuration préalable. La
stratégie est de créer dans un premier temps un objet de la classe
org.hibernate.Configuration, puis d’appliquer à cet objet divers paramétrages. On y
applique donc dans un premier temps le fichier de configuration (hibernate.cfg.xml),
puis par exemple, on ajoute des fichiers de mappage à l’aide de la commande
addRessource(String ‘path/to/file.hmb.xml’).
Dans le cas du module XGDB, la liste des fichiers de mappage n’est pas connue
d’avance. Je considère donc que tous les fichiers de mappage sont regroupés dans un
répertoire (précisé dans le fichier de configuration de XGDB). Puis, je créé une liste de
tous les fichiers finissant par hmb.xml dans le répertoire indiqué dans la configuration.
Enfin, une boucle se charge de lancer la commande addRessource sur tous les
éléments de cette liste.
Lorsque l’objet Configuration est enfin prêt, la configuration est appliquée à un objet
de la classe org.hibernate.SessionFactory, qui sert à son tour à créer la session
Hibernate, de classe org.hibernate.Session. C’est lors de ce passage entre
SessionFactory à Session que la connexion à la base de données est effectuée.
À ce moment-là, la session Hibernate est prête à être utilisée.
D’autres méthodes de la classe XgdbSession sont alors accessibles pour ajouter une
nouvelle structure de données à l’aide d’un schéma XSD, ajouter des données issues
d’un fichier XML, ou encore retrouver des données qui ont déjà été importées dans
base de données. Toutes ces méthodes font soit appel aux classes du module XGDB,
soit aux classes de Hibernate. Le but étant de simplifier l’utilisation de XGDB du côté de
l’application métier.
IV.3.1.b. L’ajout de structure de données
Cet aspect du module XGDB
fr.cines.pac.xgdb.mappingGeneration.
fait
l’objet
d’un
paquet
spécifique :
Pour rappel, ajouter une nouvelle structure de données consiste, depuis
l’application métier, à vouloir prendre en charge un nouveau jeu de métadonnées. Le
schéma de ces métadonnées est décrit dans un fichier XSD. Du point de vue du
module XGDB, cela consiste à créer un nouveau fichier de mappage Hibernate.
Pour cette transition d’un schéma XML vers un fichier de mappage Hibernate, j’ai
choisi de travailler avec une feuille de style XSL.
Donc du côté programme Java, les instructions sont très simplifiées.
14
Jean-Sylvain Granier - DUT Info. AS 2010/2011
La classe chargée de cette transformation (XsdToHmbGenerator) fait appel à la
classe javax.xml.transform.Transformer. La méthode ‘transform()’ permet alors
d’appliquer une feuille de style XSL sur un fichier XML, dans notre cas un fichier XSD.
Ensuite, le fichier hmb.xml généré précédemment est ajouté dans le répertoire qui
regroupe tous les fichiers de mappage.
La prise en charge par Hibernate d’un nouveau fichier de mappage n’est pas
possible lorsqu’une session est déjà ouverte. C’est pourquoi, lorsque l’application
métier souhaite ajouter une nouvelle structure de données, il faut appeler la méthode
addSchema de la classe XgdbSession : celle-ci se chargera de fermer la session
Hibernate, de lancer la transformation du fichier XSD en hmb.xml, puis d’ouvrir une
nouvelle session Hibernate.
IV.3.1.c. La gestion de données
Les classes qui gèrent les données qui transitent dans le module XGDB sont
regroupées dans un paquet fr.cines.pac.xgdb.dataHandler.
Ces classes permettent de conserver une liste des schémas importés, des flux
XML importés. Elles sont la réponse directe au besoin de traçabilité et de conservation
du lien qui existe entre un flux XML et le schéma qu’il respecte.
La classe ShemaImport sert à créer dans le système d’information un point de
référence vers lequel pointent tous les flux XML qui respectent un schéma XML donné.
C’est d’ailleurs un des besoins exprimés. Un tel objet permet aussi de conserver le
schéma XML brut.
La classe TypeImport permet d’associer à un type de données (décrite dans un
schéma XSD) le nom du nœud qui est utilisé dans un flux XML pour y faire référence.
Cela est très important, car lors de la sauvegarde d’un flux XML stocké dans un objet
Dom4j, Hibernate a besoin qu’un type de données soit spécifié. D’ordinaire,
lorsqu’Hibernate fonctionne avec des objets Java, le nom de la classe de cet objet est
recherché parmi les instructions de mappage qui ont été définies. C’est ce qui permet à
Hibernate de déterminer pour chaque variable de l’objet ce qu’il doit faire, afin de faire
transiter les données vers le modèle relationnel d’une base de données, ou
inversement lorsqu’il s’agit d’une ré-instanciation d’objet. Dans le cas des la
manipulation de flux XML, c’est le nom du type de données qui joue ce rôle.
Par exemple, supposons qu’un schéma décrive la structure d’un carnet d’adresses.
Le nom du type de données serait ‘ContactBookType’, et dans le fichier XML qui
utiliserait ce type de données, nous trouverions un nœud <ContactBook>.
Comme un type de données est décrit par un schéma XML, la classe TypeImport
prévoit aussi un lien vers un objet de la classe SchemaImport.
La classe DataImport implémente les méthodes et objets relatifs à l’import d’un
nouveau flux XML. Elle contient donc un objet de la classe Dom4J, destiné à recevoir le
flux XML en lui-même, un identifiant, qui permettra au travers de la persistance de
données de garder une trace des imports de données, et du flux XML original, dans le
formalisme XML.
15
Rapport de Stage - CINES, Montpellier
Un autre élément important de la classe DataImport est la variable rootEntityName.
N’importe quel flux XML commence forcément par un élément racine. Par exemple,
dans le cas d’un fichier XHTML, l’élément racine est ‘HTML’, d’où découlent ensuite
tous les autres éléments qui décrivent le document. L’élément racine est donc
extrêmement important, puisque c’est lui permet de déduire à quel type de données il
appartient. Le module XGDB va tenter de mettre en relation cet élément
rootEntityName avec un élément de la classe TypeImport. Si aucune correspondance
n’est trouvée, cela veut dire que le schéma que respecte le fichier XML n’est pas
encore importé.
Les classes Schemas, Types, Datas contiennent simplement une liste d’objets,
respectivement SchemaImport, TypeImport et DataImport.
IV.3.2. La feuille de style xml2hbm.xsl
Dans la stratégie que j’ai choisi de mettre en place pour stocker des données XML
en base de données, la librairie Hibernate est un élément essentiel. Pour fonctionner,
cette dernière a besoin de fichiers de mappage. Les fichiers XSD, qui décrivent le
schéma des flux XML à stocker, sont rédigés en XML. De même, les fichiers de
mappage d’Hibernate sont aussi rédigés en XML. En présence de deux fichiers de
même type, décrivant sensiblement les mêmes informations, mais dans une disposition
différente, les feuilles de style XML m’ont paru être la meilleure approche.
IV.3.2.a. Introduction sommaire aux feuilles de styles XSLT.
Le XSLT (eXtensible Stylesheet Language Transformations), est un langage de
transformation XML.
L'objectif principal est la transformation d'un document XML vers un autre, ou un
dialecte XML (XHTML, XSL-FO, HTML, etc.). XSLT s'appuie sur XPath pour désigner
une partie d'un arbre XML. XSLT est lui-même un dialecte XML. Un programme XSLT
est donc, avant tout, un document XML :
<?xml version="1.0" ?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="2.0">
<xsl:output method="XML" indent="yes"/>
<xsl:template match="person">
<name username="{@username}">
<xsl:value-of select="name" />
</name>
</xsl:template>
</xsl:stylesheet>
Un XSLT doit s'appuyer sur un XML, c'est un couple obligatoire, et on ne peut créer
en XSLT que des boucles parcourant des données sélectionnées par XPath.
Une transformation exprimée en XSLT décrit les règles pour transformer un arbre
source en un arbre résultat. La transformation est obtenue en associant des motifs à
des modèles. Les motifs sont appliqués aux éléments de l'arbre source. L'arbre résultat
est distinct de l'arbre source. La structure de l'arbre résultat peut être complètement
différente de la structure de l'arbre source. Pendant la construction de l'arbre résultat,
des éléments de l'arbre source peuvent être filtrés et réordonnés, et des structures
arbitraires peuvent être ajoutées.
16
Jean-Sylvain Granier - DUT Info. AS 2010/2011
Une transformation exprimée en XSLT est appelée feuille de styles. Ceci parce que
quand XSLT est transformé dans le vocabulaire de formatage XSL, la transformation
fonctionne comme une feuille de styles.
Une feuille de styles contient un ensemble de règles modèles. Une règle modèle
est constituée de deux parties : un motif qui sert à identifier des nœuds de l'arbre
source et un modèle pouvant être instancié afin de constituer une partie de l'arbre
résultat. Ceci permet à une feuille de styles d'être applicable à une large catégorie de
documents ayant des structures d'arbres source similaires.
Figure 7 : Processus de transformation d'un fichier avec XSLT
Un fichier XML associé à une feuille de style XSL (notée Code XSLT) et sont
soumis à un processeur XSLT, qui va générer un document final, en appliquant les
règles de transformations décrites dans la feuille de style aux nœuds qu’il trouvera dans
le fichier XML entré.
IV.3.2.b. Comment est fait un fichier XSD
Un fichier XSD est avant tout un fichier XML. Il permet de décrire la structure et le
type de contenu d’un autre document XML qui est destiné à recevoir des données.
Prenons en exemple le document XSD suivant :
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="personne">
17
Rapport de Stage - CINES, Montpellier
<xsd:complexType>
<xsd:sequence>
<xsd:element name="nom" type="xsd:string" />
<xsd:element name="prenom" type="xsd:string" />
<xsd:element name="date_naissance" type="xsd:date" />
<xsd:element name="etablissement" type="xsd:string" />
<xsd:element name="num_tel" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Ce schéma décrit une structure Personne, qui comprends une suite d’éléments : le
nom, le prénom, la date de naissance, un établissement, et un numéro de téléphone.
Et voici un fichier XML qui respecte ce schéma :
<?xml version="1.0" encoding="UTF-8"?>
<personne xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="personne.xsd">
<nom>MBODJ</nom>
<prenom>Babacar</prenom>
<date_naissance>1996-10-06</date_naissance>
<etablissement>NIIT</etablissement>
<num_tel>764704140</num_tel>
</personne>
IV.3.2.c. Le résultat à obtenir
À partir du fichier XSD présenté plus haut, je souhaite obtenir un fichier de
mappage utilisé par Hibernate. Un tel fichier est aussi un fichier XML, dans lequel est
décrit d’une façon spécifique, la structure des données qu’Hibernate doit traiter.
Toujours selon le même exemple, voici un fichier de mappage qu’Hibernate pourra
utiliser pour transposer un flux XML dans une base de données relationnelles.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE hibernate-mapping
PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping package="xgbd">
<class entity-name="personne" table="gen_personne" node="personne">
<id name="id_personne" type="long">
<generator class="increment"/>
</id>
<property name="nom" column="nom" node="nom" type="string" notnull="false"/>
<property name="prenom" column="prenom" node="prenom"
type="string" not-null="false"/>
<property name="date_naissance" column="date_naissance"
node="date_naissance" type="date" not-null="false"/>
<property name="etablissement" column="etablissement"
node="etablissement" type="string" not-null="false"/>
18
Jean-Sylvain Granier - DUT Info. AS 2010/2011
<property name="num_tel" column="num_tel" node="num_tel"
type="string" not-null="false"/>
</class>
</hibernate-mapping>
On remarque la présence d’un nœud ‘class’. Celui-ci correspond à l’élément
‘personne’ déclaré dans le schéma XML vu plus tôt. Cette classe est constituée de
plusieurs nœuds ‘property’, chacun correspondant à un des sous éléments décrits plus
tôt dans le fichier XSD.
De plus, un nœud ‘id’ apparaît : Il s’agit d’une clef unique qui servira d’identifiant
dans la base de données relationnelle, lorsqu’Hibernate effectuera le transfert.
On peut aussi remarquer la présence d’un attribut ‘table’ dans le nœud ‘class’ : il
s’agit du nom de la table qui sera créée puis utilisée pour stocker les données des
personnes. De même, on remarque sur les nœuds ‘property’ un attribut ‘column’, qui
correspond au nom de la colonne qui contiendra une donnée.
Enfin, l’élément le plus important, l’attribut ‘node’, que l’on retrouve sur class, mais
aussi sur property : Il permet d’indiquer quel nœud dans un fichier XML de données est
concerné par la déclaration property ou class.
Au final, voici la structure en base de données relationnelle de l’exemple
précédemment cité.
Figure 8 : Table prête à recevoir les données d'un fichier XML ayant pour schéma le fichier XSD pris en
exemple.
Lorsque l’on tente de sauvegarder un flux XML avec Hibernate en précisant la
classe ‘personne’ celui-ci va dans un premier temps créer la table montrée en
illustration. Ensuite, les données entourées par des balises nom, prénom,
date_naissance, etablissement et num_tel dans le flux XML seront transformé en un
tuple de cette table.
IV.3.2.d. La stratégie de transformation XSDHMB
Pour aborder la transition entre un fichier XSD vers un fichier HMB, la meilleure
stratégie m’a semblé celle de la récursivité. En effet, dans un schéma XML, les
éléments sont imbriqués les uns les autres. Parfois, selon l’ordre dans lequel les
éléments sont imbriqués, cela n’a pas la même répercussion sur le schéma relationnel
à mettre en place.
De plus, sur exercices que j’ai réalisé cette année en mathématique comme en
programmation sur les arbres, la stratégie récursive était quasiment prépondérante.
19
Rapport de Stage - CINES, Montpellier
La feuille de style que j’ai créé est donc organisée ainsi : à chaque élément qui
existe dans l’espace de nom lsd (donc un nœud qui décrit une structure de donnée),
correspond un modèle dans la feuille de style XSLT. Dans chaque modèle, je cherche à
déterminer certains éléments qui me permettent de décider de ce qui est à faire dans le
fichier final. Ces informations sont par exemple la place d’un nœud par rapport à
d’autres, la déclaration du nombre d’occurrences maximum, ou encore le type de
données.
Toujours avec l’exemple vu précédemment, il peut y avoir dans un document XSD
un nœud ‘élément’. En observant son contexte, on peut déduire que s’il est directement
sous la racine, c’est qu’il faut créer une classe, et donc implicitement une table. En
effet, en terme de base de données relationnelle, un attribut qui ne serait pas dans une
table ne pourrait pas exister.
Avant de fermer la déclaration de la classe, j’applique à nouveau tous les modèles.
Le processeur XSL va cette fois chercher à appliquer les modèles qui accepteraient de
traiter les nœuds qui sont enfant du nœud actuel.
Voici un exemple simplifié du modèle qui a généré le fichier de mappage donné
plus tôt :
<xsl:template match="xsd:element">
<xsl:choose>
<!-- Quand l'élément est au premier niveau, c'est surement qu'il
faut faire une classe-->
<xsl:when test="parent::xsd:schema" >
<class entity-name="{@name}"
table="{$tableprefix}{@name}"
node="{@name}" >
<id name="id_{@name}" type="long" >
<generator class="increment"/>
</id>
<xsl:apply-templates/>
</class>
</xsl:when>
</xsl:choose>
</xsl:template>
La première ligne indique que ce modèle va s’appliquer aux nœuds ‘xsd:element’.
Lorsque cette vérification est validée, on rentre dans une structure conditionnelle, qui va
effectuer certains tests. Dans le cas présent, lorsque le test chargé de vérifier que
l’élément en cours est un enfant de la racine du schéma XML
(“
test=’parent::xsd:schema’ “ — on fait appel à un élément parant dont le nom du nœud
serait xsd:schema, qui est le nœud racine d’un schéma XML. ) il faut écrire la
déclaration d’une classe telle qu’Hibernate l’attend.
Puis, avant de refermer la déclaration de la classe, les modèles sont à nouveau
appliqués avec ‘<xsl:apply-templates/>’.
Pour chaque élément d’un schéma XSD, il existe donc un modèle XSL qui va
déterminer comment l’élément doit être transformé pour aboutir à un fichier de
mappage Hibernate.
IV.4. Phase
de tests
IV.4.1. Tests
20
indépendants, classe par classe
Jean-Sylvain Granier - DUT Info. AS 2010/2011
Lors des phases de programmation, j’ai créé des méthodes main dans chaque
classe, qui me permettaient de tester individuellement de fonctionnement des classes.
Cela m’a permis de vérifier le comportement de base de celles-ci, et de constater que le
résultat était celui attendu. Et lorsque cela était redu possible par l’avancée du
développement, je faisais interagir les classes entre elles.
IV.4.2. Test
de la feuille de style xml2hbm.xml
Le langage XSLT étant quelque chose de totalement nouveau pour moi, j’ai
travaillé continuellement en testant la feuille de style que je mettais au point.
Pour ce faire, j’ai utilisé un excellent éditeur XML : Oxygen Xml Editor. Il permet,
dans une fenêtre partagée, d’éditer d’une part la feuille de style, et d’autre part, de
constater les effets de cette feuille de style appliquée sur un fichier XML que l’on
spécifie.
Je n’ai pas eu le temps de terminer cette feuille de style, donc je sais pertinemment
que le fichier de mappage Hibernate qui est créé est incomplet. J’ai d’ailleurs pu le
tester, puisque lorsque je lance une transformation depuis le module XGDB, puis que je
tente d’ouvrir la session Hibernate, le nouveau fichier de mappage est bloquant.
IV.4.3. Tests de l’ensemble du module XGDB
Affin de tester le fonctionnement complet du module, j’ai souhaité dans un premier
temps créer une petite application fictive, qui utiliserait le module, en essayant d’ajouter
des schémas de données, les données correspondantes, et de récupérer ces données.
Pour se faire, j’ai d'ailleurs demandé à mon tuteur un ensemble de fichiers de test,
incluant des fichiers XML et leurs schémas.
Le stade suivant était de remettre le module XGDB aux mains de mon tuteur, pour
qu’il puisse l’intégrer dans le projet ISAAC, et le faire fonctionner sur l’environnement de
développement global du projet.
Malheur sèment, par manque de temps, le module XGDB n’est pas terminé. Ces
phases n’ayant pas de sens à être réalisées si le module n’est pas terminé, ou en tout
cas fonctionnel, ces tests d’ensembles n’ont pas été réalisés.
21
Rapport de Stage - CINES, Montpellier
V. RESULTATS
À l’heure de la rédaction de ce rapport, et de la fin de mon stage au CINES, voici
un petit récapitulatif des résultats auxquels je suis parvenu en 10 semaines de travail :
V.1. Les
recherches préalables
En arrivant au CINES et après avoir pris connaissance de la problématique, ma
première tâche fut de faire une recherche sur les logiciels ou les méthodes déjà
existantes, qui seraient applicables dans le cadre du projet ISAAC. Le résultat de cette
étude (annexe V), nous a poussés dans la voie d’un développement interne, basé sur
une couche de persistance de données. Ce point permettant de créer un niveau
d’abstraction entre l’application métier, et le support de stockage (la base de données),
et évite notamment d’avoir à prendre en compte la structure de la BDD au sein même
de l’application métier.
V.2. La
stratégie élaborée
À partir des résultats de la veille technologique, j’ai élaboré une stratégie, et j’ai mis
au point l’architecture générale du module de transformation pour appliquer cette
stratégie.
Aujourd’hui, cette architecture semble encore cohérente. Mais l’ensemble n’étant
pas terminé, toutes les problématiques n’ont pas été soulevées. Cela est d’autant plus
vrai que n’étant pas un expert en XML, je ne suis pas habitué aux problématiques que
ce format de données soulève.
Parmi les problèmes pour lesquels je n’ai pas encore trouvé de solution, citons par
exemple la gestion des espaces de nom.
V.3. Développement
du module XGDB
J’estime qu’à l’heure actuelle, le pourcentage de complétion de la part de
développement sur ce module est de l’ordre de 50%.
La partie Java peut sembler fonctionnelle. En effet, les éléments essentiels sont là.
Mais la qualité de développement et la gestion des cas d’exception me semblent
inadaptées, vu la place essentielle que va prendre le module XGDB dans le projet
ISAAC.
De même, la partie XSLT n’est pas terminée : biens de cas de figure ne sont pas
pris en charge pour la transformation XSD vers HBM, et certaines parties déjà
développées nécessitent des corrections ou améliorations.
22
Jean-Sylvain Granier - DUT Info. AS 2010/2011
VI. DISCUSSION
VI.1. Un
modèle relationnel
hiérarchiques. Quel intérêt ?
pour
stocker
des
données
Le formalisme XML est un cas de représentation des données où un élément peut
être parant d’un autre élément, et enfant d’un élément supérieur. Et il en va de même
pour tous les éléments. Un flux XML est donc un arbre. Cela peut être très pratique
pour matérialiser la disposition des données, les relations qu’ont les données et les
informations entre elles.
Un autre intérêt du formalisme XML, c’est le système des balises, qui est
extrêmement flexible, et facile à comprendre. Ces qualités là en font un format privilégié
pour l’échange de données entre applications.
Pourtant, l’un des besoins exprimés pour le projet ISAAC, c’est que justement, ces
données soient transférées dans une base de données relationnelle.
Cette décision se justifie par une question de performances : sur un grand nombre
d’enregistrements, un gestionnaire de bases de données relationnel est plus performant
qu’un gestionnaire de bases XML. Et justement, le projet ISAAC se destine à recevoir
un grand nombre de fichiers, est les requêtes d’insertion, de sélection, mise à jour
doivent rester rapides, malgré cette quantité d’enregistrements.
VI.2. XSLT
pour transformer le fichier XSD
Afin de réaliser la transformation d’un schéma XLM en un fichier de mappage
Hibernate, j’ai choisi d’utiliser le langage XSLT.
Rétrospectivement, cela n’était peut-être pas un bon choix en terme de temps de
développement : créer une feuille de style de transformation implique de manipuler un
arbre avec des requêtes xPath, et cela implique aussi une logique de développement
bien particulière. Cela constitue un ensemble important de connaissances à mettre en
place avant de pouvoir fournir un travail efficace. Le temps que j’ai passé à apprendre à
utiliser le langage XSLT et xPath a certainement été un facteur déterminant sur les
résultats atteints à l’heure de ce bilan.
Pour réaliser une transformation XSD vers HMB, d’autres approches sont
possibles. Notamment, il est possible de parcourir un schéma XSD depuis le code
Java, avec un objet de la classe com.sun.xml.xsom.XSSchemaSet. C’est une classe
spécifiquement dédiée à la manipulation de schémas XML.
Apprendre à manipuler le XSLT était une expérience très enrichissante pour moi,
mais peut-être que j’aurais dû choisir une approche demandant moins de
connaissances et donc aboutir à un résultat plus rapidement.
VI.3. Presque
tout est à terminer. Pourquoi ?
Dans un premier temps, il faut préciser qu’en arrivant au CINES, je savais très peu
de choses sur la manipulation de fichiers XML. Même si j’en avais déjà vu, déjà
manipulé via le XHTML, je n’étais jamais entré autant dans les détails comme le
nécessitait la mission qui m’a été confiée pendant ce stage.
23
Rapport de Stage - CINES, Montpellier
Mon manque de connaissance en XML (autant sur le plan théorique que sur
l’expérience de manipulation de ce format) a donc été un élément crucial, qui m’a
beaucoup ralenti dans ma démarche. Et malgré les importants efforts que j’ai fournis
pour combler cette différence de niveau, cela n’a pas été suffisant pour terminer le
module à temps.
À la suite de la veille technologique, je me suis engagé dans un premier temps sur
une architecture qui faisait intervenir JAXB (Transition entre flux XML et classes Java),
en plus de Hibernate. Pendant deux semaines, j’ai essayé de travailler sur cette version
du module XGDB. Au terme de ces deux semaines, voyant les difficultés
supplémentaires que cela engendrait, mon tuteur et moi avons pris la décision de
simplifier davantage le module, en nous séparant de JAXB. Mais nous aurions dû
prendre cette décision bien plus tôt.
D’autre part, en élaborant l’architecture du module (utilisation d’Hibernate,
transformation XSLT…), je ne me suis pas rendu compte qu’implicitement, je
m’engageais sur une période très courte à acquérir un bon niveau en XML, en XSD, à
apprendre à manipuler Hibernate, à savoir faire du mappage Hibernante avec des
fichiers XSD, et à être bon en XSLT. Je savais qu’il allait falloir utiliser ces éléments,
mais je ne soupçonnais pas les difficultés que j’allais rencontrer pour apprendre à les
manipuler, et trouver une solution pour les imbriquer.
Enfin, cette différence entre les difficultés que je m’attendais à rencontrer, et celles
réellement rencontrées n’ont eu de cesse de me décaler dans le temps de
développement. C’est la raison pour laquelle le planning prévisionnel (Annexe 1) n’a
pas été respecté.
24
Jean-Sylvain Granier - DUT Info. AS 2010/2011
VII. CONCLUSION
Ma mission lors de ce stage était de mettre en place une solution permettant de
stocker des données XML dans une base de données relationnelle.
J’ai donc dans un premier temps réalisé des recherches sur les solutions
existantes. Je suis arrivé à la conclusion qu’il fallait créer un module personnalisé pour
pouvoir répondre à certains de nos besoins très spécifiques.
J’ai alors conçu un module faisant appel à divers éléments recueillis lors de la
phase de recherche. Par la suite, j’ai tenté de programmer ce module, en respectant le
schéma préalablement établi.
D’un point de vue personnel, j’ai pu appliquer des connaissances acquises pendant
mon DUT Informatique, notamment en génie logiciel, en base de données et en
programmation orientée objet. De plus, ce stage m’a apporté beaucoup de
connaissances en XML, XSLT, xPath et en Java. J’ai aussi pu me familiariser avec la
notion de persistance de données, qui est une approche de plus en plus courante dans
le développement orienté objet. D’avoir été en difficulté m’a aussi permis de me rendre
compte qu’il est délicat d’estimer le temps de travail nécessaire pour aboutir à un
résultat final. Ce fut aussi pour moi l’occasion d’être confronté à mes limites, ce qui est
important pour évoluer par la suite.
Initialement, j’avais choisi ce stage car j’avais précédemment travaillé avec des
médecins. Ceux-ci utilisent des logiciels de gestion patient, et j’avais été confronté de
nombreuses reprises à un problème d’archivage de données sur une longue période.
Mais par la charge de travail que j’ai eue, je n’ai pas vraiment eu le temps de
m’intéresser à ce qui fait qu’un archivage est pérenne. J’ai seulement survolé certains
aspects qui entraient en compte dans le cadre de mon projet (métadonnées
principalement).
Malgré ce point là, j’ai découvert beaucoup de choses pendant ces 10 semaines, et
ce stage aura été très constructif pour la suite de mes études et pour mon parcours
professionnel.
Du point de vue de ma mission au CINES, les résultats auquel j’ai abouti sur la
partie programmation est insuffisants. Même si j’ai apporté un concept pour résoudre la
problématique initiale, je n’ai pas réussi à transposer ce concept en application
fonctionnelle pendant le temps imparti.
Toutefois, je pense avoir laissé suffisamment de délivrables et de commentaires
dans les éléments déjà développés pour que mon travail puisse être terminé
ultérieurement.
Au-delà des difficultés rencontrées, ce stage a été pour moi une expérience très
enrichissante du point de vue de la mise en pratique de connaissance, de l’acquisition
de nouvelles compétences, et de la découverte d’un nouveau milieu de travail qu’est
celui de la recherche dans l’enseignement supérieur.
25
ANNEXES
Annexe I. Diagramme de GANTT : Planning prévisionnel de stage
Annexe II. Organigramme du CINES
Annexe III. L’Archivage Pérenne
Réaliser un document qui aborde les points suivants
Sauvegarde != Archivage
Cycle de vie d’un document
L’obsolescence technologique
Se baser sur le travail de Benjamin Huc
Avec département DAD détaillé.
Annexe IV. Veille technologique portant sur le stockage XML
Annexe V. Diagramme de XGDB : Interactions entre l’application métier,
XGDB, Hibernate et Postgre SQL.
Annexe VI. Diagramme des Classes de XGDB
Annexe VII. Spécifications fonctionnelles du module XML vers SGBDR.
RESUME
Le Centre Informatique National de l’Enseignement Supérieur de Montpellier réalise une
plateforme d’archivage intermédiaire de données scientifiques.
Ces données scientifiques sont accompagnées de métadonnées descriptives, transmises au
format XML. Par la suite, ces métadonnées doivent être transférées dans une base de données
relationnelle. La problématique étant qu’un fichier XML n’a pas une structure similaire à une base de
données rationnelle.
Ce rapport présente succinctement les diverses approches qui sont possibles pour résoudre ce
problème de transition XML vers SGBDR, et détaille la mise en place d’une technique en particulier.
Mots clefs : XML, xPath, XSLT, Java, Base de données
ABSTRACT
The CINES (Centre Informatique National de l’Enseignement Supérieur — a computer research
center in Montpellier, France) develops a platform for scientific data.
These scientific data are accompanied by descriptive metadata, through an XML file. After that,
these meta-data must be transferred into a relational database. The problem is that XML does not
have a structure similar to a relational database.
This report presents briefly the various approaches that are possible to solve the problem of
transition from XML to relational database, and details the development of a technique in particular.
Keywords: XML, XPath, XSLT, Java, Database