métier

Découverte de JAXB

pour sérialiser en XML le contenu d'une table de base de données Publié par Éric Le Merdy

Dans ce post, j'applique la sugession Chad Fowler dans son livre “My Job Went to India: All I Got Was This Lousy Book”: pour être sûr qu'on a bien compris quelquechose, il faut essayer de l'expliquer.
Voyons ce qu'est JAXB. Ma problématique est d'écrire le contenu d'une table relationnelle en XML. La structure de la table est déjà créée et le format XML déjà connu. Le but est de trouver le moyen le plus adapté dans le langage java.
Après avoir refoulé immédiatement l'idée d'écrire la sauce XML dans un fichier, je me suis intéressé à JAXB.

  1. En entrée, on a un fichier XML “en production”, c'est-à-dire déjà généré il y a quelques années. Or JAXB prend un fichier de structure en entrée. Il est possible de trouver sur internet un service "xml2xsd" qui analyse un fichier XML et en extrait un schéma possible. Après avoir contrôlé ce schéma et supprimé toutes les références aux namespaces propriétaires (de Microsoft pour ne pas le citer), on a notre schéma.
  2. La phase de génération de code de JAXB intervient ici. Voilà la commande à lancer:
    %JDK_HOME%/bin/xjc schema.xsd
    
    Elle permet de générer une implémentation java d'objets qui se conforment au schéma. On dispose donc d'une hiérarchie d'objets de style javabean qui peuvent recevoir autant de données qu'un fichier XML implémentant le schéma XML.
  3. Ensuite, il faut écrire le code jdbc pour se connecter à la base, requêter la table et extraire les données à plat dans une instanciation de notre hiérarchie d'objets. Concrètement, on instancie l'objet qui représente la balise root et on remplit !
  4. Finalement, il ne reste qu'à faire un marshall (c'est-à-dire une exportation) des objets dans un fichier.

Discussion

Avantages:

  • Rapide, la génération de code
  • Léger, le code à écrire soi-même
  • En Bonus, le unmarshalling au cas où on voudrait lire le fichier XML ailleurs.

Inconvénients:

  • Dangereuse, la génération de code lorsque le schéma va changer, on a clairement deux endroits où sont stockés l'information de structure XML : dans le XSD et dans la hiérarchie d'objets générés…
  • Lourd, la hiérarchie d'objets en mémoire lorsque les volumes de données sont importants

Conclusion: positive pour mon usage.
Evolution: intégrer la génération de code dans la procédure ant pour détecter les changements du schéma ?

Pour en savoir plus, je vous propose consulter cette présentation : JAXB.ppt

Crédits photos: JAXB-data-binding-process2.gif