Datenzugriff in Eclipse: Einzug des Java Persistence API in Eclipse

Und Dali ist mit von der Partie

Martin Wessel

In fast jeder Anwendungsentwicklung ist das Thema Datenzugriff von zentraler Bedeutung. Deshalb haben sich auch die verschiedenen Eclipse-Projekte in der Vergangenheit mit diesem Thema auseinander gesetzt und dafür eigene Lösungen geschaffen. Die jeweils aktuellen Standards wurden dabei berücksichtigt.

Mit dem Java-Persistenz-API (JSR 220 – EJB 3.0) ist nun der neue allgemeine Standard für den Datenbankzugriff in Java definiert und die verschiedenen Eclipse-Projekte müssen sich mit der Integration beschäftigen.
Im Bereich der Java-Persistenz-Standards gab es in den letzen Jahren sehr viel Bewegung. Ein kurzer Rückblick auf die Entstehungsgeschichte verschiedener Standards hilft beim Verständnis der aktuellen und künftigen Entwicklungen. Auch die Eclipse-Projekte, die in irgendeiner Form mit dem Zugriff auf Daten zu tun haben, müssen sich zwangsläufig mit den jeweils aktuellen Java-Persistenz-Standards auseinander setzen. Betrachtet man die technischen Entwicklungen in diesen Eclipse-Projekten in der historischen Reihenfolge (Abb. 1), wird klar, warum die Entwicklungen nicht immer geradlinig und einheitlich verlaufen sind. Besonders das Web Tools Platform-(WTP-)Projekt war als erstes Top-Level-Projekt Vorreiter in vielen Bereichen und musste im Bereich Datenbankzugriff Pionierarbeit leisten.

Abb. 1: Eclipse-Projekte mit Datenzugriff
Java-Persistenz

Bereits 1998 wurde im JDK 1.1 das JDBC in der Version 1.0 ausgeliefert. Der Zugriff auf eine relationale Datenbank ist mit JDBC relativ einfach und der Java-Programmcode ist auf Datenbanken von unterschiedlichen Herstellern ablauffähig. Das Datenbank-Schema ist zwangsläufig im Java-Programmcode enthalten, denn man hantiert hier direkt mit den Tabellen und mit den einzelnen Sätzen einer Ergebnismenge. Man spricht deshalb in diesem Zusammenhang auch vom „impedance mismatch“, also den Bruch zwischen objektorientierten Konzepten und deren Abbildung auf das relationale Datenbank-Modell.

Schon 1999 wurden Entity Beans im EJB-Standard für unternehmensweite Anwendungen eingeführt. Mithilfe der Entity Beans sollte die Abbildung der Unternehmensdaten auf die Tabellen einer relationalen Datenbank erreicht werden. Es war allerdings schnell klar, dass Entity Beans nicht als allgemeine Mapping-Technologie angesehen werden konnten. Denn die Abbildung von objektorientierten Konzepten wie Vererbung und Polimorphie und die Unterstützung von Verbindungen zwischen Objekten war unzureichend. Auch führte die Verteilung von Entity Beans zu Laufzeitproblemen in den Anwendungen.

Mit dem JDO-Standard wurde 2002 ein Standard vorgelegt, welcher einen vollständig objektorientierten Ansatz für Persistenz in Java verfolgte. Das Experten-Gremium bestand teilweise aus den Mitgliedern der ODMG, welches zuvor im Jahre 2001 seine Arbeit eingestellt hatte, und zum anderen aus den Vertretern der wichtigen relationalen Datenbank-Hersteller. JDO definiert einen einheitlichen Zugriffsmechanismus nicht nur auf Datenbanken, sondern auf jede Art von Datenhaltung.

