OSGi R5: Was bieten die neuen Core- und Enterprise-Specs?

Hartmut Schlosser

Seit Kurzem sind die endgültigen Spezifikationen für die OSGi-Core-R5- und OSGi-Enterprise-5-Standards verfügbar. Schauen wir uns einmal an, welche Neuerungen die Specs zu bieten haben.

Im OSGi Core Release 5 ist ein neues Resource API enthalten, mit dem sich generische Capabilities- und Requirements-Interfaces bearbeiten lassen. Ebenfalls neu hinzugekommen ist die Klasse VersionRange, mit der sich eine Menge von Versions beschreiben lässt.

Länger fällt die Liste der Neuerungen bei der Enterprise-Spezifikation aus.

So zum Beispiel die Repository-Service-Spezifikation, die ein API für den generischen Zugriff auf Repositorys beschreibt, die auch Remote betrieben werden können. Artefakte können nicht nur anhand des Namens, der Version oder Gruppe geliefert werden, sondern auch über Capabilities. Wie OSGi-Spezialist David Bosschaert auf seinem Blog kommentiert, lässt sich so etwa ein Bundle explizit anfordern, das das Package javax.servlet Version 2.5 exportiert. Oder mann kann ein Bundle erhalten, das eine Declarative-Services-Implementierung in der Version 1.2 bietet, ohne den Namen des Bundles zu kennen. Das Repository arbeitet auch mit Nicht-OSGi-Ressourcen zusammen, auch selbst definierte Capabilities lassen sich nutzen. Die Referenzimplementierung dieses Features wird übrigens gerade im JBoss OSGi Projekt erarbeitet, in dem OSGi-Funktionalitäten für den JBoss Application Server entstehen.

Eine weitere Neuerung ist die Resolver-Service-Spezifikation, mit der auch andere Entitäten auf die im OSGi-Kontext bekannten Resolver zugreifen können. Die Referenzimplementierung ist hier im Apache-Felix-Projekt zu finden – laut Bosschaert schon in einem fortgeschrittenen Zustand.

Der neue Subsystems Service ermöglicht es, mehrere Bundles in einem Archiv zusammenzufassen. So lassen sich Gruppen von Bundles, die eine bestimmte Funktion erfüllen – David Bosschaert nennt als Beispiel die Remote Services aus dem CXF-DOSGi Project – in ein Untersystem ausgliedern, das dann als ganzes deployed werden kann (anstatt alle Bundles einzeln zu deployen). Apache Aries bietet hier die Referenzimplementierung.

Die ServiceLoader-Mediator-Spezifikation ermöglicht die Nutzung von java.lang.ServiceLoader in OSGi Frameworks – was in der Apache-Aries-Komponente SPI-Fly zu begutachten sein wird.

Die Common Namespaces Spezifikation legt drei neue Namespaces fest:

  • osgi.extender ermöglicht es einem Bundle anzuzeigen, dass es einen bestimmten Extender benötigt.
  • osgi.contract ermöglicht detaillierte Import-Package-Ausdrücke, beispielsweise um Packages zu importieren, die zusammen einen contract bilden. Ein Beispiel wäre, alle Packages zu liefern, die Teil der Servlet 3.0 Spezifikation sind.
  • osgi.service ermöglicht es auszudrücken, dass ein Bundle einen bestimmten Service benötigt oder einen solchen liefert.

Ebenfalls enthalten in OSGi Enterprise 5 sind aktualisierte Versionen der JMX Management Model Spezifikation und der Configuration Admin Spezifikation.

Spannende Neuerungen bieten die OSGi Enterprise 5 Specs – ausgereifte Neuerungen dazu, die über die letzten Monate hinweg verfeinert wurden und bereits dabei sind, in den diversen Referenzimplementierungen zu hartem Code zu werden.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

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