Voici une vue (très) haut niveau de l'architecture d'Hibernate :
Ce diagramme montre Hibernate utilisant une base de données et des données de configuration pour fournir un service de persistance (et des objets persistants) à l'application.
Nous aimerions décrire une vue plus détaillée de l'architecture. Malheureusement, Hibernate est flexible et supporte différentes approches. Nous allons en montrer les deux extrêmes. L'architecture légère laisse l'application fournir ses propres connexions JDBC et gérer ses propres transactions. Cette approche utilise le minimum des APIs Hibernate.:
L'architecture la plus complète abstrait l'application des APIs JDBC/JTA sous-jacentes et laisse Hibernate s'occuper des détails.
Voici quelques définitions des objets des diagrammes :
Un cache threadsafe (immuable) des mappings vers une (et une seule) base de données. Une factory (fabrique) de Session et un client de ConnectionProvider. Peut contenir un cache optionnel de données (de second niveau) qui est réutilisable entre les différentes transactions que cela soit au niveau processus ou au niveau cluster.
Un objet mono-threadé, à durée de vie courte, qui représente une conversation entre l'application et l'entrepôt de persistance. Encapsule une connexion JDBC. Factory (fabrique) des objets Transaction. Contient un cache (de premier niveau) des objets persistants, ce cache est obligatoire. Il est utilisé lors de la navigation dans le graphe d'objets ou lors de la récupération d'objets par leur identifiant.
Objets mono-threadés à vie courte contenant l'état de persistance et la fonction métier. Ceux-ci sont en général les objets de type JavaBean (ou POJOs) ; la seule particularité est qu'ils sont associés avec une (et une seule) Session. Dès que la Session est fermée, ils seront détachés et libre d'être utilisés par n'importe laquelle des couches de l'application (ie. de et vers la présentation en tant que Data Transfer Objects - DTO : objet de transfert de données).
Instances de classes persistantes qui ne sont actuellement pas associées à une Session. Elles ont pu être instanciées par l'application et ne pas avoir (encore) été persistées ou elle ont pu être instanciées par une Session fermée.
(Optionnel) Un objet mono-threadé à vie courte utilisé par l'application pour définir une unité de travail atomique. Abstrait l'application des transactions sous-jacentes qu'elles soient JDBC, JTA ou CORBA. Une Session peut fournir plusieurs Transactions dans certain cas.
(Optionnel) Une fabrique de (pool de) connexions JDBC. Abstrait l'application de la Datasource ou du DriverManager sous-jacent. Non exposé à l'application, mais peut être étendu/implémenté par le développeur.
(Optionnel) Une fabrique d'instances de Transaction. Non exposé à l'application, mais peut être étendu/implémenté par le développeur.
Dans une architecture légère, l'application n'utilisera pas les APIs Transaction/TransactionFactory et/ou n'utilisera pas les APIs ConnectionProvider pour utiliser JTA ou JDBC.
JMX est le standard J2EE du configuration des composants Java. Hibernate peut être configuré via une MBean standard. Mais dans la mesure où la plupart des serveurs d'application ne supportent pas encore JMX, Hibernate fournit quelques mécanismes de configuration "non-standard".
Merci de vous référer au site web d'Hibernate pour de plus amples détails sur la façon de configurer Hibernate et le faire tourner en tant que composant JMX dans JBoss.