Im Frühjahr 2004 war die Unruhe in der Java-Gemeinde besonders groß, als mit EJB 3 ein neues Vorgehen bei den Entity Beans vorgestellt wurde. Denn dieses Modell war eigentlich nicht neu, sondern eine Zusammenfassung aus verschiedenen Konzepten des bereits existierenden Standards JDO und den Ideen von herstellerspezifischen Werkzeugen wie TopLink und Hibernate. Die Bedenken vieler Experten in der Java-Gemeinde aufgrund dieses Konkurrenzkampfes zwischen JDO und EJB, haben dazu beigetragen, dass im Herbst 2004 einige Experten aus dem JDO-Gremium in das EJB 3-Gremium mit aufgenommen wurden. Im Frühjahr 2005 wurde der erste Vorschlag für ein Java-Persistenz-API veröffentlicht. Seit dieser Zeit arbeiten alle Experten gemeinsam an einer allgemeingültigen Lösung für die Abbildung von objektorientierten Java-Programmen auf relationale Datenbank-Tabellen. Dieses Persistenz-API ist nicht nur in der Java EE-Welt einsetzbar, sondern kann auch in der Java SE-Welt eingesetzt werden.

Das Persistenz-API aus EJB 3 ist also der allgemeine Java-Persistenz-Standard für weite Teile der Java-Applikationsentwicklung. Jeder Java-Entwickler sollte sich deshalb in Zukunft damit auseinander setzen. In der Artikelserie EJB Corner des Java Magazins [2] wurden bereits die grundlegenden Konzepte dieses API erläutert.

Java-Persistenz – Chronologie

  • 1993 – ODMG: Die Hersteller von Objektdatenbanken und einige Hersteller von relationalen Datenbanken bemühen sich einen allgemeinen Standard für objektorientierte Datenbanken zu erreichen. Die Abfragesprache OQL orientiert sich an SQL und wird von vielen Objektdatenbanken implementiert. Für die Programmiersprachen Smalltalk und C++ werden APIs definiert.
  • 1998 – JDBC 1.0: Im JDK 1.1 ist JDBC in Version 1.0 enthalten.
  • 11.1999 – EJB 1.1: In den EJB-Standard werden die Entity Beans aufgenommen und die Prozesse für Container Manager Persistence (CMP) und Bean Managed Persistence (BMP) werden vorgegeben.
  • 2000 – JDBC 2.0: JDBC 2.0 ist im JDK 1.2 enthalten und wird u.a. um folgende Funktionalität erweitert: Batch Updates, Scrollable ResultSets und Distributed Transactions.
  • 2001 – ODMG: Arbeit wird eingestellt. Das Java-Binding dient als Basis für den späteren JDO-Standard.
  • 8.2001 – EJB 2.0: Entity Beans werden um Container Managed Relationships, Local- und Home Interfaces erweitert.
  • 10.2001 – JDBC 3.0: ist im JDK 1.4 enthalten und enthält u.a. folgende Erweiterungen: Connection Pool, Prepared Statement Pool, Savepoints und Unterstützung von Auto-generated Keys.
  • 4.2002 – JDO 1.0 (JSR 12)
  • 11.2003 – EJB 2.1: Die EJB Query unterstützt nun auch Sortierung (ORDER BY).
  • 6.2003 – EJB 3 (JSR 220 eingerichtet): Das Programmiermodell der EJB gilt allgemein als aufwendig in der Implementierung und im Test. Auch das Mapping auf relationale Datenbanken mithilfe von Entity Beans ist weit von einer optimalen Lösung entfernt.
  • 5.2004 – JDO 2.0 (JSR 243) eingerichtet: Die API von JDO 1.1 hat Lücken, die einer breiten Akzeptanz im Wege stehen. Besonders die Query wird erweitert, um die relationalen Datenbanken besser zu unterstützen.
  • 6.2004 – EJB 3.0 Early Draft: Ein völlig neues API für Entity Beans wird veröffentlicht. Dabei werden Konzepte von JDO, Hibernate und TopLink übernommen. Entity Beans sind jetzt normale Java-Objekte, die kein Remote-Interface mehr besitzen.
  • 9.2004 – Zusammenführung EJB + JDO: Sun als Moderator des Java Community Process gibt die Aufnahme der JDO-Experten in das EJB 3.0 Experten-Forum bekannt [1].
  • 1.2005 – JDO 2-Abstimmung zum Early Draft fehlgeschlagen: Wegen der allgemeinen Unsicherheit über die aktuellen Entwicklungen in den beiden Standards JDO und EJB 3 können sich die Experten nicht über die künftige JDO API verständigen.
  • 2.2005 – EJB 3.0 + JDO Zusammenführung, EJB 3.0 Early Draft 2: Die angekündigte Zusammenführen hat stattgefunden und liefert sehr schnell auch eine überarbeitete Version des EJB 3-Standards. Das Java-Persistenz-API wird in ein separates Dokument ausgelagert. Dadurch kann dieser Teil auch außerhalb von Java EE, also z.B. in Java SE, angewendet werden.
  • 2.2005 – JDO 2-Abstimmung über den ersten Entwurf endlich erfolgreich: JDO orientiert sich weiter nicht nur an dem Mapping zu relationalen Datenbanken.
  • 8.2005 – JDO 2-Vorschlag für die finale Abstimmung wird vorgestellt.
  • 12.2005 – EJB 3-Vorschlag für die finale Abstimmung wird vorgestellt.
  • 3.2006 – JDO 2-Die finale Version wird nahezu einstimmig verabschiedet.
