Suche
Schnittstellen und Abhängigkeiten in OSGi-basierten Systemen

OSGi erwacht zum Leben

Stefan Reichert und Pascal Alich

Die Softwareplattform OSGi ist mit ihren Bundles und Services per se komponentenorientiert. Für darauf basierende Anwendungen stellt sich daher die Frage, wie die Komponenten geschnitten und deren Schnittstellen definiert werden sollen. Der erste Teil der Serie hat dazu drei verschiedene Abhängigkeitstypen erläutert. Im zweiten Teil wird eine OSGi-basierte Beispielanwendung erstellt, die dem theoretischen Wissen Leben einhaucht.

Anhand der Beispielanwendung „RCP Contacts Sample“ wollen wir die verschiedenen Abhängigkeitstypen verdeutlichen und zeigen, wie die Abhängigkeiten in OSGi technisch abgebildet werden können.

Inhaltlich geht es um eine minimale Kunden- bzw. Kontaktverwaltung. Die Domäne ist einfach erklärt: Ein Kunde, repräsentiert durch Kundennummer und Name, kann mehrere Kontaktpersonen haben, von denen einer der Hauptkontakt sein kann. Zu jedem Kontakt werden der Name, E-Mail-Adresse, Telefon und eine Postanschrift gespeichert (Abb. 1).

Eine clientseitige und erweiterbare Adressprüfung soll für höhere Datenqualität sorgen. Außerdem sollen für eine E-Mail-Adresse oder Telefonnummer Aktionen ausgelöst werden können, z. B. das Mailprogramm öffnen oder via Skype die Telefonnummer wählen.

Abb. 1: Vereinfachtes Domänenmodell der Kontaktverwaltung

Der interessierte Leser kann die Eclipse-Plug-in-Projekte aus dem Github-Repository [1] beziehen und in einem Eclipse Indigo (3.7) Workspace laufen lassen. Die enthaltenen Launch Configurations verbinden sich entweder mit einer lokalen Implementierung des Serveranteils oder einer in der Cloud laufenden Instanz. Zusätzlich steht ein exportiertes Eclipse Product zur Verfügung, um die Beispielapplikation direkt ausprobieren zu können. Eine ausführliche Anleitung befindet sich in der Readme-Datei im Repository.

Bundle-Übersicht

Der folgende Abschnitt beschreibt, aus welchen Bundles die Beispielanwendung besteht und welche Funktion diese jeweils haben (Abb. 2). Das Bundle com.zuehlke.contacts.ui enthält den Code zur Darstellung und Verwaltung der Oberfläche. Eine View zeigt Kunden und Kontakt hierarchisch an, während jeweils ein Editor zur Anzeige und zum Bearbeiten der Details dient.

Das UI-Bundle ist als „Erweiterbare Komponente“ konzipiert; es stellt zwei Schnittstellen für Erweiterungen zur Verfügung. Die beschriebenen Aktionen für E-Mail-Adressen und Telefonnummern haben wir Intents genannt. Die Bundles com.zuehlke.contacts.ui.intent.outlook und com.zuehlke.contacts.ui.intent.skype sind zwei mitgelieferte Beispiele. Die Adressprüfung com.zuehlke.contacts.ui.addresscheck.IAddressCheck ist ebenfalls auf zwei verschiedene Weisen beispielhaft implementiert (Bundles com.zuehlke.contacts.ui.addresscheck.maps und com.zuehlke.contacts.ui.addresscheck.zipcity).

com.zuehlke.contacts.service.api beschreibt die Schnittstelle zur Serviceschicht und ist als Stand-alone-API entworfen. Unser Beispiel enthält wenig Geschäftslogik, daher beschränkt sich die Aufgabe der Services auf das Persistieren der Fachobjekte. Für das Service-API existieren zwei Implementierungen, die die Daten auf unterschiedliche Weise speichern. Die Implementierung com.zuehlke.contacts.service.local legt die Daten lokal auf dem Dateisystem ab, während die Implementierung com.zuehlke.contacts.service.remote einen in der Cloud installierten Server nutzt.

Abb. 2: Bundle-Übersicht der Kontaktverwaltung
Geschrieben von
Stefan Reichert und Pascal Alich
Kommentare

Schreibe einen Kommentar

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