Hot-Plugging mit Eclipse RCP und OSGi

Bei dieser Vorgehensweise wird einem Dienstkonsumenten der entsprechende Dienst erst dann übergeben, wenn dieser in der Dienstregistratur gefunden werden kann. Hierfür existieren zwei mögliche Szenarien. Entweder der Dienst ist bereits in der Dienstregistratur vorhanden und kann sofort zurückgegeben werden, oder er wird zu einem späteren Zeitpunkt registriert und anschließend der Methode addingService übergeben. Wird ein Dienst beendet, können die entsprechenden Konsumenten mithilfe der Methode removedService darüber benachrichtigt werden. Welche sinnvollen Maßnahmen die Konsumenten daraufhin ergreifen sollten, ist stark von der jeweiligen Domäne abhängig und kann nicht generell beantwortet werden. Das obige Beispiel zeigt ebenfalls eine Möglichkeit, OSGi-Dienste an Objekte zu übergeben, ohne ihren Code mit einer Technologie zu „verschmutzen“. Dies erleichtert u. a. das Testen sowie die Wiederverwendbarkeit der Objekte außerhalb der OSGi-Umgebung.

In einigen Fällen sind Dienste bei der Erfüllung ihrer Aufgaben auf die Hilfe anderer Dienste angewiesen. Dabei können durchaus komplexe, baumähnliche Abhängigkeiten entstehen, bei denen Dienste gleichzeitig als Dienstproduzent und -konsument auftreten können. Benötigt ein Dienst A zur fehlerfreien Ausführung einen Dienst B, kommt zusätzliche Komplexität ins Spiel, falls der Dienst B beendet wird: Was passiert in diesem Fall mit Dienst A? Die möglichen Konsequenzen für den Dienst A ergeben sich aus der Relevanz des Dienstes B. Ist dieser für die fehlerfreie Ausführung von A unverzichtbar, so muss auch der Dienst A eingestellt werden. In komplexen Baumstrukturen kann das Propagieren einer Dienstunterbrechung einen Schneeballeffekt auslösen und durchaus kompliziert werden. Diese Komplexität wird noch durch die Aspekte der Nebenläufigkeit erhöht, denn OSGi ist prinzipiell hochgradig nebenläufig. Wird ein Dienst gestoppt und müssen dadurch andere Dienste ihre Funktionalität ebenfalls einstellen, müssen alle dafür notwendigen Schritte synchronisiert werden. Wie komplex die Handhabung von nebenläufigen Ereignissen bei OSGi-Diensten werden kann, beschreibt Neil Barlett ausführlich in seinem Buch [8].

Um die Komplexität bei dynamischen OSGi-Diensten zu reduzieren, führte Eclipse mit der Version 3.3 deklarative Dienste (engl. Declarative Services) ein. Mithilfe deklarativer Dienste kann die Bereitstellung von Diensten sowie Dienstabhängigkeiten in XML-Form beschrieben und die Behandlung der Dynamik vereinfacht werden. Deklarative Dienste übernehmen das Propagieren von Dienständerungen an die betroffenen Konsumenten und sorgen für die Konstruktion sowie Auflösung von Dienstabhängigkeiten. Hierfür können Dienstkonsumenten bind– und unbind-Methoden angeben sowie optionale sowie obligatorische Dienstabhängigkeiten definieren. Listing 4 zeigt ein Beispiel, in dem eine Klasse gleichzeitig als Dienstproduzent und Dienstkonsument auftritt.

Listing 4: Deklarative Bereitstellung und Beschaffung von OSG-Diensten

Neben den deklarativen Diensten existieren mit Spring Dynamic Modules [9], Apache Felix und Apache Dependency Manager [2] alternative Ansätze, die sich einem ähnlichen Ziel verschrieben haben. Obwohl mit der Einführung deklarativer Dienste der Umgang mit dynamischen Diensten vereinfacht wird, müssen dennoch einige Tücken beachtet werden. Hierzu gehören beispielsweise der korrekte Umgang mit Ressourcen, wenn Plug-ins gestoppt und (wieder) gestartet werden, sowie Netzwerk- und Datenbankverbindungen, die korrekte An- und Abmeldung von Beobachtern etc.

Kommentare

Schreibe einen Kommentar

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