Ein Blick auf den kürzlich erschienenen Early Draft der Version 4.2

Nächste Spezifikation: Quo Vadis OSGi?

Heiko Seeberger

Kürzlich wurde der Entwurf zur Spezifikation von OSGi 4.2 vorgestellt. Bereits das Format unterscheidet sich von der aktuellen Version 4.1, denn der Early Draft besteht aus einer Aneinanderreihung von elf Designdokumenten (RFCs), die Änderungen oder Ergänzungen zu den bestehenden Spezifikationen bringen.

OSGi 4.2 im Überblick

Die Folgende acht RFCs adressieren den eigentlichen Kern von OSGi:

  • RFC 120: Security Enhancements
  • RFC 121: Bundle Tracker
  • RFC 125: Bundle License
  • RFC 126: Service Registry Hooks
  • RFC 128: Accessing Exit Values from Applications
  • RFC 129: Initial Provisioning Update
  • RFC 132: Command Line Interface and Launching
  • RFC 134: Declarative Services Update

Diese drei RFCs zielen speziell auf Enterprise-Szenarien ab:

  • RFC 98: Transactions in OSGi
  • RFC 119: Distributed OSGi
  • RFC 124: A Component Model for OSGi

Was alles neu ist: die Details

RFC 120 erweitert den Conditional Permission Admin Service um Blacklists, also die Möglichkeit, Permissions nicht zu erlauben, sondern zu verbieten. Als Anwendungsfall wird mit Blick auf den Enterprise-Einsatz zwischen System- und Anwendungscode unterschieden. Mit der geplanten Erweiterung wird es z.B. einfach möglich sein, zu verhindern, dass Anwendungscode bestimmte Systemservices verwendet.

Der Bundle Tracker aus RFC 121 dient zur einfachen und standardisierten Umsetzung des Extender Patterns, bei dem der Status von Bundles beobachtet wird. Der RCF zielt auf hohe Homogenität mit dem bereits existierenden Service Tracker ab, sowohl hinsichtlich des API als auch in Hinblick auf die Implementierung durch eine gemeinsame Superklasse.


RFC 125
greift das immens wichtige Lizenzthema auf und beschreibt, wie Bundles in maschinenlesbarer Form lizenzbezogene Informationen bereitstellen können. Dazu wird der neue Manifest Header Bundle-License eingeführt. Damit wird es unter anderem möglich sein, mehrere Lizenzen zu referenzieren, unterschiedliche Bereiche des Bundles zu adressieren, auf URLs für die Lizenzen zu verlinken etc.

Die Service Registry Hooks aus RFC 126 dienen zur Beobachtung und Manipulation gewisser Operationen des Service Layers. Sie sind in erster Linie für speziellen Systemcode gedacht, z.B. für die Distributionssoftware aus dem RFC 119.

Mit RFC 128 wird das ApplicationHandle des Application Admin Service um eine Methode erweitert, die einen Ausgangswert zurückgibt. Damit bieten OSGi Applications in diesem Punkt dieselben Möglichkeiten wie Eclipse Applications heute schon.

Das Update des Initial Provisioning aus RFC 129 ermöglicht eine bessere bzw. flexiblere Tool-Unterstützung, insbesondere für Build-Tools. Anstelle des bisherigen Verfahrens kann der MIME Type von Einträgen für das Provisioning Dictionary nun durch den neuen Manifest Header InitialProvisioning-Entries spezifiziert werden.

Der recht umfangreiche und detaillierte RFC 132 zielt darauf ab, das Starten des OSGi-Frameworks sowie das Management mittels einer interaktiven Shell zu standardisieren. Abgesehen von proprietären Erweiterungen sollte damit ein Plattformwechsel deutlich leichter werden.


RFC 134
bringt schließlich als achter und letzter in Bezug auf den OSGi-Kern ein „kleines“ Update für Declarative Services [7] in Form einiger Bugfixes.

Insgesamt entspricht der Umfang der Änderungen und Ergänzungen dieser Kern-RFCs dem, was man sich von einem Minor-Versionsschritt von 4.1 auf 4.2 erwartet: Feinschliff und Stärkung der Flanken, aber nichts Bahnbrechendes im Kern. Ganz anders ist es bei den folgenden drei Enterprise-RFCs, die für OSGi das Tor zum Enterprise-Einsatz ganz weit aufstoßen sollen.

Transaktionen sind ein wesentlicher Bestandteil zahlreicher Enterprise-Systeme. Bisher in der OSGi-Welt undefiniert, legt RFC 98 bewährte Transaktionsstandards wie JTA und XA für OSGi fest. Darüber hinaus wird spezifiziert, wie diese als Services verfügbar und somit für OSGi-Systeme verwendbar gemacht werden.

Bisher drehte sich OSGi nur um die lokale JVM. RFC 119 durchbricht diese Grenze nicht nur hin zu entfernten OSGi-Plattformen, sondern ermöglicht sogar das Zusammenwirken von OSGi und „anderen“ Systemen. Dazu werden Konzepte wie Distributionssoftware und Discovery Service spezifiziert, die hinsichtlich Format, Transport und Transparenz sehr viel Flexibilität lassen. Die Spezifikation wirkt sehr ambitioniert und weckt Assoziationen zu Enterprise SOA.

Zu guter Letzt bringt RFC 124 Spring Dynamic Modules einschließlich Dependency Injection in leicht abgewandelter Form ins Spiel. Dies wirft natürlich die Frage auf, was mit OSGi Declarative Services passiert? Werden wirklich zwei deklarative Komponentenmodelle benötigt?

Schlussbemerkung

Dieser Early Draft deutet mit seinem Umfang, seinen vielen Detailverbesserungen und der klaren Ausrichtung auf den Enterprise-Einsatz auf einen sehr großen Schritt hin, viel größer als der Versionsschritt vermuten lässt. Wir dürfen sehr gespannt sein, was die kommenden Monate und letztendlich der Final-Release bringen werden.

Geschrieben von
Heiko Seeberger
Kommentare

Schreibe einen Kommentar

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