© StonePictures/Shutterstock.com
Kolumne: EnterpriseTales

Kolumne: EnterpriseTales


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 [1], 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 [2] 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 [3].

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 Graph-basiert. Zunächst war also die Frage zu klären, ob eine gemeinsame Abstraktion dieser Konzepte, wie Spring sie mit Spring Data fährt [3], ü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....

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang