OSGi goes Enterprise

Von JDBC zu JPA

In unserer Enterprise-Anwendung wollen wir JPA-Entitäten nutzen. Diesem Ziel sind wir mit einer lauffähigen JDBC-Service-Implementierung für unsere Lieblingsdatenbank einen guten Schritt näher gekommen. Nun können wir uns daran machen, die JPA-Entitäten zu integrieren. Halten wir uns noch einmal unser Ziel vor Augen: Wir möchten eine durch und durch modulare Enterprise-Anwendung realisieren. Die Modularisierung soll durchgängig von der Persistenzschicht bis zur Präsentationsschicht gewährleistet sein. Das hat zur Konsequenz, dass wir in der Lage sein müssen, unsere JPA-Entitäten auf mehrere OSGi Bundles zu verteilen. Diese verschiedenen Bundles mit JPA-Entitäten greifen dann unter Umständen auch auf mehrere verschiedene Datenbanken zu.

Dazu müssen wir für jedes Bundle mit JPA-Entitäten ein Paket aus JPA-Entitäten und Mapping-Metadaten (wie eine Liste der JPA-Entitäten, Konfigurationseinstellungen und Ähnliches) schnüren und über eine JPA EntityManagerFactory nutzen. Dieses Paket wird in der JPA-Terminologie als Persistence Unit bezeichnet. Sie ist die geeignete Stelle, um unsere Anwendung in Module zu schneiden – also in OSGi Bundles. Das heißt, wir erstellen für jede Persistence Unit ein OSGi Bundle. Dann ist die Persistenzschicht unserer Enterprise-Anwendung modular aufgebaut.

Schauen wir uns nun zunächst an, wie der OSGi-Enterprise-Standard die Integration von JPA vorsieht. Danach lernen wir an einem Beispiel die Implementierung des Eclipse-Gemini-Projekts kennen. Für JPA ist laut OSGi-Enterprise-Spezifikation der OSGi Service EntityManagerFactoryBuilder zuständig. Mit diesem Service kann für jede Persistence Unit eine EntityManagerFactory erzeugt werden. Andere Bundles nutzen dann diese EntityManagerFactory, um den EntityManager zu erzeugen, der dann für das Bundle die Arbeit mit den JPA-Entitäten übernimmt.

Nehmen wir nun an, es gibt mehrere Persistence Units. Dann wird mittels des EntityManagerFactoryBuilder-Services für jede Persistence Unit eine EntityManagerFactory erzeugt. Wie können wir nun die verschiedenen EntityManagerFactorys unterscheiden? Dazu sieht die Spezifikation des OSGi Services so genannte Service-Properties vor. Ein Service-Consumer, der den EntityManagerFactory-Service verwenden möchte, filtert über diese Service-Properties. Der Name der Service-Property einer Persistence Unit ist osgi.unit.name. Nehmen wir an, wir haben ein Bundle für die Persistence Unit Accounts. Dann muss ein Service-Consumer, der die EntityManagerFactory der Persistence Unit Accounts verwenden möchte, den Filter (osgi.unit.name=Accounts) verwenden. Tut er das nicht, erhält er die EntityManagerFactorys der falschen oder sogar aller Persistence Units. Also merken wir uns, dass die EntityManagerFactory immer über einen Filter eingeschränkt werden muss!

Um die Verbindung zur Datenbank herzustellen, braucht Gemini JPA die Zugangsdaten, d. h. User, Passwort und JDBC URL. Diese können derzeit leider nur in dem Mapping-Metadaten (definiert in der Datei persistence.xml) angegeben werden. Das ist jedoch nicht praxistauglich, da bei jeder Änderung des Passworts das entsprechende OSGi Bundle neu deployt werden muss. Das Problem soll künftig auf folgende Arten gelöst werden: Variante 1 [13] ist die Integration von Gemini JPA mit dem Config Admin Service, dem Konfigurationsmechanismus von OSGi. Gemini JPA erfragt die Zugangsdaten für die Datenbank beim Config-Admin-Service der diese je nach Implementierung beispielsweise aus einer externen Konfigurationsdatei einliest. Variante 2 sieht die Integration von Gemini JPA mit einem weiteren Eclipse-Gemini-Projekt namens Gemini Naming [14] vor. Dabei handelt es sich um eine Implementierung von JNDI [15] für OSGi. Bei dieser Variante ermittelt Gemini JPA die Zugangsdaten für die Datenbank über JNDI, wie im Java Enterprise Standard üblich.

Gemini JPA versus Eclipse Link OSGi

Eclipse Link bietet mit Eclipse Link OSGi bereits eine Integration von JPA für OSGi an. Diese stammt jedoch aus der Zeit vor der OSGi-Enterprise-Spezifikation. Eclipse Link OSGi wird nicht mehr weiter entwickelt und somit auch nicht die OSGi-Enterprise-Spezifikation implementieren. Der offizielle Nachfolger ist das Eclipse-Gemini-Projekt, das auch Teile der Implementierung übernommen hat.

Kommentare

Schreibe einen Kommentar

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