Vergleichstest: Objekt-Relational Mapping mit JDO, Teil 2

JDO praktisch

Thomas Pöschmann

Nachdem im letzten Java Magazin viel Theorie über das OR-Mapping getrieben wurde, folgt nun die Praxis. Sehr interessant sind die Spezialisierungen der einzelnen Produkte, denn es sind durchaus gewisse Polarisierungen im Kreise der Wettbewerber erkennbar. Ein Streifzug über den JDO-Marktplatz unter den Blickwinkeln JDO-Support, Flexibilität, Mapping, Abfragen, Performance und Integration soll helfen, den nötigen Durchblick zu erhalten.

Innerhalb dieses Artikels werden die folgenden OR-Mapper betrachtet (zu erwähnen ist dabei, dass die Aussagen zu OJB sowie JRelay nicht auf den Tests des Autors, sondern auf den Aussagen des Herstellers beruhen):

  • LIBeLIS LiDO 1.2
  • OJB 0.8
  • ObjectIndustries JRelay 2.0
  • PrismTech OpenFusion 1.1
  • Signsoft intelliBO 2.7
  • SolarMetric Kodo 2.2
  • TradeCity RexIP JDO
  • WebGain TOPLink 4.0

Zunächst einmal zeichnet sich eine breite Unterstützung für den neuen Standard ab. Bis auf TOPLink und OJB unterstützen alle Hersteller die entsprechenden Schnittstellen sowie das Konzept des „Enhancer“. Dabei setzt wiederum JRelay alleinig auf einen Sourcecode-Enhancer, während alle anderen Tools den Bytecode verändern.

TOPLink setzt zwar auf JDO als Markenzeichen, hat aber keine nach javax.jdo kompatiblen Schnittstellen im Programm. Außerdem wird hier Reflection verwendet, um den Zustand eines Objekts zu füllen oder abzufragen. Um trotzdem das partielle Laden von Objekten zu ermöglichen, werden JDK 1.3 Proxy-Objekte oder spezielle TOPLink-Klassen angeboten. Dabei sind die Proxies von der Verwendung von Schnittstellen abhängig, während die TOPLink-Klassen natürlich an den entsprechenden Stellen anstatt der Original-Objekte etwa für Referenzen verwendet werden müssen.

OJB implementiert ursprünglich die Schnittstellen der Object Database Management Group (ODMG), von daher wird auch hier nicht das Konzept des Enhancer unterstützt. Die aktuellen Aussagen des Projekts bewegen sich aber klar in Richtung JDO, wobei eine komplette Implementierung angestrebt wird. Eine nach JDO anhand des TCK (Technology Compatibility Kit) zertifizierte Version konnte bei Redaktionsschluss dieses Artikels noch kein Hersteller vorweisen.

Flexibilität und Nutzbarkeit

Um die beiden Welten „Objekt“ und „Entität“ ein wenig näher zusammen zu bringen, unterstützen viele Hersteller den Kunden mit einer eigenen Entwicklungsumgebung. LiDO (Abb. 1) bringt etwa eine solche mit, in welcher existierende Klassen zu existierenden Tabellen gemappt werden können. Die Ausgabe dieses Tools sind die Mapping-Deskriptoren, auf deren Grundlage auch ein entsprechendes Datenbank-Schema erstellt werden kann.

Abb. 3: Signsoft intelliBO for Together

Ähnliches kann auch mit dem JRelay-Tool (Abb. 2) erledigt werden, wobei hier auch Klassen aus existierenden Datenbank-Strukturen erstellt werden können. Dies ist eine erste Hilfe bei größeren, vorhandenen Strukturen.

Auch intelliBO kommt mit einer eigenen Entwicklungsumgebung (kann in JBuilder integriert werden) daher und kann Klassen aus existierenden Strukturen erstellen. Eine Schemagenerierung ist nicht vorgesehen. Zusätzlich wird ein Plug-In für Together (Abb. 3) bereitgestellt, welches das Erstellen der Mapping-Deskriptoren anhand eines eigenen Diagrammtypen erlaubt. Durch diese Integration wird dann auch die Schemagenerierung möglich, da dies ja bereits in Together „eingebaut“ ist.

