Kolumne

Enterprise Tales: NoSQL in Jakarta EE – Ein Aufbruch in die Zukunft?

Arne Limburg
Funktionale Programmierung

© S&S_Media

Es gibt Neues aus der Jakarta-EE-Welt. Nachdem nun langsam alle Spezifikationen und der gesamte Code zur Eclipse Foundation umgezogen sind, gibt es gerüchteweise einen ersten Ausblick auf die Zukunft von Jakarta EE. Und diese Zukunft beinhaltet NoSQL.

Glaubt man dem Google-Trend, begann das Interesse an NoSQL bereits 2009. So richtig startete der Hype 2010 und hält bis heute an. Dennoch existiert bis heute keine Möglichkeit, im Java-EE-Standard auf eine NoSQL-Datenbank zuzugreifen. Wer in seinem Projekt eine NoSQL-Datenbank als sinnvoll erachtet oder gar für notwendig ansieht, muss auf die jeweilige Java-Bibliothek des Anbieters zurückgreifen. Alternativ hat man die Möglichkeit, Third-Party-Bibliotheken wie Spring-Data zu verwenden.

Aber warum hat der Enterprise-Java-Standard das Thema NoSQL bisher ignoriert? Liegt es wirklich daran, dass Java EE rückwärtsgewandt ist und es neue Themen generell nicht leicht haben, im Standard zu landen?

Das, was dem Enterprise-Java-Standard als Rückwärtsgewandheit ausgelegt wird, ist tatsächlich ein durchaus sinnvoller Grundsatz: Es werden nur communityerprobte Themen in den Standard aufgenommen. Die ersten Standards, die auf Basis dieses Grundsatzes spezifiziert wurden, waren JPA in Java EE 5 und CDI in Java EE 6. Warum gibt es also bisher kein NoSQL im Standard?

Wie wir am Google-Trend erkennen können, wäre Java EE 7 die erste Enterprise-Java-Version gewesen, in die ein NoSQL-Standard hätte einfließen können. Zum Zeitpunkt von Java EE 5 (2006) und Java EE 6 (2009) stand NoSQL sicherlich noch nicht auf der Agenda. Zu Zeiten von Java EE 7 wurde das Thema NoSQL in der Community auch tatsächlich diskutiert. Man war sich aber nicht einig, in welcher Form NoSQL den Weg in den Standard finden sollte. Ein Artikel aus dem Jahr 2012 von Markus Eisele veranschaulicht und kommentiert die Möglichkeiten recht ausführlich.<

NoSQL-Ansätze unterscheiden sich

Auch die Herausforderungen eines NoSQL-Standards werden dort aufgeführt: NoSQL ist nicht gleich NoSQL. Vielmehr handelt es sich dabei um einen Oberbegriff für einen ganzen Blumenstrauß von Persistenztechnologien mit ganz unterschiedlichen Konzepten. Dazu gehören Column-basiert, Document-basiert, Key-Value-basiert und Graphen-basiert. Zunächst war also die Frage zu klären, ob eine gemeinsame Abstraktion dieser Konzepte, wie Spring sie mit Spring Data fährt, überhaupt sinnvoll ist; oder ob es nicht besser sein könnte, für jede der Technologien eine separate Spezifikation aufzusetzen.

Auch in Spring Data wird das Dilemma recht deutlich. Hier gibt es zwar eine Abstraktion für den Datenzugriff, aber keine Abstraktion für das Objekt-Mapping. Diese Diskussion wurde bisher nicht zu Ende geführt, sodass das Thema NoSQL im Enterprise-Java-Standard bis heute auf Eis gelegt wurde.

JNoSQL als Abstraktion

Mit der Übergabe von Java EE an die Eclipse Foundation und der damit verbundenen Umbenennung zu Jakarta EE kommt jetzt wieder Bewegung in das Thema. Angetrieben wird es von einem Open-Source-Framework, das 2016 ins Leben gerufen wurde und auch unter dem Dach der Eclipse Foundation läuft: JNoSQL. JNoSQL verspricht eine Lösung genau für das beschriebene Dilemma. Einerseits bietet es eine Abstraktion für die vier Typen von NoSQL-Datenbanken, andererseits stellt es ein gemeinsames Objekt-Mapping zur Verfügung, sofern die einzelnen NoSQL-Konzepte Gemeinsamkeiten haben.

JNoSQL unterstützt bereits jetzt fast dreißig NoSQL-Datenbanken. Möglich wird das durch eine geschickte Architektur, die das Objekt-Mapping vom eigentlich Datenzugriff trennt (Abb. 1). Man hat für jede der NoSQL-Technologien ein eigenes (Low-Level) API geschaffen, das implementiert werden muss, um einen Anbieter zu unterstützen. Hierbei handelt es sich gewissermaßen um das Pendant zum JDBC-Driver. Falls eine NoSQL-Datenbank mehrere Konzepte unterstützt, kann natürlich auch mehr als eins der APIs implementiert werden.

