Teil 1: Integration von JDBC und JPA mit Gemini JPA

OSGi goes Enterprise

Jan Stamer

OSGi ist ja schon ein alter Hut. Aber welche Projekte nutzen denn OSGi? Laut Wikipedia [1] sind dies Apache, Eclipse, IBM, JBoss, Oracle und viele mehr. Aber Moment mal – das sind ja lauter Application-Server-Projekte! Wo sind denn da die Enterprise-Anwendungen? Genau, da sieht es ziemlich düster aus. Hier kommt das Eclipse-Gemini-Projekt [2] ins Spiel. Die Vision von Eclipse Gemini sind Enterprise-Anwendungen, die sich aus Enterprise-Modulen zusammensetzen. Gemini liefert den passenden Werkzeugkasten dazu. Wie mit diesen Tools tatsächlich Enterprise-Anwendungen gebaut werden können, werden wir in dieser Artikelserie kennen lernen.

Der erste Baustein unserer Anwendung mit Gemini ist der Anschluss an die Datenbank. Dazu nutzt die Anwendung das Java Persistence API (JPA) [3] und somit auch JDBC. Damit ist auch schon der Rahmen für diesen Artikel abgesteckt: In unserer Enterprise-Anwendung wollen wir OSGi Bundles mit JPA-Entitäten nutzen. Passend dazu bietet der Eclipse-Gemini-Werkzeugkasten Gemini JPA [4]. Wie das genutzt wird, werden wir nun kennen lernen. Dabei beginnen wir ganz unten bei der Datenbank und arbeiten uns hoch bis zu unseren JPA-Entitäten.

Zugriff auf die Datenbank mit JDBC und OSGi – kein Problem, oder?

Zehn Jahre hat es gedauert, nun ist es soweit. Der JDBC Service der OSGi-Enterprise-Spezifikation [5] regelt, wie JDBC in OSGi-Anwendungen zu integrieren ist. Wird eine JDBC DataSource benötigt, so wird sie über den JDBC-Service [6] erzeugt. Diesem wird mitgeteilt, was für eine DataSource gebraucht wird, und er gibt dann die entsprechende DataSource zurück. Eine Anfrage an den JDBC-Service lautet beispielsweise: Gib‘ mir eine DataSource für den URL jdbc:postgresql://localhost:5432/gemini und authentifiziere dich als Benutzer admin mit Passwort admin. Als Ergebnis gibt es dann eine DataSource für eine Postgres-Datenbank unter dem Benutzer admin. Braucht ein Bundle eine DataSource, erzeugt es sich diese also nicht selbst, sondern nutzt dazu den JDBC-Service. Das Bundle hängt nun also vom JDBC-Service ab, dafür aber nicht mehr von konkreten JDBC-Treibern. Die Verwaltung der JDBC-Treiber obliegt einzig und allein dem JDBC-Service. Für das Bundle ist also transparent, welche Datenbank und welcher JDBC-Treiber genutzt werden.

Soweit die Theorie, nun zur Praxis. Obwohl der JDBC-Service aus der OSGi-Spezifikation sehr einfach ist, gibt es bis dato fast keine Implementierungen. Eine Recherche im Web liefert diverse Codeschnipsel für die eine oder andere Datenbank, aber nicht mehr. Aber da gibt es doch dieses Eclipse-Gemini-Projekt… Und tatsächlich, es bietet mit DBAccess [7] eine Implementierung des JDBC-Service an. Gerade erst wurde die erste stabile Version 1.0.0 veröffentlicht.

Gemini DBAccess besteht aus einem Bundle mit der Implementierung des JDBC-Service. Zusätzlich wird für jede unterstützte Datenbank ein weiteres Bundle benötigt plus ein Bundle mit dem JDBC-Treiber der Datenbank. Für die Apache-Derby-Datenbank brauchen wir also zunächst das Bundle mit dem JDBC-Service org.eclipse.gemini.dbaccess.util.jar. Dazu kommt das Bundle für Derby org.eclipse.gemini.dbaccess.derby.jar und das Bundle mit dem JDBC-Treiber für Derby org.apache.derby.jar. Sobald wir diese drei Bundles deployt haben, können wir loslegen. Listing 1 zeigt, wie mit diesen Bundles eine DataSource erzeugt wird.

Listing 1
public DataSource createDataSource() throws SQLException {
   DataSourceFactory dataSourceFactory = getDataSourceFactory();
   Properties properties = new Properties();
   properties.put(DataSourceFactory.JDBC_URL, "jdbc:postgresql://localhost:5432/gemini");
   properties.put(DataSourceFactory.JDBC_USER, "admin");
   properties.put(DataSourceFactory.JDBC_PASSWORD, "secret");
   DataSource dataSource = dataSourceFactory.createDataSource(properties);     
   return dataSource;
}

Alternativ zur Implementierung aus Listing 1 bietet die DataSourceFactory des JDBC-Service noch die Methode createConnectionPoolDataSource an, um eine DataSource mit Connection Pooling zu erzeugen.

Bei genauerer Betrachtung des DBAccess-Projekts macht sich leider etwas Ernüchterung breit. Gemini DBAccess unterstützt in Release 1.0.0 nur Apache Derby als einzige Datenbank. Allerdings finden sich Bundles für Postgres unter [8] und für H2 sowie MySQL unter [9]. Die Integration dieser Datenbanken in ein offizielles Release ist gerade in Arbeit. Wer es nicht abwarten will oder kann, muss die Quellen des DBAccess-Projekts selbst anzapfen. Das Beispielprojekt zu diesem Artikel (siehe Abschnitt „Putting it Together“) nutzt die H2-Datenbank aus oben genannter Quelle.

Geschrieben von
Jan Stamer
Kommentare

Schreibe einen Kommentar

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