Kodo ermöglicht mit der JBuilder-Integration (Abb. 4) die Konfiguration der .JDO-Dateien über eigenen Dialog. Der Enhancer sowie die Schemagenerierung können so aus der Oberfläche heraus gestartet werden.

Abb. 5: Die TOPLink Workbench

Tools zum Erstellen der Deskriptoren werden auch von OJB und TOPLink bereitgestellt. TOPLink kann dabei sowohl die Klassen als auch die Datenbank erstellen.

OpenFusion hat keine graphische Oberfläche, dafür kann das Schema mit Hilfe eines Kommandozeilentools erstellt werden. RexIP bietet ebenfalls keine UI, dafür aber einen Schemagenerator und zusätzlich noch einen Klassengenerator auf Kommandozeile an.

Eine Ant-Integration steht sowohl von LiDO, OpenFusion, intelliBO, Kodo als auch RexIP bereit. Bezüglich der Konnektivität unterstützen alle Hersteller JDBC sowie DataSources und JCA Connectoren über JNDI. Zusätzlich erlaubt LiDO den Zugriff auf das OODBMS Versant sowie den Zugang zu Dateien. Eine Ausnahme pictureet TOPLink; hier werden die JCA-Schnittstellen nicht zum Anfordern von Datenbankverbindungen unterstützt.

Nur bei OJB, intelliBO, Kodo und TOPLink ist es möglich, bei Bedarf auf den internen Ressourcen-Manager zuzugreifen. OJB, intelliBO und TOPLink können jedoch Klassen einer Client-Schnittstelle (sprich: PersistenceManager) auf unterschiedliche Datenbanken abpictureen. Um das two-phase commit-Protokoll wird derzeitig von OJB noch nicht unterstützt, hier ist die Verwendung von XA-fähigen Datenbanktreibern aber geplant.
Alle Tools bieten die Möglichkeit, Log-Ausgaben zu erzeugen. TOPLink und LiDO gehen hier am weitesten, wobei TOPLink sogar ein Profiling anbietet. OJB und JRelay nutzen dabei Log4J als Quasi-Standard zur Generierung von Debug-Ausgaben.

Transient transaktionale Attribute können derzeitig nicht in intelliBO, TOPLink und OpenFusion verwendet werden. Außerdem wiederspricht dieses Konzept der ODMG-Spezifikation, sodass OJB damit auch noch nicht umgehen kann.

Mapping

Im Bereich des Mappings trennen sich die Wege der Hersteller weiter. Während einige Tools versuchen, möglichst eng im Rahmen der Normalisierung zu arbeiten und sogar Zugriff auf den Statementgenerierungsprozess geben, kommen andere Tools nur mit eigenen Strukturen klar.

LiDO ordnet zunächst jeder Klasse eine Tabelle zu. Dabei wird die Speicherung der JDO-Datentypen unterstützt, der jeweilige Zieltyp (JDBC SQL type) kann angegeben werden, um einfache Konvertierungen auf der Ebene des JDBC-Treibers zu unterstützen. Darüber hinaus kann java.util.Date auch in einen String konvertiert werden. Der Primärschlüssel wird bei Bedarf anhand einer Sequenztable vom Framework gepictureet. Beziehungen (1:N, N:M) wurden beim Test nicht nach den Regeln der Normalisierung aufgelöst – es werden jeweils eine (1:N) oder zwei (N:M) Zwischentablen vom Framework benötigt. Laut Hersteller soll aber das Problem mit der 1:N-Beziehung bereits behoben worden sein, indem die Nutzung von Fremdschlüsseln angeboten wird. Bezüglich der Vererbung wird der thin table-Ansatz unterstützt; dabei wird pro konkreter Subklasse eine Tabelle mit allen Attributen angelegt. Es kann also sein, dass Attribute, welche durch eine abstrakte Klasse definiert werden, mehrfach gespeichert und gewartet werden müssen [1].

