JBoss a sorti la version 4 d'Hibernate, le framework de mapping Objet/Relationnel le plus populaire. Les principales nouveautés de cette version sont:
- Le support du Multi-tenancy
- L'introduction d'une API "Services"
- De meilleurs logs avec l'internationalisation des messages et des codes d'erreur (via JBoss Logging au lieu de SLF4J)
- La préparation du support d'OSGi
- Du nettoyage de code et la suppression de code déprécié.
Le Multi-tenancy est la capacité à partitionner virtuellement les clients (aussi appelés tenants) d'une grosse application d'entreprise, au lieu d'avoir toutes les données concentrées dans un seul et même espace. Ce principe permet des améliorations dans la gestion, le monitoring et même la sécurité, et se révèle très utile pour les gros fournisseurs de services. Les entreprises qui proposent des infrastructures de type cloud pourront aussi tirer partie du Multi-tenancy. Il y a plusieurs façons d'implémenter ce principe, notamment:
- Une base de données et/ou un schéma distincts pour chaque client/tenant
- Une même base de donnée/schéma pour tous les clients mais avec une colonne supplémentaire (par exemple tenant_id) dans toutes les tables destiné à filtrer les données.
Dans cette version 4.0, Hibernate supporte la première méthode. Le support de la seconde (multi-tenancy basé sur un discriminant) est prévu pour la prochaine version.
Une autre nouveauté importante est l'apparition d'une API "Services" dans Hibernate. Cette API permet d'étendre Hibernate de différentes manières au delà des services fournis en standard. Il était certes déjà possible de se brancher sur les entrailles d'Hibernate mais l'API Services propose un moyen clair et formalisé de la faire. InfoQ a contacté le leader du projet, Steve Ebersole, pour en savoir plus sur ces nouvelles fonctionnalités.
InfoQ: Pourriez-vous nous expliquer le concept de "Services" ? Sont-ils destinés uniquement aux extensions d'Hibernate, ou bien pourraient-il être utiles aux développeurs d'application aussi.
D'abord, je pense qu'il est important de comprendre que beaucoup de développeurs d'applications développent aussi des extensions Hibernate lors du développement de leurs applications. Si vous développez vos propres "event listener", vos propres types utilisateur... vous développez déjà des extensions Hibernate. Ce n'est pas un scénario nouveau.
Il faut voir l'API Services comme une implémentation simplifiée de CDI destinée à fournir une solution unifiée aux besoins courants comme le cycle de vie, les dépendances, la gestion de JMX, etc. Donc, sous cet angle, oui, je vois des développeurs produire des Services assez fréquemment. Un exemple facile est un "event listener" qui voudrait envoyer des messages JMS. Je vois JMS comme un Service parce que d'autres listeners, ou d'autres extensions, pourraient aussi profiter de cette connexion JMS.
Mais l'idée de Service est très ouverte. Est-ce que je vois du "code applicatif" accéder et utiliser directement à ces Services ? Non, pas en règle générale. Mais cela ne veut pas dire que tout le monde le verra de cette façon. Pour revenir à mon cas d'utilisation de JMS, on peut aisément imaginer que le code applicatif ait aussi besoin de cette connexion JMS: Il pourrait potentiellement l'obtenir d'Hibernate. Bref, cela reviendrait à utiliser Hibernate pour gérer l'intégralité du cycle de vie.
InfoQ: Quelle est l'importance d'OSGi pour vous ? Hibernate est-il loin de supporter entièrement OSGi ?
C'est une question intéressante. D'expérience, quand nous commençons à réellement en parler, la plupart des gens qui demandent ce que signifie pour eux "supporter OSGi" ou bien "être compatible OSGi", soit ils ne savent pas, soit ils ont des réponses très différentes. A mon avis, il y a deux réponses:
D'une part, est-ce que Hibernate peut travailler de manière modulaire en ce qui concerne le chargement des classes dans les environnements OSGi ? C'était très difficile avant la version 4.0, parce qu'avant Hibernate s'attendait à trouver un ClassLoader conventionnel. Dans la 4.0, un des grand services est le ClassLoaderService qui définit comment Hibernate recherche les classes et les ressources, mais aussi comment il cherche les ServiceLoader Java standards. Cela revient à définir une API pour toutes les interactions d'Hibernate avec le ClassPath. Et encore plus important, il définit cela d'une manière interchangeable. L'objectif est ici de permettre aux environnements utilisant un mécanisme de chargement de classes non-traditionnel, de changer la stratégie par laquelle Hibernate intéragit avec les ClassLoader. Cela a été testé intensivement dans JBoss, qui possède son propre ClassLoaderService avec son propre chargement modulaire des classes. Donc de ce point de vue, Hibernate a atteint son objectif.
D'autre part, quelle est la qualité des "metadonnées OSGi" définies par Hibernate en termes d'imports/exports ? Aujourd'hui, Hibernate ne définit aucune métadonnée OSGi spécifique dans ses jars. Quand quelqu'un contribuera à cette tâche, nous incluerons son travail. Ce qu'il faut voir, c'est que personne dans l'équipe Hibernate n'est expert OSGi. C'est une tâche pour quelqu'un, qui à l'habitude d'écrire ce genre de métadonnées, et qui a un intérêt certain pour ce genre de tâche. Nous avons décidé à ce sujet de découper les packages dans cette version 4.0, afin de mieux illustrer le public cible et qui, si je comprends bien, devrait faciliter l'écriture d'exports adéquats.
InfoQ: Why was the logging framework changed ?
Quand le développement d'Hibernate 4 a démarré nous avons décidé que nous avions vraiment besoin de logs internationnalisés. A ce moment, JBoss Logging était, à notre connaissance, la seule librairie de logs qui supportait l'internationalisation, y compris dans le paramétrage. Cette internationalisation est de la même veine que GNU gettext, que l'équipe de développement Hibernate a préféré, par un large consensus, à une approche basée sur les ResourceBundle. JBoss Logging supporte aussi l'internationalisation des messages des exceptions à travers une approche classique, mais nous n'utilisons pas cette fonctionnalité.
De plus, JBoss Logging inclut nativement des clés de messages qui diffèrent de la notion de clé dans les ResourceBundle. Il s'agit plutot d'une clé qui ne change jamais, associée à la condition qui a amené le message à être loggué. C'est très pratique pour construire des FAQs et des documentations autour de ces clés. Oui, vous pourriez bricoler quelque chose de semblable avec SLF4J, Java Util Logging, etc directement. Mais d'un point de vue outillage, je dirais qu'il est impératif que les clés soient des citoyennes de premier ordre. Pour les grands projets avec beaucoup des logs, vous avez vraiment besoin de valider que ces clés sont uniques est consistantes. JBoss Logging sert aussi à ca.
InfoQ: certains diront que ces fonctionnalités sont essentiellement internes. Est-ce que cela signifie qu'Hibernate a atteint un niveau de maturité où plus aucun changement visible de l'utilisateur ne sera apporté ? Hibernate est-il passé en mode "Maintenance" ?
Non, Hibernate n'est certainement pas passé en mode maintenance en termes de nouvelles fonctionnalités pour les développeurs. A-t-il besoin de maintenance ? Oui bien sûr. Je ne suis pas sûr que tout le monde s'en rende compte, mais Hibernate a maintenant 10 ans. Cela fait longtemps que les pansements se sont accumulés. Je pense que nous avons juste atteint un moment où nous devons nous arrêter de mettre des pansements par dessus les pansements, d'autant plus que nous envisageons de développer de nouvelles fonctionnalités. Hibernate est basé sur les principes YAGNI et en particulier la notion que les contrats/APIs apparaitraient naturellement au fil du temps. Donc il y a un peu de ça aussi.
Je pense qu'il n'y a qu'une poignée de projets Java open-source qui sont là depuis longtemps, qui ont encore du succès, qui sont toujours d'actualité, et tous ont traversé un ou plusieurs refactorings importants.
InfoQ: Que pouvons nous attendre d'Hibernate 5 ? Vers quoi s'oriente le développement actuellement ?
La version 5.0 se focalisera sur un refactoring du modèle qu'Hibernate utilise pour conserver les métadonnées de mapping O/R, provenant à la fois du XML et des annotations. Ce code est issus des besoins initiaux d'Hibernate. Les nouveaux besoins de JPA ou les nouvelles fonctionnalités étaient simplement coincés par le modèle historique. La raison principale à cela est que beaucoup de projets utilisent ce jeu de classes et que, jusqu'ici, nous voulions éviter de les perturber. Mais il est grand temps de repenser ce modèle.
Les artefact Java sont déjà dans Maven Central, donc Hibernate 4 est prêt à être inclus dans les applications Java
Kostis Kapelonis Ingénieur logiciel spécialisé dans les applications d'entreprise.