OSGi - Java Komponenten - page 151

Neu ist jetzt das Element <reference>. Darin wird durch das Attribut interface angegeben,
welchen Dienst die Komponente nutzen möchte. Durch die Attribute bind und unbind werden
die Methoden spezifi ziert, die automatisch aufgerufen werden, wenn der Dienst verfügbar
wird bzw. nicht mehr verfügbar ist. Diese brauchen einen Parameter vom Typ des zu nutzen-
den Dienstes. Dadurch haben wir übrigens dieselbe Funktionalität des Clients wie in
Abschnitt 9.5 durch Implementierung der ServiceListener-Schnittstelle: Es ist gleichgültig, in
welcher Reihenfolge die Service- und Client-Komponenten installiert und gestartet werden.
Sobald beide vorhanden sind, läu der Thread los. Auch auf eine Aktualisierung der Service-
Komponente reagiert der Client und benutzt sofort die neue Version der Klasse CounterImpl.
Statt einer XML-Datei kann man die für die Declarative Services benötigten Angaben auch
durch Annotationen machen (z. B. @Component für Klassen, @Activate, @Deactivate und
@Reference für Methoden). Die Annotationen haben allerdings als RetentionPolicy den
Wert CLASS (vgl. Kapitel 3). Damit sind sie zur Laufzeit nicht mehr verfügbar. Die Annota-
tionen sind dafür gedacht, dass man vor der Installation mit einem So ware-Werkzeug aus
den Annotationen die entsprechenden XML-Dateien erzeugt.
9 .8 .2 Zusätzliche Erweiterungen
Es gibt weitere Komponenten, die die Grundfunktionalität von OSGi erweitern. Dazu gehö-
ren u. a.:
! Gogo: Dies ist eine Komponente, die wir bisher schon benutzt haben. Sie liefert die Mög-
lichkeit, mit Hilfe von Kommandos wie install und start Komponenten zu installieren und
zu starten. Eine solche Shell zur Eingabe von Kommandozeilen gehört nicht zum Kern
des OSGi-Frameworks. Dass man eine solche scheinbar grundlegende Funktionalität
quasi als Anwendungskomponente realisieren kann, wird möglich, weil OSGi eine Pro-
grammierschnittstelle zum Installieren und Starten von Komponenten bietet. Davon
macht Gogo (wie übrigens auch Declarative Services, File Install und iPOJO [s. u.])
Gebrauch. Dies ist ein schönes Beispiel dafür, wie man mit einem kleinen, aber funktional
gut ausgestatteten Kern weitere zusätzliche nützliche Funktionen realisieren kann, die
aber bereits die Form von Anwendungen haben und nicht zum Kern gehören.
! File Install: Mit dieser Komponente wird es möglich, Bundle-Dateien in einem Verzeichnis
abzulegen. Die Komponente „File Install“ sieht von Zeit zu Zeit nach, ob es neue Bundles
gibt. Wenn ja, dann werden diese installiert, ohne dass man ein entsprechendes Kom-
mando eintippen muss. Entsprechend werden Komponenten deinstalliert oder aktuali-
siert, wenn die Datei verschwunden ist oder erneuert wurde. Diese Funktionalität haben
wir in der prototypischen Realisierung eines Komponenten-Frameworks in Kapitel 6 schon
gesehen. Dort war sie Teil des Frameworks. Hier ist die Lösung wesentlich schöner, da
auch diese Komponente wie Gogo eine Anwendung eines sehr kleinen Framework-Kerns
ist, somit nur bei Bedarf installiert werden muss und beliebig ausgewechselt werden kann.
! iPOJO: Einen sehr ähnlichen Ansatz wie Declarative Services verfolgt iPOJO. Mit iPOJO
lässt sich ebenfalls deklarativ über eine XML-Datei spezifi zieren, welche Dienste eine
Komponente anbietet und nutzt. Auch für iPOJO gibt es Annotationen, die ebenfalls nicht
zur Laufzeit auswertbar sind, sondern für Tools gedacht sind, die vor der Installation
XML-Dateien aus den Annotationen generieren.