Newsletter April 2006 Einleitung Der OR-Mapper Hibernate hat inzwischen eine sehr weite Verbreitung erreicht nach eigenen Angaben ist Hibernate der klare Marktführer bei OR-Mappern. Immer mehr Projekte nutzen Hibernate, das inzwischen in der Version 3 vorliegt, um auf einfache Art und Weise ihre Java-Objekte in relationalen Datenbanken zu speichern. Dieser Newsletter erläutert die Funktionsweise von Hibernate, zeigt die Vorteile, die sich beim Einsatz von Hibernate ergeben und gibt einen Ausblick auf die Zukunft von Hibernate im Zusammenhang mit EJB 3. Der Gesamtzusammenhang Gavin King gründet das Hibernate-Projekt im November 2001 unter der Open-Source-Plattform Sourceforge. Im Juni 2003 wird Hibernate 2.0 veröffentlicht und erreicht eine sehr große Verbreitung (mehrere 10.000 Downloads pro Monat). Die Industrie beginnt, sich ernsthaft für Hibernate zu interessieren. Im Oktober 2003 integriert sich Hibernate in die JBoss-Gruppe. Im April 2004 gibt es eine Million Klicks auf www.hibernate.org. Im Juni 2004 erscheint die Draft-Version von EJB 3, dessen Persistenzmodell erheblich von Hibernate beeinflusst wurde. Im März 2005 wird Hibernate 3.0 veröffentlicht. Diese Entwicklung hat zwei wesentliche Kritikpunkte an Hibernate entkräftet: Hibernate wurde vorgeworfen, so genannte Guru-Software zu sein. Hibernate sei abhängig vom Projektgründer Gavin King. Inzwischen beteiligen sich viele andere Programmierer an der Weiterentwicklung von Hibernate. Außerdem ist durch den Beitritt von Hibernate zur JBoss-Gruppe auch ein kommerzieller Firmenhintergrund für Hibernate geschaffen worden. Hibernate wurde die fehlende Standardisierung entgegengehalten. Durch den Einfluss von Hibernate auf das Persistenzmodells von EJB 3 sowie die Verbreitung von Hibernate kann man bereits heute von einem Quasi-Standard sprechen. Der Migrationspfad zu EJB 3 ist bereits heute in Hibernate angelegt und damit steht auch der formalen Standardisierung nichts im Weg. Funktionsweise von Hibernate Hibernate verfolgt den Ansatz transparenter Persistenz mit POJOs (POJO = Plain Old Java Object). Das bedeutet, dass die Geschäftsobjekte nicht geändert werden müssen, um persistierbar zu sein. Sie werden wie ganz normale nicht-persistente Geschäftsobjekte programmiert (siehe Code-Beispiel 1 im Anhang). Wie die Geschäftsobjekte auf die Datenbank abgebildet werden, wird in Mappingdateien beschrieben, die im XML-Format definiert werden. In den Mappingdateien wird festgelegt, welche Geschäftsobjekte persistent sein sollen, welche Felder wie in der Datenbank abzulegen sind und welche Beziehungen zu anderen persistenten Geschäfttsobjekten existieren (siehe Code-Beispiel 2 im Anhang). Dabei können die Mappingdateien sehr schlank ausfallen, weil Hibernate die meisten Definitionen selbst mit sinnvollen Defaultwerten bestücken kann. So ist für das Schreiben und Pflegen der Mapping-Dateien nur geringer Aufwand notwendig.
Die Mappingdateien können über XDoclet auch aus Java-Quellcode generiert werden (siehe [2] und [4]). Darüber hinaus unterstützen vielen MDA 1 - und MDSD 2 -Werkzeuge die Generierung von Hibernate-Mappingdateien. Wenn das System gestartet wird, liest Hibernate die Mappingdateien ein und generiert zur Laufzeit Bytecode, der für die transparente Persistenz sorgt. Java-VM Termin.java javac Termin.class Hibernate Termin.class Der Anwendungscode, der mit den persistenten Geschäftsobjekten umgeht, ist natürlich abhängig von Hibernate. Er muss insbesondere das Suchen, Laden und Speichern von Geschäftsobjekten initiieren. Dabei spielt die Klasse Session eine zentrale Rolle (siehe Code-Beispiel 3 im Anhang). Sie stellt die Funktionen zum Laden, Speichern und Löschen von Geschäftsobjekten zur Verfügung, erledigt das Caching und stellt den Zugang zu den Hibernate-Abfragemöglichkeiten dar. Hibernate Datenbank Anwendungscode Geschäftsobjekte Datenbank-Abfragen werden in HQL (Hibernate Query Language) definiert. Die HQL ist an SQL angelehnt, so dass sie mit SQL-Grundkenntnissen leicht zu erlernen ist (siehe Code-Beispiel 4 im Anhang). Außerdem kann Hibernate so die HQL performant auf SQL abbilden. 1 MDA=Model Driven Architecture 2 MDSD=Model Driven Software Development
Performance Ein wichtiges Kriterium für OR-Mapper ist die Performance. Hibernate benutzt eine Mischung aus Bytecode- Generierung und Core-Reflection, die zu einem vernachlässigbar kleinen Overhead führt. Bei der direkten Datenbank-Kommunikation spielt Hibernate seine Stärken aus. Hier wirken sich primär drei Hibernate-Konzepte positiv aus: 1. Spezifische Datenbank-Adapter 2. Caching pro Session (First Level Cache) 3. Lazy-Loading (Load on Demand) Hibernate nutzt die standardisierte JDBC-Schnittstelle zum Zugriff auf die Datenbank. Gleichzeitig verwendet Hibernate spezifische Datenbank-Adapter, die Detailwissen über das konkrete Datenbank-Management-System besitzen. Sie ist es Hibernate möglich, Optimierungen ganz genau auf das verwendete Datenbank-Management- System zuzuschneiden. Die Verwendung der Datenbankadapter ist dabei für den Entwickler transparent. Er muss nur in einer Konfigurationsdatei den verwendeten Datenbanktyp angeben. Eine Programmanpassung bei Änderung des verwendeten Datenbanksystems ist nicht notwendig. Hibernate bringt spezifische Datenbank-Adapter für alle gängigen Datenbank-Management-Systeme (DB2, Oracle, mysql, PostgreSQL, etc.) mit. Speichert die Anwendung ein Geschäftsobjekt über Hibernate, wird das Objekt nicht sofort in die Datenbank geschrieben. Stattdessen wird das Geschäftsobjekt zunächst in einem Cache zwischengespeichert. Erst wenn die Transaktion abgeschlossen oder der Cache explizit geleert wird, werden die Geschäftsobjekte auch in die Datenbank geschrieben. Wird ein Objekt angefordert, dass sich bereits im Cache befindet, wird es direkt von dort geliefert ein Datenbankzugriff ist nicht notwendig. Dadurch wird die Anzahl der Datenbankzugriffe deutlich reduziert und die Dauer von Transaktionen auf der Datenbank minimiert. Werden Objekte geladen, arbeitet Hibernate mit Lazy-Loading. Das bedeutet, dass immer nur so viele Daten aus der Datenbank geladen werden, wie im Moment benötigt werden. Werden weitere Daten benötigt, werden diese transparent nachgeladen. Weiß die Anwendung bereits vorher, dass sie viele Daten auf einmal benötigen wird, kann sie mit Join-Fetching das Lazy-Loading auch gezielt ausschalten. Insgesamt kann man festhalten, dass Hibernate sehr guten SQL-Code generiert, der häufig sogar handoptimiertem SQL überlegen ist. Sollte es einmal Hart auf Hart kommen, kann man Hibernate immer noch sein eigenes hoch optimiertes SQL unterschieben.
Vorteile von Hibernate Die Verwendung von Hibernate bringt viele gewichtige Vorteile mit sich: Hibernate erlaubt ein performantes OR-Mapping unter Ausnutzung der spezifischen Datenbankmöglichkeiten, ohne vom konkreten Datenbank-Management-System abhängig zu werden. Geschäftsobjekte müssen für die Verwendung mit Hibernate nicht angepasst werden (Hibernate ist minimal-invasiv). Hibernate ist Open-Source. Dadurch entfallen nicht nur die Lizenzkosten. Viel wichtiger ist die Möglichkeit, durch Lesen des Quelltextes ein besseres Verständnis der Hibernate-Funktionsweise zu bekommen. Da man so auch in den Hibernate-Quelltext hinein debuggen kann, ist bei Fehlerfällen auch leicht festzustellen, ob das Problem bei Hibernate oder in der eigenen Anwendung besteht. Das ist insbesondere während der Lernphase sehr wichtig. Gleichzeitig erhöht sich die Investitionssicherheit, weil man Bugs zu Not selbst beheben kann. Durch den Einsatz von Hibernate lassen sich ca. 30% Anwendungscode im Gegensatz zur Programmierung auf JDBC-Basis sparen. Weniger Code bedeutet höhere Produktivität und geringere Fehlerwahrscheinlichkeit. Hibernate hat sich als Quasi-Standard etabliert. Es gibt sehr viele Entwickler mit Hibernate-Know-How, sehr viele Informationsmöglichkeiten im Internet und eine gute Unterstützung in anderen Werkzeugen und Frameworks (z.b. auch im Spring-Framework, siehe [5]). In EJB 3 wird das Persistenzmodell runderneuert und an Hibernate ausgerichtet. Wer heute Hibernate einsetzt, befindet sich bereits auf dem Weg hin zu EJB 3. Dem Quasi-Standard folgt also der offizielle Industriestandard. Gegenüber JDO (siehe [6]) bringt Hibernate eine Reihe von Vorteilen mit sich: o Bei JDO ist die Generierung von Bytecode ein eigener Post-Compile-Lauf, der den Build- Prozess verkompliziert und die Entwicklung verlangsamt. o JDO gibt es bis heute nur von kommerziellen Herstellern, so dass z.t. erhebliche Lizenzkosten anfallen. o Support gibt es daher ebenfalls nur direkt vom Hersteller, während sich bei Hibernate eine riesige weltweite Community entwickelt hat, die sich gegenseitig bei Problemen hilft. o Während Hibernate aus der direkten Praxiserfahrung entstanden ist, wurde JDO am grünen Tisch entworfen. Viele Probleme wurden erst im Nachhinein beim Praxiseinsatz deutlich, so dass die JDO-Spezifikation geändert werden musste. Diese Anpassung der Spezifikation an die Praxisbedürfnisse und die Umsetzung der neuen Spezifikation durch die Hersteller ist ein langwieriger Prozess. Zwangsläufig haben die JDO-Hersteller eigene spezifische Erweiterungen in ihre JDO-Produkte eingebaut, die die Softwareprojekte von Ihnen abhängig machen (so genanntes Vendor Lock In). Gegenüber Entity-Beans (siehe [7]) ist Hibernate deutlich leichtgewichtiger, einfacher zu programmieren und vor allem auch ohne Application-Container lauffähig. Letzteres mag für den Produktiveinsatz des Systems nur ein sekundäres Argument sein. Allerdings kann dadurch während der Entwicklung so manches langwierige Deployment vermieden werden. Außerdem erhöht es die Testbarkeit ernorm.
Die Zukunft von Hibernate Hibernate wird den kommenden Standard EJB 3 unterstützen und unterstützt heute bereits die wesentlichen Anteile des Persistenz-APIs von EJB 3, so dass eine spätere Migration mit überschaubarem Aufwand möglich ist. Lediglich die Hibernate-Mappingdateien müssen durch Java-5-Annotationen ausgetauscht werden. Dabei wird die Beschreibung der Persistenzeigenschaften mit EJB 3 noch etwas einfacher: Während bei Hibernate jedes nicht spezifizierte Feld eines Geschäftsobjekte transient ist, ist es bei EJB 3 genau umgekehrt. Per Default sind alle Felder eines Geschäftsobjektes persistent. Nur transiente Felder müssen explizit deklariert werden. Zusammenfassung Am Thema Hibernate kommt man heute nicht vorbei. Die Alternativen sind entweder zu schwergewichtig, zu instabil, funktional zu schwachbrüstig oder einfach noch nicht verfügbar. Mindestens jetzt neu gestartete Java- Projekte sollten Hibernate ernsthaft evaluieren. Unser Angebot zu Hibernate Wir setzen Hibernate seit Langem in unseren eigenen Projekten ein. Darüber hinaus arbeiten drei Hibernate-Buchautoren (siehe [2]) bei uns und bieten Beratung und Schulungen zur Hibernate- Einführung an. Ausführliche Informationen finden Sie unter hibernate.akquinet.de.
Referenzen 1. Hibernate: http://www.hibernate.org 2. Robert Beeger, Arno Haase, Stefan Roock, Sebastian Sanitz : Hibernate Persistenz in Java- Systemen mit Hibernate 3, dpunkt Verlag, 2006. 3. Quellcode zu den Beispielen aus [2]: http://hibernatesample.sourceforge.net 4. XDoclet-Generierung der Hibernate-Mappingdateien im Detail: http://hibernatesample.sourceforge.net 5. Spring-Framework: http://www.springframework.org 6. JDO (Java Data Objects): http://java.sun.com/products/jdo 7. Entity-Beans sind Bestandteil von EJB 2.1: http://java.sun.com/products/ejb/docs.html Anhang: Beispielquellcode Hibernate Code-Beispiel 1: Persistentes Geschäftsobjekt public class Termin { private long _id; private String _titel; private String _beschreibung; private String _ort; private Date _datum; private Set<Benutzer> _teilnehmer; public String gettitel () { return _titel; private void settitel (String titel) { _titel = titel; Code-Beispiel 2: Mapping-Datei <?xml version="1.0" encoding="iso-8859-1"?>
<hibernate-mapping package="ab.de"> <class name="termin" table="termin"> <id name="id"> <generator class="hilo"/> </id> <property name="titel"/> <property name="beschreibung"/> <property name="datum" type="timestamp"/> <property name="ort" column="wo"/> <set name="teilnehmer" /> </class> </hibernate-mapping> Code-Beispiel 3: Session als zentrale Hibernate-Klasse Termin termin = new Termin(); try { Session session = _sessionfactory.opensession(); Transaction transaction = session.begintransaction(); session.save(termin); transaction.commit(); catch (HibernateException e) { Code-Beispiel 4: HQL Hibernate Query Language Session session = _sessionfactory.opensession(); Query query = session.createquery( from Termin t where t.ort = Berlin ); List<Termin> termine = query.list(); session.close();
Unsere Schulungen akquinet auf einen Blick Wir bieten Beratung und Schulungen zu Eclipse RCP, Groovy/Grails sowie zu agilen Themen wie Scrum oder extreme Programming an. Weitere Infos finden Sie unter http://www.akquinet.de/schulungen Individualentwicklung Standardlösungen Outsourcing agiles Vorgehen Beratung und Betrieb von SAP- und Navison- Systemen Open-Source-basierte Systeme Weitere Informationen erhalten Sie gerne unter info@akquinet.de Kontakt: akquinet AG Paul-Stritter-Weg 5 22297 Hamburg Fon +49 (0)40 881 73 0 info@akquinet.de www.akquinet.de