Abb. 1: Die Architektur von JNoSQL

Abb. 1: Die Architektur von JNoSQL

Der größte Unterschied zu JDBC ist, dass die Implementierung des JDBC-Drivers in der Regel vom Anbieter zur Verfügung gestellt wird. Die NoSQL-Anbindungen werden (momentan noch) vom JNoSQL-Projekt selbst gepflegt.

Dennoch hat es das Projekt durch diese Abstraktion geschafft, in kurzer Zeit viele NoSQL-Datenbanken anzubinden. Eben auch dadurch, dass das vom Datenzugriff getrennte Mapping zu den Java-Objekten nicht für jeden Anbieter neu geschrieben werden muss.

NoSQL und JPA

Bevor ein komplett neuer Standard ins Leben gerufen werden soll, kann es sich durchaus lohnen, einen Blick in die bestehenden Standards und die jeweiligen Implementierungen zu werfen. Tatsächlich wird man bei JPA und den beiden Implementierungen Hibernate und EclipseLink recht schnell fündig. Beide bieten mittlerweile mit Hibernate OGM und EclipseLink NoSQL Lösungen für NoSQL-Datenbanken an. Im Gegensatz zu JNoSQL, dessen API zwar an JPA angelehnt ist, aber eigene Packagenamen für Annotations und auch eine eigene Queryabstraktion bietet, ist es mit Hibernate OGM und EclipseLink NoSQL möglich, mit dem von JPA bekannten API auf NoSQL-Datenbanken zuzugreifen. Die Menge der unterstützten Datenbanken ist allerdings bei Weitem nicht so groß wie bei JNoSQL.

Macht es also Sinn, keinen neuen Standard für NoSQL in Enterprise Java zu entwerfen, sondern das Ganze in einen bestehenden Standard wie JPA aufzunehmen? Oben haben wir diskutiert, ob es einen gemeinsamen Standard für die unterschiedlichen NoSQL-Konzepte geben soll, oder ob es nicht sinnvoller ist, für jeden der NoSQL-Typen (Column, Document, Key Value, Graph) einen eigenen Java-Standard zu spezifizieren. Der Ansatz von JNoSQL, nämlich alles mit einer gemeinsamen Abstraktion zu versehen, scheint sinnvoll und ist daher ein starkes Argument für einen gemeinsamen Standard. Setzt man diesen Gedanken fort, folgt unmittelbar der nächste: Wenn ich für alle NoSQL-Typen einen gemeinsamen Standard habe, warum gibt es dann für SQL einen separaten? Oder anders gefragt: Ist RDBMS nicht nur eine weitere Persistenztechnologie, die von einem Persistenzstandard behandelt werden könnte?

Wäre es dann nicht die logische Konsequenz, dass der JPA-Standard dahingehend weiterentwickelt würde, dass er nicht nur relationale Datenbanken abbildet, sondern auch NoSQL-Datenbanken? Natürlich würde das in einem Major Release passieren. Das nächste anstehende Major Release von JPA wäre 3.0.

JPA anpassen

Natürlich müsste es dazu einige Anpassungen an JPA geben. Bisher ist JPA nicht darauf ausgelegt, mit etwas anderem als relationalen Datenbanken zu arbeiten. Der Standard müsste also aufgeteilt werden und zwar so ähnlich, wie es in JNoSQL bereits geschehen ist: in einen Teil, der den Datenzugriff kapselt, und einen Teil, der das Objekt-Mapping realisiert. Aber haben JPA und JNoSQL überhaupt genug Gemeinsamkeiten, um einen gemeinsamen Standard zu rechtfertigen?

Um das festzustellen, betrachten wir die einzelnen Teile. Da die Schnittstelle des Datenzugriffs mit JDBC klar spezifiziert ist, sind vor allem die Komponenten des Objekt-Mappings spannend. Grundsätzlich orientiert sich JNoSQL dabei an den JPA Annotations. So muss auch in JNoSQL jede Entität mit der Annotation @Entity versehen werden und jede dieser Entities muss auch ein Attribut haben, das die ID repräsentiert und mit @Id annotiert werden muss. Wie bereist geschrieben, werden momentan allerdings nicht die JPA Annotations verwendet. Stattdessen gibt es eigene Annotations, die jedoch dieselben Namen tragen wie die jeweiligen JPA-Pendants. Nun sind natürlich nicht alle JPA-Annotations im NoSQL-Kontext sinnvoll. Die in JPA möglichen ID-Generierungsstrategien sucht man in JNoSQL logischerweise vergebens.