Auch OJB speichert zunächst einmal alle Objekte einer Klasse in nur einer Tabelle. Der Primärschlüssel kann dabei von einer Klasse des Nutzers gepictureet werden. Abpictureungen für Attribute werden anhand von so genannten Conversion Strategies definiert. Damit sind dann etwa auch Abpictureungen von „String“ nach „Integer“ möglich. Bei Beziehungen wird entsprechend der Ansatz über Fremdschlüssel (1:N) oder eine Zwischentable (N:M) gewählt. Hinsichtlich der Vererbung wird auch der von LiDO gewählte Ansatz „Konkrete Klasse – Tabelle“ sowie „flat table“ angeboten. OJB ist eines der wenigen Produkte, welche eine Schnittstelle anbieten, um datenbankspezifisches SQL zu nutzen. In der Regel beschränken andere Produkte hier die Unterstützung der Datenbank-Dialekte auf die unterstützten Datenbanken. Auch referentielle Integrität wird unterstützt, dabei erkennt OJB anhand der Beziehungen zwischen Klassen, in welcher Reihenfolge die Statements abgesetzt werden müssen.

JRelay speichert ebenfalls alle Objekte einer Klasse in einer Tabelle ab. Für die Abpictureung von Beziehungen werden die entsprechenden, der Normalform angepassten, Fremdschlüssel und Zwischentablen verwendet. Bei Vererbung kann sowohl „flat table“ als auch „thin table“ (abstrakter und konkreter Klasse wird jeweils eine Tabelle zugeordnet) angeboten. Außerdem soll JRelay mit referentieller Integrität umgehen können.
OpenFusion geht beim Mapping eigene Wege. Zwar kann der SQL-Type eines Datentyps in der Datenbank angegeben werden, doch sowohl Beziehungen als auch Vererbung werden nicht auf einen Algorithmus abgepictureet, welcher der Normalform ähnelt. Die Generierung von Primärschlüsseln erfolgt mit Hilfe einer Sequenztable.

Anders dagegen intelliBO: Hier wird zwar auch jeder Klasse eine Tabelle zugeordnet, doch jedes Attribut (außer Primärschlüssel) kann wieder in eine separate Tabelle gespeichert werden. Die Beziehung wird dann über den Primärschlüssel hergestellt. Der Primärschlüssel kann mit Hilfe von Sequenztablen, Oracle-Sequenzen, Interbase-Generatoren oder über eine Klasse des Nutzers generiert werden. Daneben existieren weitere Mappings: statische Wertzuordnungen in CodeMappings (M-male, F-female) sowie ExchangeOperators, welche auf einer Feldbasis die Veränderung des Wertes nach dem Laden und vor dem Speichern erlauben. Relationen werden auf eine Art und Weise abgepictureet, welche der Normalisierung gleichkommt (Fremdschlüssel für 1:N, Zwischentable für N:M). Vererbung wird über „flat table“ und „thin table“ (abstrakte und konkrete Klassen auf die jeweiligen Tabellen) gelöst. Signsoft ist einer der wenigen Hersteller, welcher eine explizite Unterstützung für Oracle BLOB/CLOB anbieten. Außerdem kann das Produkt mit Regeln der referentiellen Integrität umgehen: anhand eines Tools werden die Abhängigkeiten zwischen Tabellen erkannt und eine XML-Datei mit der Reihenfolge der UPDATE/INSERT/DELETE-Befehle erstellt.

Kodo ordnet zunächst ebenfalls jeder Klasse eine Tabelle zu. Bestimmte Datentypen (BLOB/CLOB) werden in separaten Tabellen gespeichert. Dabei soll laut SolarMetric auch eine Spezialbehandlung für Oracle integriert sein. Primärschlüssel werden über Sequenztablen oder Klassen des Nutzer gepictureet, für Relationen steht der Fremdschlüssel bzw. Zwischentablen-Ansatz zur Verfügung. Vererbung wird über den „flat table“-Ansatz realisiert. Referentielle Integrität wird nicht automatisch unterstützt, doch SolarMetric betont, dass die Statements gegenüber der Datenbank in der Reihenfolge abgesetzt werden, in welcher die Befehle am PersistenceManager eintreffen.