Eclipse-Projekte

Dem Entwickler werden in Eclipse Editoren und Hilfesysteme für alle möglichen Programmiersprachen und Dateitypen zur Verfügung gestellt. Aber nicht nur die Erstellung der Software ist Bestandteil von Eclipse, sondern auch der Entwurf und der Test von Software wird in ein einheitliches Umfeld integriert. Die verschiedenen Eclipse-Projekte bieten für spezielle Anwendungsfelder spezifische Lösungsvorschläge, die sich ebenfalls über die gesamte Laufzeit eines Projektes erstrecken und Eclipse als Integrationsplattform nutzen.

Web Tools Platform (WTP)

  • 6.2004 – Gründung
  • Projektmanagement: BEA, ObjectWeb, IBM, Innoopract, Eteration, Oracle
  • Ziele: Entwicklungswerkzeuge für Java EE Webapplikationen
  • Unterprojekte:

    – Web Standard Tools (WST): Werkzeuge für, HTML, XML, CSS, JavaScript

    – j2ee Standard Tools (JST): Modell für Projekte, Editoren, Server (Laufzeitumgebungen); Unterstützung aller Artefakte (web.xml, ejb-jar.xml, application.xml, war, ejb jars, ear, rar

    – The JavaServer Faces (JSF) Tools Datenzugriff: generell über JDBC; Definition von Werkzeugen für Datenbanken in der Komponente (RDB)

Das WTP-Projekt [3] [4] ist so ein Projekt, das Lösungen für alle Probleme im Umfeld einer Webapplikation liefert. Es wurde 2004 gegründet und ist in vielen Aspekten ein Vorreiter für spätere Eclipse-Projekte. Besonders die Definition des Prozesses, also wie so ein Top-Level-Projekt in Eclipse eigentlich eingerichtet und betrieben werden soll, wurden für das WTP-Projekt erarbeitet und damit für folgende Projekte definiert.

Das WTP-Projekt hat sich dann auch gleich an ein wirklich beachtliches Aufgabenspektrum rangemacht. Will man ein Webprojekt für eine unternehmensweite Anwendung erstellen und betreiben, muss man sich um sehr viele Themen kümmern. Die Spanne geht von Darstellung und Aufbereitung der Informationen in der eigentlichen Webapplikation über Layer- und Schichtenmodell bis hin zum Zugriff auf Datenbanken und andere Datenquellen. Natürlich immer unter dem Gesichtspunkt der Entwicklung, des Tests und des Betriebs einer solchen Anwendung. Eine Aufteilung in verschiedene Unterprojekte scheint bei dem großen Umfang der Aufgaben angebracht.

Das Unterprojekt Web Standard Tools (WST) befasst sich mit allen Belangen der Webentwicklung und deren existierenden Standards. Es stellt dafür Werkzeuge und Lösungskonzepte vor. Die Anzahl der Standards, Protokolle und Dateiformate ist nahezu unüberschaubar. Doch gerade deshalb werden die unterschiedlichen Themenbereiche hier strukturiert angegangen.

Das Unterprojekt j2ee Standard Tools (JST) definiert einheitliche Modelle und stützt sich beim Zugriff auf Datenbanken nicht alleine auf die in Java EE verwendeten Entity Beans, sondern schafft auch Werkzeuge, um die Arbeit mit Datenbanken im Allgemeinen zu erleichtern.

Unter dem Begriff WTP – Data Tools sind hier Modelle entstanden, um die Nutzung der Daten zu vereinheitlichen und die Integration von Werkzeugen erleichtern. Eines dieser Werkzeuge ist der Datenbank-Server-Explorer. Er zeigt alle Informationen wie Tabellen, Views und StoredProcedures einer relationalen Datenbank. Das zugrunde liegende Modell basiert auf SQL 99/2003. Im Paket org.eclipse.wst.rdb.models.dbdefinition werden die spezifischen Besonderheiten der jeweiligen Datenbank auf dieses Eclipse-Modell abgebildet. So wird erreicht, dass die Werkzeuge für alle relationalen Datenbanken gleich aussehen und gleich funktionieren. Der JDO-Standard und verschiedene Mapping-Technologien wurden nicht in das Aufgabenspektrum des WTP-Projekts aufgenommen, weil sie keinen Standard im Java-Enterprise-Umfeld darstellen. Betrachtet man aber die aktuellen Entwicklungen im Bereich des Java-Persistenz-API, so wird mit der Unterstützung von EJB 3 das Thema Mapping doch künftig Einzug in das WTP-Projekt finden (siehe Kasten „Java-Persistenz – Historie“).

BIRT – Steckbrief

  • 8.2004 – Vorschlag eingereicht
  • 9.2004 – Gründung
  • Projektmanagement: Actuate
  • Ziele: Reporting Tools für Java-Applikationen und Webapplikationen; einfache Benutzung für Java-Entwickler und -Anwender
  • Unterprojekte:

    – Eclipse Report Designer (ERD)

    – Eclipse Report Engine (ERE)

    – Eclipse Charting Engine (ECE)

    – Web-Based Report Designer (WRD)

  • Datenzugriff: über JDBC und über das Open Data Access API (ODA)

Das Business Intelligence and Reporting Tools-(BIRT-)Projekt [5] [6] wurde 2004 gegründet und liefert Werkzeuge für die Definition und Generierung von Reports. Die Ablaufumgebungen für diese Reports sind in jede Art von Java-Applikation integrierbar. Alle Werkzeuge müssen für den Entwickler und natürlich auch für den Anwender leicht bedienbar sein. Das Format der Report-Definitionen ist unabhängig von der zugrunde liegenden Datenquelle. Mit dem Open Data Access (ODA) API können sehr leicht unterschiedliche Datenquellen angebunden werden. Die Implementierung orientiert sich an JDBC, ist aber nicht davon abhängig. So können neben relationalen Datenbanken auch andere Datenquellen und Dateien in beliebigen Formaten leicht eingebunden werden.

Unterprojekte im Technology Project

Das Technology Project dient generell als Startpunkt für neue Projekte im Eclipse-Umfeld, bei denen eine Zuordnung zu einem anderen Projekt nicht sofort sinnvoll erscheint. Diese neuen Projekte können hier erst mal eingerichtet und weiter spezifiziert werden. Es ist auch möglich, dass sich die Ziele und Aufgabenbereiche von zwei Projekten überlappen. So wird durch den Konkurrenzdruck die hoffentlich beste technische Lösung entstehen oder die am Markt eingesetzte Lösung wird bestmöglich unterstützt. Zu einem späteren Zeitpunkt werden diese Projekte vermutlich anderen Top-Level-Projekten zugeordnet. Quasi gleichzeitig wurden in dem Technology Project zwei neue Vorschläge für Werkzeuge im Java-Persistenz-Umfeld eingereicht.

JSR220-ORM – Steckbrief

  • 4.2005 – Vorschlag eingereicht
  • 7.2005 – Gründung
  • Projektmanagement: Versant, Ambysoft, Sybase
  • Ziele: Werkzeuge für EJB 3 (JSR 220) und JDO 2 (JSR 243); Offenheit für verschiedene Laufzeitsysteme
  • Datenzugriff: zu relationalen Datenbanken über JDBC und über proprietäre Protokolle zu anderen Datenbanken wie objektorientierten Datenbanken.

Versant hatte im Frühjahr 2005 das Projekt JSR220-ORM eingereicht und verfolgt damit das Ziel, Werkzeuge für die neue Java-Persistenz-API zu erstellen. Als Ablaufumgebung sollen hier Werkzeuge von verschiedenen Herstellern zum Einsatz kommen. Einige Entwickler dieses Projektes haben an der Komponente RDB im WTP-Projekt mitgearbeitet und nutzen diese Komponente natürlich auch im eigenen Plug-in.

Oracle hat mit dem Projekt Dali ebenfalls einen Vorschlag eingereicht, um Werkzeuge zu erstellen, welche das neue Java-Persistenz-API unterstützen. Auch hier können Ablaufumgebungen von verschiedenen Herstellern integriert werden. Das Plug-in nutzt die RDB-Komponente aus dem WTP-Projekt für den Zugriff auf die relationale Datenbank.

Weil diese beiden Projekte gleichzeitig und unabhängig voneinander eingereicht wurden, überlappen sie sich in ihrer Zielsetzung sehr stark. Deshalb wurde im Januar dieses Jahres der Zusammenschluss dieser beiden Projekte bekannt gegeben. Das Dal- Projekt wird unter der Führung von Oracle weiterbestehen. Das JSR220-ORM-Projekt wird eingestellt, die Quellen werden in das Dali Projekt integriert und die Projektmitglieder werden sich innerhalb des Dali-Projektes um das Modell für die Datenbank kümmern.


Dali – Steckbrief

  • 4.2005 – Vorschlag eingereicht (EJB 3.0 ORM)
  • 7.2005 – Gründung
  • 1.2006 – Zusammenschluss mit JSR220-ORM-Projekt
  • Projektmanagement: Oracle, BEA (vorher SolarMetric, JBoss, Versant
  • Ziele: Werkzeuge für EJB 3.0; Offenheit für verschiedene Laufzeitsysteme
  • Datenzugriff: zu relationalen Datenbanken über JDBC.

Datenzugriff durch Eclipse

Das Thema Datenzugriff ist also bereits in verschiedenen Eclipse-Projekten gelöst worden:

  • WTP: Data-Tools-Komponenten ermöglichen den Zugriff auf relationale Datenbanken.
  • BIRT: Das Open Data Access API ermöglicht den Zugriff auf alle möglichen Datenquellen.
  • Dali: Werkzeuge für das neue Persistenz-API. Die Projekte Dali und JSR220-ORM haben bereits beim Projektstart auf eine spätere Integration in das WTP-Projekt hingewiesen.

Zeitgleich mit dem Entstehen der Projekte JSR220-ORM und Dali gab es konkrete Planungen für ein neues Top-Level-Projekt auf Eclipse.org: das jetzige Data Tools Platform-(DTP-)Projekt. Dieses wurde im Herbst 2005 eingerichtet und hat das Ziel, Werkzeuge für alle Arten von Datenquellen zur Verfügung zu stellen. Dabei liegt die Betonung wirklich auf allen Datenquellen und nicht nur auf Datenbanken und schon gar nicht nur auf SQL Datenbanken. Deshalb muss man sich Konzepte überlegen, wie ein einheitlicher Zugriff auf diese verschiedenen Datenquellen geschehen soll. Auch die Beschreibung dieser Datenquelle muss möglich sein und kann sich eben nicht einfach auf SQL-Datentypen beziehen. In dem Unterprojekt Model Base wird so ein Modell zur Beschreibung von Datenquellen definiert. Die Komponente RDB aus dem WTP-Projekt hat genau diese Problemstellung bereits gelöst und wurde deshalb gleich zu Beginn an das DTP-Projekt übergeben. Damit ist ein wichtiger Grundstein für die weiteren Arbeiten gelegt. Dieses Projekt dient später als Basis um Model Driven Development zu unterstützen. Das Unterprojekt Connectivity stellt Komponenten zur Verfügung um die Verbindung zu jeder beliebigen Datenquelle herstellen zu können. Auch diese Problemstellung ist bereits in dem BIRT-Projekt mit der Komponente ODA gelöst und wurde deshalb ebenfalls gleich zu Beginn dem DTP-Projekt unterstellt. Natürlich spielen SQL Datenbanken eine große Rolle in der Anwendungsentwicklung. Deshalb beschäftigt sich das Unterprojekt SQL Development Tools mit allen Aspekten, die für die Arbeit mit einer SQL Datenbank wichtig sind. Besonders hier ist es hilfreich einheitliche Werkzeuge zu haben, die mit verschiedenen SQL-Dialekten umgehen können.

Das DTP-Projekt ist übrigens ein gutes Beispiel für die Wiederverwendung. Komponenten, die bereits in anderen Projekten erfolgreich eingesetzt wurden, werden hier zu einem neuen Ganzen zusammengefügt und ergeben hier dann mehr als nur die Summe aller Teile. Auch für die beiden geplanten neuen Unterprojekte Administration und Mapping, werden vermutlich bereits existierende Lösungen aus anderen Projekten in das DTP-Projekt übernommen.

Data Tools Platform (DTP) – Steckbrief

  • 6.2005 – Vorschlag eingereicht
  • 8.2005 – Gründung
  • Projektmanagement: Sybase, BEA, Actuate
  • Ziele: Entwicklungswerkzeuge für datenbasierte Applikationen; keine Beschränkung auf Datenbanken.
  • Unterprojekte

    – Model Base: Hier wird die Komponente RDB aus dem WTP-Projekt integriert.

    – Connectivity: Hier wird die Komponente Open Data Access API aus dem BIRT-Projekt integriert.

    – SQL Development Tools

    – Administration (in Planung)

    – Mapping (in Planung)

  • Datenzugriff: Die Komponente RDB greift mit JDBC auf relationale Datenbanken zu. Die Komponente Open Data Access API (ODA) ermöglicht den Zugriff auf andere Datenquellen.
Die Zukunft

Das WTP-Projekt will bis Ende Juni 2006 die Version 1.5 freigeben. Darin soll auch das Thema EJB 3.0 adressiert werden. Für das Java-Persistenz-API aus dem EJB 3.0-Standard ist die Integration mit dem Dali-Projekt geplant. Diese beiden Projekte werden auch künftig eng zusammenarbeiten. Ob das nun aber bedeutet, dass das Dali-Projekt auch organisatorisch in das WTP-Projekt übergeht, steht noch nicht fest. Denn auch eine Integration in das DTP-Projekt erscheint sinnvoll, denn dort soll ja alles gesammelt werden, was mit Datenquellen aller Art zu tun hat. Bereits jetzt werden die Komponenten aus dem DTP-Projekt in anderen Eclipse-Projekten (WTP, BIRT) benutzt. Die Abbildung 2 zeigt die mögliche Struktur der Eclipse-Projekte. Neue Projektvorschläge wie z.B. das SOA (Service Oriented Architecture) Tools Platform Project (STP) orientieren sich gleich zu Beginn an den verfügbaren Komponenten im DTP-Projekt, damit wenigstens hier das berühmte Rad nicht neu erfunden wird.

Abb. 2: Eclipse Projekte mit Datenzugriff – Zukunft

Martin Wessel beschäftigt sich seit mehr als zehn Jahren mit objektorientierten Technologien in den Bereichen Medizintechnik und Telekommunikation. Dabei lag der Schwerpunkt immer auf objektorientierte Datenbank- und Datenzugriffstechnologien. In seiner aktuellen Rolle als Principal Consultant bei Versant verfolgt er die Entwicklungen verschiedener Eclipse-Projekte zum Thema Datenzugriff und gibt seine Erfahrungen auf Konferenzen und durch Publikationen an Interessenten weiter.

Geschrieben von
Martin Wessel
Kommentare

Schreibe einen Kommentar

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