Babyleichtes OSGi: Peter Kriens stellt neues OSGi Application Framework vor

Hartmut Schlosser

Als Best Practice hat sich in der Softwareentwicklung etabliert, eine Anwendung in mehrere, möglichst selbständige Einheiten aufzugliedern, die über Schnittstellen miteinander kommunizieren. In der Java-Welt ist man diesem Gedanken weit gefolgt, als Idealfall strebt man nach lose gekoppelten Systemen mit Modulen oder Services, die sich je nach Bedarf dynamisch hinzuladen lassen. Neben der Modularisierung von Java-Anwendungen könnte auch das JDK selbst modular aufgebaut sein, damit Entwickler Plattformkomponenten dem jeweiligen Anwendungsfall gemäß frei zusammenstellen könnten. Das Projekt Jigsaw hat sich diesem Problem angenommen, ohne jedoch bisher zu einem allseits akzeptierten Ergebnis zu kommen (siehe „Kein Modulsystem in Java 8“ und „Projekt Jigsaw: Oracle startet neuen Versuch„).

Seit über 10 Jahren indes schon erfolgreich in Industrieprojekten eingesetzt wird der OSGi-Standard mit seinem Service-Loader-Modell. Die OSGi-Gemeinde wirbt seit Jahren schon dafür, auf ihrem Standard aufbauend auch das offizielle JDK-Modulsystem zu entwerfen. Dass genau dies nicht passiert, hat zum einen wohl politische Gründe – zumindest Sun schien der OSGi Alliance nicht besonders zugetan zu sein (James Gosling kommentierte 2009 „OSGi´s just too much fat„, Peter Kriens warf Jigsaw daraufhin Simplizismus vor.) Zum anderen gilt OSGi aber auch als komplex und erfordert ein gewisses Maß an Einarbeitung, sodass die Argumentation, man wolle die Programmierung mit Java nicht verkomplizieren, nicht ganz von der Hand zu weisen ist.

Statt die Komplexität von OSGi schlicht zu negieren (wie früher oft geschehen) ist die OSGi Alliance mittlerweile dazu übergegangen, Einstiegshilfen zu suchen. OSGi-Gründer Peter Kriens selbst arbeitet derzeit an einem neuen OSGi Application Framework, das dem Entwickler  – gewissermaßen als Starter-Kit – komplexe und fehleranfällige Arbeiten abnimmt. Als erster Markstein für dieses Framework wurde jetzt ein offizieller Request for Proposal (RFP) zugänglich gemacht – Codename: „Babysteps“.

Schon in der Einleitung zum Babysteps RFP ist ein kleiner Seitenhieb auf Jigsaw auszumachen. Hier wird das JDK-Modul-System als einer der Gründe aufgeführt, warum OSGi  keinen allgemeinen Durchbruch erlebt hat:

After 15 years of focusing on specifications, the OSGi Alliance has an impressive array of a core framework and component specifications. These specifications have found traction in high end products like embedded, application servers and by many early adopters. However, OSGi never took off as one could have expected looking at the breadth of the technology and its corporate backers. Part of the hesitancy was caused by the threat of another module system in Java 7, which is fortunately gone now for the foreseeable future (moved after Java 8), but it is clear that mainstream adoption has been laggard so far.

Zum Glück bleibt das Proposal aber nicht bei Sticheleien stehen und nennt als weiteren Hauptgrund für die zögerliche OSGi-Akzeptanz das Fehlen eines durchgängigen Beispiels, das als Design-Vorlage die Vorteile von OSGi exemplarisch vorführt. Als schlechte Beispiele werden übrigens Eclipse und diverse existierende OSGi JEE Server genannt, da sie versuchten, das „Quadrat durch ein rundes Loch“ zu quetschen – sprich, OSGi nicht wie intendiert nutzen.

Peter Kriens, dem Verfasser des RFPs, geht es um die Herausstellung des μservices-Modells als den eigentlichen Kern von OSGi. So soll das geplante Framework ganz auf μservices basieren, ein HTML5/JavaScript GUI besitzen und JSON-Pakete mit einem Server austauschen. REST Support über ein Service API, JPA als Persistenzschicht, Servlets Support, ein Security-Modell, Autorisierung/Authentifizierung und User Management werden als weitere Eigenschaften genannt.

Desweiteren soll eine Tool Chain entstehen, insbesondere ein Werkzeug zur Automatisierung der nötigen Schritte zur Erstellung eines OSGi-Projektes. Zuletzt soll mit Service-Unternehmen wie GitHub oder Cloudbees zusammengearbeitet werden, um eine Integrierte Umgebung bereitzustellen.

Auf seinem Blog bezeichnet Kriens dieses Programm als sehr ambitioniert. Bei seinen Arbeiten an dem OSGi-Repositorys jpm4j (Kriens hatte dafür 1.5 Jahre die OSGi Alliance verlassen) sei ihm die Wichtigkeit des  kompromisslosen µservice-Ansatzes bewusst geworden, der bisher nicht wirklich zum Tragen gekommen sei. Wir dürfen also damit rechnen, dass viele für jpm4j entwickelte Komponenten sich auch im OSGi Application Framework wiederfinden werden. Geplant sind zudem zahlreiche Dokumentationsmaterialien, die die OSGi Best Practices besser demonstrieren sollen als bisher.  

Inwieweit OSGi durch „Babysteps“ nochmals einen Popularitätsschub erhält, bleibt abzuwarten. Die Initiative kommt zwar etwas spät – angesichts der Verzögerungen beim Jigsaw-Projekt aber vielleicht gerade noch rechtzeitig, um Wirkung zu erzielen.  

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare
  1. Susan_Schwarze2013-09-17 09:35:19

    Um mehr über die Arbeiten zum OSGi Application Framework und auch andere OSGi relevante Themen zu erfahren, inclusive Berichte über kommerzielle Projekte und Produktlösungen, Best Practices und Tutorials, besuchen Sie uns bitte vom 29. bis 31.Oktober auf dem OSGi Community Event in Ludwigsburg. Mehr Informationen erhalten Sie hierzu unter http://www.osgi.org/CommunityEvent2013/HomePage

Schreibe einen Kommentar

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