Die @Column-Annotation dagegen gibt es in JNoSQL. Sie ergibt auch in allen Datenbanktypen Sinn, außer bei Key-Value-Stores. Das Gleiche gilt für @Embeddable, die in Key-Value-Stores allerdings auch keinen Sinn ergeben. In Key-Value-Stores wird jeweils die ID als Key angesehen und die Entity als Value.

Relevante Unterschiede zwischen JNoSQL und JPA gibt es beim Mapping von Beziehungen. In JNoSQL lassen sich Collections aus einfachen Werten persistieren. Das Mapping von Beziehungen jedoch ist grundsätzlich nicht vorgesehen, auch weil es die unterliegenden Datenbanktechnologien (mit Ausnahme von Graph-basierten Datenbanken) nicht so richtig unterstützen. Ein Joining wäre entsprechend inperformant.

Die einzige NoSQL-Technologie, in der Beziehungen explizit vorgesehen sind, sind Graph-basierte Datenbanken. Hier gehören Beziehungen sogar so stark zum Konzept, dass eine direkte Unterstützung wünschenswert wäre. In JNoSQL werden Beziehungen in diesen Datenbanken allerdings über Repository-Abfragen und nicht über Objektbeziehungen realisiert. So etwas wie Lazy Loading gibt es nicht. Interessant ist an dieser Stelle, dass sowohl Eclipselink NoSQL als auch Hibernate OGM Graph-Beziehungen als Objektbeziehungen unterstützen.

Entity-Lifecycle und Transaktionen

Zwei weitere spannende JPA-Themen bedürften besonderer Betrachtung, wenn NoSQL in JPA aufgenommen würde: der Entity-Lifecycle und direkt damit zusammenhängend das Thema Transaktionen. Der Entity-Lifecycle sorgt in JPA dafür, dass Änderungen an Entitäten, die einmal geladen wurden, beim Transaktions-Commit wieder in die Datenbank geschrieben werden. Ein solches Konzept sucht man in JNoSQL vergeblich.

Transaktionen sind deshalb eine Herausforderung, weil sie nicht von allen NoSQL-Datenbanken unterstützt werden. Stattdessen gibt es häufig das Konzept der „Eventual Persistency“, das Einzug in den JPA-Standard halten müsste.

Um Abwärtskompatibilität zu älteren JPA-Versionen zu wahren, müsste man diese Features in irgendeiner Form in einer gemeinsamen Spec optional markieren. Das wäre bei den vielen Spezifika der einzelnen Datenbanktechnologien durchaus legitim.

Lieber zusammen als getrennt

Für die erste Jakarta-EE-Version wird diskutiert, NoSQL in den Standard aufzunehmen. Ein Vorschlag besteht darin, das Framework JNoSQL als Basis für diesen Standard zu verwenden. JNoSQL bietet eine Abstraktion des Zugriffs auf NoSQL-Datenbanken. Ähnlich wie bei Spring Data wird dadurch erreicht, dass der Zugriff auf unterschiedliche NoSQL-Datenbanken durch ein einheitliches API erfolgen kann. Um das zu erreichen, gibt es eine Schichtenarchitektur, die den konkreten Datenzugriff vom Objekt-Mapping trennt.

Aus meiner Sicht würde ein weiterer Datenzugriffsstandard neben JPA aber eher zu Verwirrung als Vereinheitlichung führen. Zusätzlich verwendet JNoSQL Annotations, die genauso heißen wie die JPA Annotations; lediglich ein Package unterscheidet sich. Außerdem gibt es mit EclipseLink NoSQL und Hibernate OGM bereits innerhalb des JPA-Standards Ansätze, NoSQL ebenfalls zu unterstützen.

Es erscheint deshalb sinnvoller, eine neue Version von JPA herauszubringen, die beide Ansätze vereint. In diesem Zusammenhang könnte die Arbeit von JNoSQL einfließen. Allerdings müssten dazu im JPA-Standard einige Umstrukturierungen vorgenommen werden. Dadurch ließe sich die Trennung zwischen Mapping und Datenbankzugriff realisieren.

Man darf gespannt sein, ob, wann und wie das geschieht.

In diesem Sinne, stay tuned.

Geschrieben von
Arne Limburg
Arne Limburg
Arne Limburg ist Softwarearchitekt bei der open knowledge GmbH in Oldenburg. Er verfügt über langjährige Erfahrung als Entwickler, Architekt und Consultant im Java-Umfeld und ist auch seit der ersten Stunde im Android-Umfeld aktiv.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: