Die OSGi Alliance (früher Open-Services-Gateway-Initiative) spezifiziert eine dynamische Softwareplattform [1], die es ermöglicht, Applikationen und dazugehörige Dienste per Komponentenmodell zu modularisieren und zu verwalten. Seit Version 3.0 ist OSGi das Eclipse zugrunde liegende Modell, das unter dem Namen Equinox als eigenständiges Eclipse-Projekt weiterentwickelt wird. Im Jahr 2003 sollte Eclipse auf eine Plug-in-Struktur umgestellt werden. Bis zu diesem Zeitpunkt gab es innerhalb von Eclipse keine standardisierten Komponenten und das Laden oder das Entfernen von Komponenten erforderte einen Neustart. Darüber hinaus war die statische Abhängigkeit der Module untereinander ein Problem. Um diese Mängel zu beheben, hat sich die Eclipse Foundation dafür entschieden, die OSGi-Plattform zu verwenden. Equinox implementiert die OSGi-Kernspezifikation. Zusätzlich zu den von der OSGi spezifizierten Anforderungen setzt Equinox verschiedene zusätzliche Features, z.B. die Extension Registry, um. Neben Eclipse setzen auch noch andere Applikationen auf Equinox auf (z.B. IBM Workplace).
OSGi Alliance
Die OSGi Alliance wurde 1999 gegründet. Ihr gehören Unternehmen aus den unterschiedlichsten Branchen an (z.B. Sun Microsystems, Nokia, Siemens, Red Hat, Eclipse Foundation, Deutsche Telekom, Motorola). Geleitet wird die OSGi Alliance von einem Direktorium, das sich aus den Vorständen des jeweiligen Arbeitsgebiets zusammensetzt. Technische Fragen – so auch die Weiterentwicklung der Spezifikationen – werden in diversen Arbeitsgruppen behandelt. Die aktuellen Spezifikationen stehen auf der OSGi-Website zur Verfügung [1]. Aktuell ist das Release 4 in der Version 4.1 [2]. Die OSGi spezifiziert lediglich die API und die Testfälle für Implementierungen und stellt in diesem Zusammenhang auch eine Referenzimplementierung zur Verfügung, die jedoch nicht für den Produktiveinsatz, sondern lediglich als Vorlage gedacht ist. Neben Equinox gibt es noch einige andere freie und auch kommerzielle Umsetzungen der Spezifikation, beispielsweise Knopflerfish. Ein interessantes und auch hinter die Kulissen schauendes Blog, von einem der OSGi-Verantwortlichen geschrieben, findet sich unter www.osgi.org/blog/ [3].
Die OSGi-Spezifikationen
Das OSGi Framework besteht aus einer Reihe von Schichten, die aufeinander aufbauen. Sie erweitern das durch Java und die entsprechende JVM vorgegebene Modell durch Konstrukte, die nicht nur die oben genannten Einschränkungen lösen, sondern die Funktionalität nochmals deutlich erweitern. Abbildung 1 zeigt die Bestandteile der OSGi-Architektur.
Folgende Schichten sind dabei relevant:
- Execution Environment: Die Ausführungsumgebung ist so spezifiziert, dass sie auf unterschiedlichen Java-Plattformen lauffähig ist. Statt eine konkrete Java-Version zu referenzieren, wird mit einer Execution Environment ein Repräsentant einer Laufzeitumgebung definiert, die festlegt, welche Klassen, Interfaces und Methoden vorhanden sein müssen.
- Module Layer: Die unterste logische Schicht des OSGi Frameworks definiert ein Bundle (Plug-in) als kleinste Einheit. Ein Bundle kann eigenständig im Framework installiert und genutzt werden und besteht aus Java-Klassen und den benötigten Ressourcen. Die enthaltene Datei MANIFEST.MF wird um eine Anzahl von Metadaten angereichert, die explizit die Abhängigkeiten und angebotenen Pakete auflisten. Exemplarisch ist der Inhalt eines Bundle-Manifests in Listing 1 dargestellt. Eine spezielle Eigenschaft des OSGi Frameworks ist die Möglichkeit, Abhängigkeiten zwischen verschiedenen Bundles explizit verwalten zu können. Die Klassen eines Bundles sind zunächst nicht für andere Bundles sichtbar. Um diese in anderen Bundles nutzen zu können, muss das implementierende Bundle diese Klassen zuerst über die Manifest-Datei exportieren.
- Life Cycle Layer: Während in der Modulschicht in erster Linie statische Aspekte eines Moduls thematisiert werden, stehen in der Lebenszyklusschicht die dynamischen Aspekte im Vordergrund. In Abbildung 2 werden die Zustände eines Bundles dargestellt. Die Bundle-Zustände werden dabei von einem Managementagenten geändert, der ein Interface zum OSGi Framework implementiert, über die das Framework von außen gesteuert werden kann.
- Service Registry: Die Service Registry dient dazu, Bundles im OSGi Framework zu registrieren, sodass diese Bundles genutzt werden können. Ein Service ist ein simples Java-Objekt, das in einer zentralen Registratur unter seinem Interfacenamen angemeldet wird. Dort kann es von anderen Bundles abgefragt und genutzt werden. Die Registratur existiert nur während der Laufzeit, ist also nicht persistent. Selbst während der Laufzeit muss man damit rechnen, dass Services an- und abgemeldet werden, bzw. nicht mehr zur Verfügung stehen. Um das Arbeiten mit diesen dynamischen Services zu erleichtern, sind in der OSGi-Spezifikation drei Mechanismen beschrieben, um auf entsprechende Änderungen zu reagieren: der Service Listener, der Service Tracker und der Declarative Service.
- Standardservices: Das OSGi Framework definiert eine Reihe von Standardservices, die Lösungen für unterschiedliche Probleme implementieren und in anderen Bundles genutzt werden können. Zu diesen Standardservices gehört z.B. der http-Service, der einen einfachen Webserver spezifiziert, an dem Bundles Ressourcen anmelden können, die über das http-Protokoll ansprechbar sind.
- Security Layer: Mit den Mechanismen dieser Schicht lassen sich die Ausführungsrechte einzelner Bundles gezielt einschränken. Diese Schicht basiert auf dem Java-Sicherheitsmodell, das mit dem JDK 1.2 eingeführt wurde, erweitert diese jedoch, sodass den OSGi-spezifischen Anforderungen Genüge getan wird.
Listing 1
Manifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Name: MyFirstBundleBundle-SymbolicName: myFirstBundleBundle-Version: 1.2.3
