Das OSGi Framework

Artikel

April 2009 | Artikel

Das OSGi Framework Fortsetzung, Teil 2

Teil 1 Teil 2

Abhängigkeiten zwischen Bundles

Ein einzelnes Plug-in zu entwickeln, ist relativ einfach; die Komplexität kommt dann ins Spiel, wenn ein Plug-in zu groß wird und es in verschiedene Komponenten aufgeteilt werden muss. In diesem Fall muss ein Bundle auf die Klassen und Ressourcen eines anderen Bundles zugreifen können. Im Rahmen des OSGi Frameworks wird dies durch das Im- und Exportieren von Packages erreicht, somit spricht man hier auch von Package-Abhängigkeiten. Als Basis für das explizite Im- und Exportieren dient der Java-Class-Loading-Mechanismus, der es ermöglicht, die einzelnen Bundles voneinander zu isolieren, indem er die sichere Zuführung von Klasseninformationen zur JVM steuert.

Damit die Klassen eines Bundles auch für andere Bundles nutzbar bzw. überhaupt sichtbar sind, müssen diese explizit exportiert werden. Das Exportieren passiert im OSGi Framework auf Package-Ebene. Dabei wird die Datei MANIFEST.MF um folgenden Eintrag erweitert: Export-Package: org.bla.myPackage. Mit dieser Anweisung können andere Plug-ins das Package myPackage entsprechend importieren und nutzen. Praktischerweise kann man Bundles und die von ihnen exportierten Packages versionieren. Auf diese Weise lässt sich die Abhängigkeit noch weiter verfeinern, indem man nämlich beim Importieren eines Packages bereits angeben kann, welche Versionsnummer gefordert ist. Eine Versionsnummer setzt sich aus maximal vier, durch einen Punkt getrennte Stellen zusammen, wobei die ersten drei numerisch (major, minor, micro) und die letzte (qualifier) auch ein String sein darf. Die Manifest-Datei dient wiederum dazu, das Bundle mit einer entsprechenden Versionsnummer zu versehen. In Listing 1 hat das Bundle die Versionsnummer 1.2.3. Da ein Bundle sowohl über die Versionsnummer als auch über den symbolischen Namen im System identifiziert wird, kann man in einem System durchaus verschiedene Versionen eines Bundles nutzen.

Bei der Spezifikation der Bundle-Abhängigkeiten kann man einen Versionsbereich festlegen, aus dem ein Package kommen muss. Ein Versionsbereich setzt sich dabei aus einem Minimal- und einem Maximalwert zusammen, wobei man runde und eckige Klammern nutzen kann, um ein „größer“ bzw. ein „größer-oder-gleich“ und umgekehrt auszudrücken. Beispiele für mögliche Wertebereiche zeigt Tabelle 1.

Tabelle 1: Beispiele für Abhängigkeiten mit Versionsbereichen

Der Eintrag Import-Package: myPackage; version=“[1.1.0,1.3.0)“ in der Manifest-Datei bewirkt also, dass das Package myPackage nur in der Version größer oder gleich 1.1.0 und kleiner als 1.3.0 ist.

Nutzung von dynamischen Services

Die OSGi Service Registry dient dazu, dass Bundles an dieser zentralen Stelle angemeldet werden können, um ihre Dienste anzubieten. Andere Bundles dagegen können diese Registry nutzen, um nach erforderlichen Diensten zu suchen. Bundles können zu diesem Zweck Properties und Filter verwenden, mit denen Services detailliert beschrieben oder auch gesucht werden können.

Beim Arbeiten mit Services sind folgende Schritte notwendig:

Service registrieren: Bundle muss in Service Registry angemeldet warden.
Service abfragen: Registrierte Bundles können über Properties gesucht werden.
Service verwenden: Direkter Zugriff auf die vom Bundle bereitgestellten Funktionen.
Service freigeben: Nach Nutzung muss das Bundle den Service wieder freigeben.
Service deregistrieren: Bundle soll seinen Service dem System nicht mehr zur Verfügung stellen.

Somit ist es also möglich, dass zu einem beliebigen Zeitpunkt ein Service registriert bzw. deregistriert wird. Das OSGi Framework muss deshalb Mechanismen bereitstellen, die es ermöglichen, während der Laufzeit auf Änderungen der Service Registry oder der angemeldeten Services zu reagieren. Im Kern basieren diese Mechanismen auf dem Konzept des Service Listeners. Dieses Konzept wird sowohl im Service Tracker (unterstützt programmatischen Umgang mit dynamischen Services) als auch im Declarative Service (Serviceabhängigkeiten werden in deklarativer Form beschrieben) umgesetzt. Da der Einsatz von Service Listenern recht fehleranfällig werden kann (Nebenläufigkeitsprobleme), wird von diesen abgeraten. Stattdessen sollten Mechanismen wie der Service Tracker verwendet werden, der eine deutlich einfachere Handhabung gewährleistet und selbst wiederum auf den Service Listenern basiert.

Über unterschiedliche Methoden können nach dem Erzeugen eines Service Trackers die beobachteten Services und Servicereferenzen abgefragt werden. Der Service Tracker bietet darüber hinaus Mechanismen an, um auf Änderungen (Hinzufügen, Ändern, Entfernen) von Services unmittelbar zu reagieren. Eine andere Alternative ist der Einsatz des so genannten Whiteboard Patterns. Dieses ersetzt im OSGi Framework das traditionelle Listener Pattern. Es wird eingesetzt, wenn man innerhalb eines Bundles einen Event Listener an einen Service anmelden möchte, um bestimmte Events dieses Service zu empfangen. In diesem Pattern werden die Listener nicht über add()- und remove()-Methoden an der Event Source angemeldet, sondern als OSGi Services in der Service Registry angemeldet. An dieser Stelle können sie beim Feuern eines Events vom jeweiligen Service abgefragt werden.

Zusammenfassung und Ausblick

Das OSGi Framework ist hervorragend dazu geeignet, eigene Plug-ins modular aufzubauen. Die Werkzeuge, die zur Verfügung gestellt werden, sind ausgereift und stabil, wie man bereits bei der Arbeit mit Eclipse feststellen kann. Für eine tiefergehende Beschäftigung mit dem Thema OSGi und Equinox sei an dieser Stelle auf das hervorragende Buch von Wütherich, Hartmann, Kolb und Lübken verwiesen [4]. Aktuell ist die Version 4.2 der OSGi-Spezifikationen in Arbeit. In einem ersten Entwurf wurden dabei bereits die Marschrichtungen vorgegeben. Hier wird es vor allem Erweiterungen im Enterprise-Bereich geben. So soll der Transaktionsbereich – bisher in OSGi noch nicht spezifiziert – mit der Version 4.2 standardisiert werden. Man kann also gespannt sein, was die Zukunft im Bereich OSGi noch bringen wird.

Holger Funke arbeitet als Senior Consultant bei der HJP Consulting GmbH in Paderborn. Er leitet die Entwicklung des Eclipse-Plug-ins GlobalTester (www.globaltester.org), das zum Testen von Chipkarten dient. GlobalTester wird weltweit eingesetzt, um die Konformität von elektronischen Reisepässen zu gewährleisten. Daneben veröffentlicht er Artikel in Fachzeitungen und spricht auf internationalen Konferenzen.