Objektpersistenz mit Java Data Objects

Als die Sprache Java spezifiziert wurde, wurde auch an die Persistenz von Objekten gedacht - leider aber nur in Form des reservierten Schlüsselworts "transient". Die Ergänzung Java Data Objects soll die Lücke zwischen Vision und Realität schließen.

Java Data Objects oder JDO, wie man die Spezifikation mit einem der beliebten Three-Letter-Akronyme auch nennt, wird gegenwärtig in einem Java Community Process gemeinsam von Experten entwickelt, die bei verschiedenen Firmen beschäftigt sind (siehe[1]). Inzwischen steht die Spezifikation kurz vor der 1.0-Release, sollte also im Wesentlichen bereits stabil sein.

Bei JDO geht es darum, den Anwendungsentwicklern ein Implementations- unabhängiges Framework für die persistente Speicherung von Objekten an die Hand zu geben. Vorhandene Lösungen wie das im Linux-Magazin 7/01 vorgestellte Goods[2] oder die Speicherung mittels JDBC[3] sind zwar recht einfach, werden aber mit der Abhängigkeit von spezifischen Datenbankprodukten oder zumindest von speziellen Datenbankstrukturen erkauft.

Weil JDO ein Java-Standard ist, müssen sich die Hersteller von Datenbanken eine Schnittstelle gemäß der Spezifikation einfallen lassen, so dass es den Entwicklern ermöglicht wird, ohne Kenntnis der Datenbank ihre Objekte persistent zu machen.

Die JDO-Spezifikation ist insbesondere für Hersteller von Middleware interessant. Ein einheitliches Framework würde es einem Anwender erlauben, mit geringem Aufwand etwa einen EJB-Server für eine Datenbank zu konfigurieren. Der Vergleich von relationalen und objektorientierten Datenbanken kann in diesem Zusammenhang zu bemerkenswerten Ergebnissen führen, denn meist sind EJB-Server nur auf relationale Datenbankmanagement-Systeme ausgerichtet.

Der Manager im Zentrum

Dreh- und Angelpunkt der JDO-Architektur ist der »javax.jdo.PersistenceManager«. Das ist, wie bei den meisten Java-Paketen, ein Interface, das von einem Provider implementiert werden muss. Ein Datenbankhersteller, der sein Produkt für JDO verfügbar machen will, muss eine Datenbankklasse (für die Konfiguration der Datenquelle) sowie eine Implementation des Interfaces »javax.jdo.PersistenceManagerFactory« zur Verfügung stellen. Die Datenbankklasse könnte dieses Interface auch selbst implementieren.

Ist erst mal ein Persistence Manager erzeugt, wird nur über dessen Methoden auf die Datenbank zugegriffen. Die genaue Implementation - ob relational, objekt-relational oder objektorientiert - spielt keine Rolle mehr. In Listing 1, das weiter unten erläutert wird, ist ein kleines Beispiel zu sehen, wie damit Objekte gespeichert werden können.

Eintrittskarte zur Ewigkeit

Nicht jedes Objekt einer Anwendung soll gespeichert werden. Die Eintrittskarte zur Unvergänglichkeit ist die Implementation des zweiten wichtigen Interfaces der JDO-Spezifikation: »javax .jdo.PersistenceCapable«. So genannte JDO-Instanzen implementieren dieses Interface und repräsentieren Daten in einem Datenspeicher. Zudem implementieren sie natürlich auch die applikationsspezifische Logik. Ein sauberes Design wird hier aber versuchen, durch Vererbung oder Aggregation die Datenschicht zu kapseln.

Da das Persistence-Capable-Interface recht komplex ist, gibt es Enhancer, das sind Programme von JDO-Providern, die normale Anwendungsklassen so umwandeln, dass daraus Persistence-Capable-Klassen werden. Die Spezifikation sieht dabei vor, dass die erzeugten Klassen unabhängig vom JDO-Provider sind, also kompatibel zum JDO-Standard.

Der Weg zu einer persistenten Klasse ist also ein zweistufiger Prozess. Im ersten Schritt wird ganz normal eine Klasse implementiert, im zweiten Schritt wird diese umgewandelt. Diesen Ansatz verwendet auch das erwähnte Goods.

Da die Standardklassen von Java das Persistence-Capable-Interface nicht implementieren, sind diese auch nicht persistent. Benutzerdefinierte Klassen können es aber sein, wobei jedoch nur Felder gespeichert werden, die entweder selbst wieder das PC-Interface implementieren, primitive Typen sind oder Immutable Object Classes. Das sind Objekte, die sich nicht mehr verändern lassen, wenn sie einmal erzeugt sind. Von den wichtigen Klassen sind dies etwa String, Integer oder Float.

Zusätzlich zu diesen Klassen müssen auch Date und Hashset unterstützt werden. Optional sind die Klassen Arraylist, Hashmap, Hashtable, Linkedlist, Treemap, Treeset und Vector. Die Liste ist lang genug, um auch komplizierte Datenstrukturen abzubilden. Eine Konsequenz ist aber, dass Persistenz keine vererbare Eigenschaft ist. Subklassen von nicht-persistenten Klassen können also auch persistent sein, wenn deren Basisklassen es nicht sind, und umgekehrt.

Abbildung 1: Java-Entwickler können auf der Sun-Website ihre JDO-Kenntnisse in einem Quiz unter Beweis stellen.