"Letztendlich wird es die Java Community sein, die darüber entscheidet, wie Modularität sich in Java weiterentwickelt"

Oracle-Architekt Mike Keith über OSGi, Gemini und JDK 8

OSGi-Standardimplementierungen finden sich zunehmend bei Eclipse wieder. So spendete etwa SpringSource anfangs des Jahres die Codebasis ihres Spring-DM-Produktes an Eclipse, welche als Referenzimplementierung der OSGi-Blueprint-Spezifizierung in das neu gegründete Eclipse-Projekt Gemini integriert wurde. Mike Keith von Oracle beschreibt, was es mit dem Gemini-Projekt auf sich hat und nimmt Stellung zu der Frage, ob OSGi als Modularisierungsstandard in das JDK 8 einfließen sollte.

JAXenter: Hallo Mike! Welche Hindernisse gibt es deiner Meinung nach für die Einführung von OSGi im Enterprise-Bereich?

Mike Keith: Enterprise-Anwendungen sind typischerweise groß und komplex, was zur Folge hat, dass diese nicht leichtfertig durch etwas anderes ersetzt werden und lange im Einsatz sind. Nun gibt es in der Entstehungsgeschichte von Enterprise-Anwendungen zahlreiche Enterprise-Technologien, die nicht modular aufgebaut sind. Angesichts der Tatsache, dass wenige Enterprise-Anwendungen wirklich von Grund auf neu geschrieben werden, ist es eine der größten Herausforderungen bei der Einführung irgendeiner Art von Modularisierung, einen vernünftigen Grad an Kompatibilität mit den bereits existierenden Anwendungsteilen zu gewährleisten.

Üblicherweise besteht die zweite Herausforderung darin, die Denkweise der Entwickler derart zu verändern, dass sie in Begriffen von Abhängigkeiten denken, sowie sie mit Werkzeugen zu versorgen, die ihnen dabei helfen, modularisierten Code zu entwickeln, zu testen und aktuell zu halten. Außerdem kommt es dann noch darauf an, das Management davon zu überzeugen, dass Investitionen in Modularisierung auf lange Sicht Zeit und Ressourcen sparen.

JAXenter: Kannst du das Eclipse Gemini-Projekt kurz vorstellen und beschrieben, wie Gemini diese Hindernisse überwinden helfen kann?

Mike Keith: Gemini ist ein Eclipse-Projekt, das modulare Implementierungen von Enterprise-Technologien bereitstellt. Es besteht aus verschiedenen Unterprojekten, welche jedes eine spezifische Technologie implementiert. Diese Unterprojekte sind weitgehend unabhängig voneinander und können einzeln oder gemeinsam heruntergeladen und genutzt werden. Sie stellen eine Basis für Entwickler dar, um mittels bekannter und gern genutzter Technologien modularisierte Enterprise-Applikationen zu schreiben.

JAXenter: Aus welchen Teilen besteht Gemini?

Mike Keith: Gemini besteht aus sechs Unterprojekten, von denen jedes eine modularisierte Implementierung einer aktuellen OSGi-Enterprise-Spezifizierung darstellt.

  • Gemini Web löst das Problem, ein Web Application Archiv (WAR) zu deployen und in einem OSGi Framework zu starten
  • Gemini Blueprint ist das neue zu Hause für das, was früher das Spring-DM-Projekt war. Es implementiert die OSGi-Blueprint-Komponenten-Spezifizierung
  • Gemini DBAccess bietet Zugriff auf JDBC-Treiber und -Datenbanken in Form von geteilten Modulen.
  • Gemini JPA implementiert den OSGi-Standard für die Konfiguration, das Deployment und den Zugriff auf JPA-Persistenz-Einheiten.
  • Gemini Naming ist eine Implementierung des viel genutzten Java Naming and Directory Interface (JNDI), inklusive der Integration mit OSGi Services
  • Gemini Management stellt ein Standard JMX Interface für die Verwaltung des Kern-OSGi-Frameworks bereit.

Alle Subprojekte können wie gesagt unabhängig voneinander genutzt werden, was bereits durch den Praxis-Einsatz bewiesen ist: Tatsächlich verwenden viele unserer Anwender nur ein oder zwei der Subprojekte in ihren eigenen Projekten.

JAXenter: Sollte OSGi deiner Meinung nach als Modularisierungsstandard für JDK 8 eingesetzt werden?

Mike Keith: Java ist heute allgegenwärtig. Java wird auf der ganzen Welt genutzt und kommt in allen möglichen Plattformen und Systemen zum Einsatz – und das ist großartig. Andererseits bringt dieser große Einfluss Javas auch die Verantwortung mit sich, Entscheidungen bzgl. des JDK mit großer Sorgfalt und Voraussicht zu treffen. Ich glaube, dass alle Optionen für eine Modularisierung in Betracht gezogen und sorgfältig gegeneinander abgewägt werden sollten. Ich denke aber auch, dass OSGi dabei weit oben auf der Liste der möglichen Technologien stehen sollte.

Doch letztendlich wird es natürlich die Java Community sein, die darüber entscheidet, wie Modularität sich in Java weiterentwickelt, und dies wird auf die selbe Art und Weise geschehen, wie immer: durch den JCP. Ich bin zuversichtlich, dass OSGi einen signifikanten Beitrag zu diesem Prozess leisten wird, und dass das Endresultat Einflüsse sowohl von OSGi als auch von anderen relevanten Ansätzen und Systemen reflektieren wird.

JAXenter: Vielen Dank für dieses Gespräch!

Das komplette Interview mit Mike Keith gibt es im kommenden Eclipse Magazin 1.11 zu lesen. Nicht verpassen!

Mike Keith war Co-Lead der EJB 3.0 und JPA 1.0 Spezifikationen und Repräsentant Oracles in der Expertengruppe für die Java EE 5 Spezifikation. Er ist Co-Autor des ersten JPA Referenzbuches „Pro EJB 3: Java Persistence API“. Mike verfügt über mehr als 15 Jahre Berufserfahrung in Lehre, Forschung und Entwicklung von objektorientierten und verteilten Systemen, mit einer Spezialisierung auf Objekt-Persistenz. Er arbeitet derzeit als Architekt für Java-Persistenz-Strategien bei Oracle und repräsentiert Oracle in den Expertengruppen für JPA 2.0 (JSR 317) und Java EE 6 (JSR 316).
Kommentare

Schreibe einen Kommentar

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