Auch RexIP ordnet zunächst jeder Klasse eine Tabelle zu, kann aber Attribute auf Wunsch auch in anderen Tabellen ablegen. Primärschlüssel werden über Sequenztablen oder Oracle-Sequences gepictureet. Fremdschlüssel sowie der Zwischentablen-Ansatz werden unterstützt. Bei der Vererbung wird „thin table“ angeboten, dabei kann eine konkrete oder abstrakte Klasse auf eine Tabelle zugeordnet werden – quasi eine Mischung aus beiden „thin table“-Ansätzen. Neben diesen Mapping-Formen kann eine Collection auf eine Anzahl von Spalten abgepictureet werden. Dies ist sicherlich nur sinnvoll, wenn die Anzahl der Elemente in der Collection bekannt ist. Gleiches ist mit Maps durchführbar, wobei hier die Map auf eine Matrix von Spalten und Zeilen abgepictureet wird.

TOPLink pictureet ebenfalls eine Klasse auf eine Tabelle ab, kann dann aber wieder die einzelnen Attribute auf andere Tabellen verteilen. Der Primärschlüssel wird auf Wunsch des Nutzers mit Hilfe von Sequenztablen, nutzerdefinierten Klassen oder nativen Methoden für Oracle, Sybase und Informix automatisch gewartet. Bezüglich des Mappings werden natürlich die Fremdschlüssel sowie Zwischentablen unterstützt, außerdem nutzerdefinierte Mappings (Implementierung eines Interfaces, Callback nach dem Laden und vor dem Speichern eines Objekts) sowie Code-Tabellen (M-male, F-female). Die so genannten compound mappings sind beide implementiert. Bezüglich der Vererbung werden alle drei Optionen (die zwei „thin tables“ sowie „flat table“) unterstützt. Referentielle Integrität wird auf Objektebene aufgelöst. Sehr interessant ist die Option von TOPLink: Zugriff auf den Statement-Generierungsprozess sowohl zur Erstellungszeit (durch Angabe von eigenen SQL-Statements für UPDATE/INSERT/DELETE) als auch zur Laufzeit zu erhalten.

Abschließend erlauben die Produkte OJB, intelliBO und TOPLink die Nutzung von JDK-Listen und Maps bzw. eigenen Listen/Maps. Alle anderen Hersteller ersetzten Listen bzw. Maps auf persistente Objekte durch ihre eigene Implementierung.

Abfragen

Zunächst unterstützen alle Produkte JDOQL. Die beiden „nicht-JDO“-Tools OBJ und TOPLink sind hiervon natürlich ausgenommen. RexIP und intelliBO bieten dabei die Nutzung der vereinfachten Notation für 1:N bzw. N:M-Beziehungen an, damit muss nicht die umständliche „contains“-Notation genutzt werden.
Die Nutzung von reinem SQL als Abfragesprache ist bei OJB, LiDO, intelliBO und TOPLink erlaubt. LiDO unterscheidet, ob nur die WHERE-Klausel oder das ganze SQL-Statement angegeben werden. Signsoft intelliBO dagegen unterstützt die Nutzung von Datenbank-Feldnamen, in JDOQL eingebettetes SQL, die Nutzung kompletter SELECT-Klauseln sowie nutzerdefinierte Funktionen und Operatoren. Daneben können die SQL tuning hints für prinzipiell alle Datenbanken mitgegeben werden, ohne auf JDOQL zu verzichten. TOPLink erlaubt ebenfalls die Nutzung von SQL als Abfragesprache, außerdem können Datenbank-Feldnamen in Abfragen eingebaut werden, ohne dass diese gemappt sein müssen.

