© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: EnterpriseTales

Kolumne: EnterpriseTales


Am 11. Mai 2006 wurde der EJB-3.0-Standard veröffentlicht und mit ihm die Version 1.0 des Java Persistence API, kurz JPA. Und so hatte JPA vor einem knappen Dreivierteljahr seinen ersten runden Geburtstag. Zehn Jahre sind in der IT-Welt eine halbe Ewigkeit. Wie hat der JPA-Standard diese Zeit überstanden? Wo kam er her? Was hat er bewirkt? Und welche Bedeutung hat er heute und in der Zukunft?

Seit den 70er-Jahren des letzten Jahrhunderts gibt es relationale Datenbanken, spätestens in den 90er-Jahren setzten sie sich endgültig im Enterprise-Computing durch. In Java gibt es seit 1996 die Möglichkeit, standardisiert auf relationale Datenbanken zuzugreifen. Da wurde nämlich die Version 1.0 des JDBC-API veröffentlicht [1]. Damit konnte zwar auf eine relationale Datenbank zugegriffen werden, als Ergebnis bekam man aber eine relationale Sicht auf die Daten. Da Java eine objekt­orientierte Programmiersprache ist, ergab sich bereits damals die Herausforderung, diese Daten nach dem Laden in Objekte zu mappen und Objekte beim Speichern wieder in die relationale Repräsentation zu überführen. Man benötigt ein Object-relational Mapping.

Herausforderungen des Object-relational Mappings

Dass beim Object-relational Mapping (ORM) Datenbankspalten auf Objektattribute gemappt werden, ist unmittelbar einsichtig. Herausforderungen sind aber das Mapping von Java-Objektbeziehungen auf Datenbankfremdschlüsselbeziehungen, das Mapping von Ableitungshierarchien und das Mapping eines feingranularen Datenmodells auf relationale Datenbanken, bei denen häufig eine gröbere Granularität vorzufinden ist, also weniger Tabellen. Auch die Gleichheit ist eine Herausforderung: Während in Java in der Regel zwei Objektreferenzen als gleich definiert werden, wenn sie auf dasselbe Java-Objekt zeigen, gibt es in einer relationalen Datenbank häufig einen Primärschlüssel. Wenn also beim ORM zweimal dieselbe Zeile gemappt wird, muss beim Vergleich beachtet werden, dass gegebenenfalls zwei unterschiedliche Java-Objekte dieselbe Zeile repräsentieren.

Es gab schon früh Bemühungen, den Vorgang des ORMs in Java zu standardisieren. Ein erster Versuch war der JDO-Standard, der im Jahr 1999 ins Leben gerufen und 2001 verabschiedet wurde [2]. Er wurde aber nicht als J2EE-Standard übernommen. Stattdessen entschied man sich, EJB Entity Beans als Ansatz für ORM zu standardisieren. Diese erwiesen sich in der Praxis als schlecht handhabbar und viel zu schwergewichtig, weshalb sie sich nicht durchsetzten. Als Folge ...

Java Magazin
Kolumne: EnterpriseTales

Kolumne: EnterpriseTales

Am 11. Mai 2006 wurde der EJB-3.0-Standard veröffentlicht und mit ihm die Version 1.0 des Java Persistence API, kurz JPA. Und so hatte JPA vor einem knappen Dreivierteljahr seinen ersten runden Geburtstag. Zehn Jahre sind in der IT-Welt eine halbe Ewigkeit. Wie hat der JPA-Standard diese Zeit überstanden? Wo kam er her? Was hat er bewirkt? Und welche Bedeutung hat er heute und in der Zukunft?

Arne Limburg


Am 11. Mai 2006 wurde der EJB-3.0-Standard veröffentlicht und mit ihm die Version 1.0 des Java Persistence API, kurz JPA. Und so hatte JPA vor einem knappen Dreivierteljahr seinen ersten runden Geburtstag. Zehn Jahre sind in der IT-Welt eine halbe Ewigkeit. Wie hat der JPA-Standard diese Zeit überstanden? Wo kam er her? Was hat er bewirkt? Und welche Bedeutung hat er heute und in der Zukunft?

Seit den 70er-Jahren des letzten Jahrhunderts gibt es relationale Datenbanken, spätestens in den 90er-Jahren setzten sie sich endgültig im Enterprise-Computing durch. In Java gibt es seit 1996 die Möglichkeit, standardisiert auf relationale Datenbanken zuzugreifen. Da wurde nämlich die Version 1.0 des JDBC-API veröffentlicht [1]. Damit konnte zwar auf eine relationale Datenbank zugegriffen werden, als Ergebnis bekam man aber eine relationale Sicht auf die Daten. Da Java eine objekt­orientierte Programmiersprache ist, ergab sich bereits damals die Herausforderung, diese Daten nach dem Laden in Objekte zu mappen und Objekte beim Speichern wieder in die relationale Repräsentation zu überführen. Man benötigt ein Object-relational Mapping.

Herausforderungen des Object-relational Mappings

Dass beim Object-relational Mapping (ORM) Datenbankspalten auf Objektattribute gemappt werden, ist unmittelbar einsichtig. Herausforderungen sind aber das Mapping von Java-Objektbeziehungen auf Datenbankfremdschlüsselbeziehungen, das Mapping von Ableitungshierarchien und das Mapping eines feingranularen Datenmodells auf relationale Datenbanken, bei denen häufig eine gröbere Granularität vorzufinden ist, also weniger Tabellen. Auch die Gleichheit ist eine Herausforderung: Während in Java in der Regel zwei Objektreferenzen als gleich definiert werden, wenn sie auf dasselbe Java-Objekt zeigen, gibt es in einer relationalen Datenbank häufig einen Primärschlüssel. Wenn also beim ORM zweimal dieselbe Zeile gemappt wird, muss beim Vergleich beachtet werden, dass gegebenenfalls zwei unterschiedliche Java-Objekte dieselbe Zeile repräsentieren.

Es gab schon früh Bemühungen, den Vorgang des ORMs in Java zu standardisieren. Ein erster Versuch war der JDO-Standard, der im Jahr 1999 ins Leben gerufen und 2001 verabschiedet wurde [2]. Er wurde aber nicht als J2EE-Standard übernommen. Stattdessen entschied man sich, EJB Entity Beans als Ansatz für ORM zu standardisieren. Diese erwiesen sich in der Praxis als schlecht handhabbar und viel zu schwergewichtig, weshalb sie sich nicht durchsetzten. Als Folge ...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang