Una visione (molto) di alto livello sull'architettura di Hibernate:
Questo diagramma mostra come Hibernate usa il database e i dati di configurazione per fornire servizi di persistenza (e oggetti persistenti) all'applicazione.
Vorremmo mostrare una vista più dettagliata dell'architettura di runtime. Sfortunatamente Hibernate è flessibile, e rende possibili diversi approcci: mostreremo quindi i due estremi. L'architettura "leggera" è quella in cui l'applicazione fornisce le sue connessioni JDBC e gestisce le transazioni. Questo approccio usa un sottoinsieme minimale delle API di Hibernate.
L'architettura "completa" di Hibernate, permette all'applicazione di astrarre dai dettagli delle API JDBC/JTA e lascia che se ne occupi Hibernate.
Ecco alcune definizioni degli oggetti nei diagrammi:
È una cache immutabile e "thread-safe" di mappaggi compilati per un database singolo. Allo stesso tempo è un factory per oggetti Session e un client di ConnectionProvider. Potrebbe contenere una cache di secondo livello opzionale riutilizzabile tra le transazioni, sia a livello di processo, sia a livello di cluster.
È un oggetto mono-thread, di corta durata, che rappresenta una conversazione tra l'applicazione e il contenitore persistente. Incapsula una connessione JDBC. È un factory per oggetti Transaction. Mantiene una cache obbligatoria (di primo livello) per gli oggetti persistenti, usata quando si naviga il grafo degli oggetti o si ricercano oggetti per identificatore.
Sono oggetti di corta durata, a thread singolo, che contengono stato persistente e funzioni applicative. Potrebbero essere normali oggetti POJO/Javabeans, con l'unica particolarità che in un dato momento sono associati con (esattamente) una Session. Nel momento in cui la Session viene chiusa, verranno staccati e saranno liberi di essere usati in qualsiasi strato applicativo (ad esempio direttamente come oggetti di trasferimento dei dati da e allo strato di presentazione).
Sono le istanze delle classi persistenti che in un dato momento non sono associate con una Session. Possono essere state istanziate dall'applicazione e non (ancora) rese persistenti, o possono essere state istanziate da una Session poi chiusa.
(Opzionale) È un oggetto a thread singolo, di corta durata, usato dall'applicazione per specificare unità di lavoro atomiche. Separa le applicazioni dalla transazione JTA, CORBA o JDBC sottostante. Una Session potrebbe estendersi lungo varie Transaction in certi casi.
(Opzionale) Un factory (e pool) di connessioni JDBC. Astrae le applicazioni dai dettagli dei sottostanti Datasource o DriverManager. Non viene esposta all'applicazione, ma può essere estesa/implementata dagli sviluppatori.
(Opzionale) Un factory per istanze di Transaction. Non viene esposta all'applicazione, ma può essere estesa/implementata dagli sviluppatori.
In un'architettura "leggera", l'applicazione aggira le API Transaction/TransactionFactory e/o ConnectionProvider per parlare direttamente con JTA o JDBC.
JMX è lo standard J2EE per lo standard o la gestione di componenti Java. Hibernate può essere gestito tramite un MBean standard JMX, ma poiché molti application server non supportano ancora JMX, Hibernate consente anche di usare alcuni sistemi di configurazione non-standard.
Per cortesia, leggete il sito web di Hibernate per informazioni aggiuntive su come configurare Hibernate in modo tale da funzionare come componente JMX in JBoss.