Die Rückgabe von reinen „result sets“ (etwa für Reports) als Query-Ergebnisse ist nur bei intelliBO und TOPLink vorgesehen. Bezüglich des Cache bieten nur die Produkte Kodo, OJB und TOPLink einen „intra-PM“-Cache und ermöglichen damit, Ergebnisse zwischen PersistenceManager-Instanzen (bzw. deren Entsprechung bei TOPLink) zu teilen. TOPLink erlaubt dabei auch das „object pinning“, also das permanente Halten von Objekten im Cache. OpenFusion ignoriert interessanterweise die Cache-Kontrolloptionen (ignoreCache true/false), nutzt aber den internen Cache.

Performance

Das verzögerte Laden von Ergebnismengen einer Query wird von allen besprochenen Produkten außer Kodo unterstützt. Dabei sind LiDO und OpenFusion darauf angewiesen, zunächst eine Liste mit Primärschlüsseln zu laden. Die Objekte selber werden mit einem zweiten Statement dann aber verzögert geladen.

Die Ergebnisse der Query werden von LiDO, OJB, JRelay, RexIP, OpenFusion und TOPLink auf Wunsch mit schwachen Referenzen belegt. Außer OpenFusion sind alle Produkte in der Lage, Objekte bei Bedarf unter Nutzung von JDBC 2-Funktionalität nachzuladen, wenn Sie vom garbage collector entfernt wurden.

Das Konzept der default fetch group unterstützen alle Hersteller. Dabei kann bei intelliBO und TOPLink diese Gruppe von Attributen zur Laufzeit „überschrieben“ werden, also für eine bestimmte Query gewisse Attribute zu dieser Gruppe hinzugefügt werden. Kodo und RexIP definieren die default fetch group für Ihre „primäre Tabelle“. Alle Attribute, welche auf diese Tabelle gemappt wurden, werden also immer in einem Zug geladen. OpenFusion ordnet die ID generell nicht der Gruppe hinzu, damit werden die Primärschlüssel mit einem SELECT geladen, dann die default fetch group-Felder in einem zweiten Schritt.

Optimistisches Sperren wird in der Regel in den Varianten Zeitstempel (intelliBO, Kodo, TOPLink, OJB), Versionsfeld (JRelay, intelliBO, TOPLink, OJB) oder durch die Nutzung des alten Zustands in der WHERE-Klausel (RexIP, TOPLink) realisiert. Bei TOPLink kann zusätzlich unterschieden werden, ob der komplette alte Zustand durch die WHERE-Klausel repräsentiert wird oder ob das nur für die geänderten Felder gilt.
Eine Optimierung von Statements (zweimaliges UPDATE wird zu einem UPDATE am Ende der Transaktion u.ä.) unterstützen LiDO, JRelay, intelliBO, Kodo und TOPLink. Prepared Statements werden derzeit nicht von OJB und Kodo zum Rückschreiben genutzt, eine entsprechende Nachbesserung wurde angekündigt.

Integration

Alle Tools können eine externe Konfigurationsdatei nutzen. Damit ist die Basis für eine Integration in Web- und Applikationsserver gelegt. Bis auf JRelay sind auch alle Tools in der Lage, die jeweiligen Datenbankverbindungen über JNDI anzufordern.

Die Integration in die jeweiligen Transaktionsmanager der Applikationsserver wird bei LiDO, OpenFusion, Kodo und RexIP über die J2EE Connector Architecture realisiert. Damit können diese Tools in JCA-kompatiblen Applikationsservern eingesetzt werden. TOPLink geht hier eigene Wege und bringt eine Integration für den Transaktionsmanager für die unterstützten Applikationsserver mit. Signsoft intelliBO dagegen kann mit jedem beliebigen JTA- oder CosTransaction-kompatiblen Server umgehen und verfügt über Default-Implementierungen für BEA WebLogic, jBoss, und Borland Enterprise Server. OJB kann sich nur in den Transaktionsmanager von jBoss einklinken, bei anderen Servern muss selbst Hand angelegt werden.

