Modulare Enterprise-OSGi-Anwendungen mit Eclipse Gemini

Services konsumieren

Konsumierte Services werden in der Blueprint-Konfiguration durch das Element reference definiert. Davon gibt es zwei Varianten. Die erste ist die Referenz auf einen Service, die zweite die Referenz auf eine Liste von Services. Für beide Varianten kann die Auswahl der in Frage kommenden Services über Filter eingeschränkt werden. Listing 5 zeigt beide Varianten. Für jede Servicereferenz kann ein Timeout (in Millisekunden) angegeben werden. So sorgt die Angabe timeout=“60000″ dafür, dass maximal eine Minute auf den referenzierten Service gewartet wird. Ist das nicht der Fall, wird eine ServiceUnavailableException geworfen.

Listing 5
// Reference single service

   
// Reference multiple services
Blueprint für Fortgeschrittene

In den vorherigen Abschnitten konnten wir gerade einmal die wichtigsten Funktionen der Blueprint-Spezifikation vorstellen. Was auf der Strecke bleiben musste, wird in diesem Abschnitt erwähnt.

Dynamisches (Un-)Binding von Services:

OSGi Services sind dynamisch. Zur Laufzeit können neue Services hinzukommen, entfallen oder sich ändern. Die Blueprint-Spezifikation bietet eine Vielzahl von Konfigurationsmöglichkeiten, um diese Dynamik zu behandeln.

Integration mit dem Config Admin Service:

Der Config Admin Service ist der Standardmechanismus von OSGi, um Konfigurationseinstellungen zu verwalten. Diese Einstellungen können in der Blueprint-Konfiguration verwendet werden. Auch Managed Properties und Managed Service Factories können mit Blueprint kombiniert werden.

Gemini Blueprint und Spring

Die Nähe von Gemini Blueprint und Spring ist offensichtlich. Damit die Blueprint-Konfiguration einfach erweiterbar bleibt, können mehrere XML Namespaces in einer Konfiguration miteinander kombiniert werden, wie in Spring. Ein Beispiel zeigt Listing 6. Zur Deklaration der Konstante thread-priority wird der Namespace http://www.springframework.org/schema/util verwendet. Dazu kommt noch ein Task Executor aus dem Namespace http://www.springframework.org/schema/task. Die Gemini-Blueprint-Konfiguration kann wie eine normale Spring-Konfiguration verwendet werden. Das senkt die Einstiegshürde für Spring-Projekte, die den Schritt in die OSGi-Welt machen wollen, gewaltig. Für OSGi-Projekte hat das den Vorteil, dass Teile der Konfiguration auch außerhalb des OSGi-Containers weiterverwendbar sind.

Listing 6
Testen der Blueprint Services

Auch zum Testen unserer Enterprise-Anwendung brauchen wir eine Implementierung der Interfaces, gegen die wir programmiert haben. Hierzu ist auch im OSGi-Enterprise-Standard nichts zu finden. Zwei Varianten stehen uns zur Auswahl:

Variante 1: Mock-Objekte:

In den Tests können wir Mock-Objekte verwenden. Dazu erzeugen wir Mock-Objekte der Interfaces, die wir benötigen, zum Beispiel mit Mockito [3]. Mit diesen Mocks initialisieren wir den Teil der Anwendung, die wir testen. Den Mocks kann beliebiges Verhalten eingehaucht werden. Insbesondere Interaktion mit einem anderen Service oder auch Fehlerszenarien lassen sich so gut und isoliert testen.

Variante 2: Spring Unit Tests:

Auch mit Spring Unit Test können wir unsere Enterprise-Anwendung testen. Dabei handelt es sich um JUnit Tests mit Dependency Injection über Spring. Speziell für den Test wird eine XML-Konfiguration für Spring erstellt. Dort können wir für den Test andere Implementierungen der benötigten Interfaces verwenden. Spring kümmert sich um die Initialisierung der Objekte, das heißt, es ist kein Code zur Initialisierung des Tests nötig. Interessant sind Spring Unit Tests insbesondere dann, wenn Services benötigt werden, für die Spring bereits einfache Implementierungen für Tests anbietet. Auf diese Weise könnten wir beispielsweise im Test eine In-Memory-Datenbank als Datenquelle verwenden. Das geschieht im Test CustomerRepositoryImplTest unseres Beispielprojekts.

Kommentare

Schreibe einen Kommentar

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