OSGi Lite: Der Durchbruch für modulare Enterprise-Anwendungen?

Hartmut Schlosser

Das ist bisher das vielleicht beste Argument für den breitflächigen Einsatz des OSGi-Standards in Enterprise-Anwendungen – so beschreibt OSGi-Evangelist Peter Kriens eine vereinfachte OSGi-Implementierung, die unter dem Namen „OSGi Lite“ von Karl Pauls vorgelegt wurde.

Um in den Genuss der Vorteile von OSGi zu kommen – unabhängige, wieder verwendbare Module statt schwergewichtiger Anwendungstorsos voller interner Abhängigkeiten -, waren bisher tief greifende Refaktorisierungen einer existierenden Codebasis notwendig. Ob sich aufgrund dieser Komplexität der Umstieg auf OSGi überhaupt lohne, wird seit Monaten kontrovers in den Blogs diskutiert.

OSGi Lite soll dieses Problem nun entschärfen und einen weichen Übergang zu „mehr“ Modularität ermöglichen. Peter Kriens beschreibt das Problem vieler Java-Anwendungen, in denen der Klassenlader-Mechanismus angepasst wurde, mit dem Ergebnis, dass bestimmte Implementierungs-Klassen über Modulgrenzen hinweg sichtbar bleiben müssen. Ein System unabhängiger Module wird so unmöglich, weshalb bei einer Umstellung auf OSGi all diese „Class Loader Hacks“ in einem komplizierten Prozess entfernt werden müssen.

Die Idee, den Einstieg in OSGi mittels einer „OSGi Lite“ Version zu erleichtern, war bei der OSGi-Alliance deshalb mehrfach diskutiert worden, ohne zu konkreten Ergebnissen zu führen. OSGi-Entwickler Karl Pauls hat nun jenseits dieser Diskussionen die Initiative ergriffen und kurzerhand eine Umsetzung dieser Vision vorgelegt: OSGi Lite, eine OSGi-Version ohne den Module Layer auf Basis von Apache Felix.

Ein OSGi ohne Module Layer sei deshalb interessant, so Kriens, weil es die Migration auf den Service Layer vereinfache. Und die Idee der Services stellt für Kriens die wichtigste Innovation bei OSGi dar – der Module Layer sei lediglich ein Mittel zum Zweck, die Service-Schicht zum Laufen zu bringen.

Nach ersten Versuchen mit OSGi Lite stellt Kriens fest, dass viele Bundles wie Declarative Services und die Shell bereits Out-of-the-Box funktionieren. Für beinahe beliebige Java-Anwendungen ständen ohne große Aufwände 80 Prozent der Mächtigkeit von OSGi zur Verfügung.

OSGi Lite löst zwar nicht das Problem der „Class Loader Hacks“, umgeht es aber, indem es den Class Loader ignoriert. Alle Class Loader Hacks liefen zwar weiter, was einer „echten“ Modularisierung im Weg stehe. Dennoch könne mittels OSGi Lite schnell auf das µservice-Modell gewechselt werden, mit dessen Hilfe nach und nach auch das Problem der Class Loader Hacks gelöst werden könne. Und nach diesem Schritt sei eine Migration auf den vollen OSGi-Standard eine leichte Übung.

Kriens schlägt vor, OSGi Lite anhand der vorliegenden Implementierung zu standardisieren und damit offiziell abzusegnen. Damit wäre OSGi Lite auch in anderen Implementierungsvarianten denkbar.

Gehört damit das OSGi-Gegenargument „Komplexität“ der Vergangenheit an? Interessant wird zu beobachten sein, wie sich die Erkenntnisse einer OSGi-Lite-Version auf die Modularisierungsanstrengungen für das JDK8 auswirken. Der OSGi-Standard war bei Sun aufgrund seiner vermeintlichen Komplexität stets kritisch betrachtet worden (man erinnere sich an Goslings Kommentar: „OSGi´s just too much fat„).

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

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