Eine Unterstützung für Container Managed Persistence (CMP) bringt nur TOPLink auf den unterstützten Plattformen mit.

Um verteilte Anwendungen mit JDO zu realisieren, muss es möglich sein, Objekte von einem PersistenceManager zu einem anderem Persistencemanager in einer anderen VM zu übergeben. Nach JDO ist so etwas eigentlich nicht definiert, denn die Factory für persistente Objekte ist immer der PersistenceManager und nicht die Objektserialisierung von Java. Daher tun sich die Tools recht schwer, serialisierte Objekte wieder unter die Kontrolle des Systems zu bringen. Einzige Ausnahme ist intelliBO; hier können Objekte zum update registriert werden. Ansonsten haben OJB und TOPLink hier noch entsprechende Vorteile, wobei diese Lücke sicher bald geschlossen wird.

Fazit

Das Fazit eines Produktvergleichs gehört wohl mit zu den schwierigsten Dingen überhaupt. Es ist zu sehen, dass die Produkte, welche im Vergleich zu TOPLink recht jung erscheinen mögen, durchaus mit dem „Urgestein“ des O/R-Mapping mithalten können. Zwar fehlen einige Features im Bereich EJB und Web, doch die Innovationsfreudigkeit der Hersteller wird diese Lücke sicherlich schnell schließen. Während einige Hersteller dabei versuchen, sich an existierende Datenstrukturen so gut wie möglich anzupassen, setzen andere Tools komplett auf ihr eigenes Schema.

TOPLink setzte über viele Jahre die Standards beim O/R-Mapping und um so erstaunlicher ist sein gegenwärtiges Schicksal. Das Unternehmen WebGain, so heißt es zur Zeit, wo ich diesen Artikel schreibe, befinde sich in Auflösung, TOPLink werde samt Entwicklungsmannschaft von Oracle übernommen. Trifft dies zu, wäre dies eine gute Sache für den Markt der O/R-Mapper, weil durch Oracle gewissermaßen der offizielle Segen für die JDO-Technologie verliehen wird.

Die Firmen hinter den Produkten

LIBeLIS, der Hersteller von LiDO, ist eine französische Firma mit Sitz in Paris. Neben dem JDO-Produkt steht mit NAViLIS eine Bibliothek zur Darstellung von Geschäftsobjekten in Oberflächen bereit. Darüber hinaus wird Orcas angeboten, ein freier J2EE-Server, basierend auf Jonas.

ObjectIndustries ist eine deutsche Firma mit Sitz in München und Hersteller/Anbieter der JDO-Implementierung „JRelay“.

OBJ als Open Source-Implementierung ist bei „SourceForge“ zu Hause und wird demnächst Apache Jakarta Subprojekt. Das Projekt wird von Thomas Mahler geleitet. Das Produkt implementierte ursprünglich die ODMG-APIs und wird gerade nach JDO portiert.

PrismTech ist eine US-amerikanische Firma, die neben Ihrer JDO-Implementierung einen Schwerpunkt auf CORBA-Implementierungen (ORB, CORBA Services, J2EE Integration) legt.

Signsoft ist ebenfalls eine deutsche Firma mit Sitz in Dresden, welche neben intelliBO Java Schulungen und Consultings anbietet.

SolarMetric als Hersteller der JDO-Implementierung Kodo hat seinen Sitz in Washington, D.C. Die Firma ist außerdem in Europa (Paris) präsent.

TradeCity ist ebenfalls eine US-amerikanische Firma, die außerdem noch in Hong Kong tätig ist. Sie bietet als zweites Produkt einen Applikationsserver an und ist im Consulting-Bereich tätig.

WebGain als US-amerikanische Firma ist im Tool-Bereich tätig, unter anderem mit den Entwicklungsumgebungen „WebGain Studio“ und „Visual Café“. WebGain befand sich unbestätigten Gerüchten zufolge bei Redaktionsschluss in Auflösung, das Produkt TOPLink werde von Oracle übernommen.

Geschrieben von
Thomas Pöschmann
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.