Abhängen à la OSGi

Abhängigkeitstyp „Erweiterbare Komponente“

Dieser Abhängigkeitstyp kann als eine Weiterentwicklung des ersten gesehen werden. Er zeichnet sich dadurch aus, dass die Komponente zusätzlich Callbacks in ihrer Schnittstelle definiert und dadurch erweiterbar wird. In Abbildung 2 wird durch die blauen Call-Pfeile verdeutlicht, dass die Komponente A unter bestimmten Umständen Implementierungen der Callbacks aufruft, die von den Bundles D und/oder E bereitgestellt werden.

Die erhöhte Flexibilität besteht nun darin, dass es für Teilaspekte einer Komponente mehrere Varianten beziehungsweise Implementierungen geben kann, zum Beispiel um sich verschiedenen Installationen eines Produkts anzupassen. Auch lassen sich Fallback-Szenarien damit umsetzen: Fällt eine Erweiterung aus, kann problemlos auf eine andere zurückgegriffen werden.

Die Erweiterungen unterscheiden sich von gewöhnlichen Komponenten dadurch, dass sie selbst keine eigene Schnittstelle bereitstellen. Vielmehr können sie in ihrer Implementierung wiederum andere Komponenten nutzen. In diesem Fall wird die Erweiterung zu einer Art „Adapter“. Erweiterungen zeichnen sich dadurch aus, dass sie nur in Verbindung mit der erweiterten Komponente verwendbar und somit nicht allein „lebensfähig“ sind.

Abb. 2: Abhängigkeitstyp „Erweiterbare Komponente“

Bei der Betrachtung von Abbildung 2 wird schnell ersichtlich, dass die Komplexität des Gesamtsystems durch erweiterbare Komponenten zunimmt. Zum einen liegt dies an den zusätzlichen Abhängigkeiten und zum anderen entstehen Implikationen für die Laufzeitumgebung. Denn in der Regel ist eine erweiterbare Komponente zur Laufzeit auf das Vorhandensein von Erweiterungen angewiesen. Etwaige Fehler fallen unter Umständen erst zur Laufzeit auf.

Das bereits erwähnte Beispiel der Security-Komponente könnte so weiterentwickelt werden, dass zum Beispiel der Datenzugriff über eine Erweiterung abgewickelt wird. Konkret würde das bedeuten, dass von der LDAP-Anbindung abstrahiert wird und ein Interface für den Zugriff eingeführt wird. Dieses wird dann durch erweiternde neue Komponenten implementiert. Eine würde die alte LDAP-Implementierung enthalten, während andere zum Beispiel auf eine Datenbank, einen Web Service oder einfach auf eine Textdatei zugreifen würden.

Abhängigkeitstyp „Standalone API“

Auch die dritte Abhängigkeitsart kann als Weiterentwicklung der ersten gesehen werden. Die Schnittstelle, die vorher Teil des Providers war, wird herausgelöst und als Komponente ohne eigene Funktionalität bereitgestellt. Es kann nun verschiedene Implementierungen in Form eigener Komponenten geben, während die Schnittstelle nun unabhängig weiterentwickelt und versioniert wird. Wie in Abbildung 3 dargestellt, ist es nun nicht mehr nur möglich, mehrere Provider der Schnittstelle zu haben (D und E), sondern auch mehrere Consumer (B und C). Somit vereint dieses Szenario Wiederverwendbarkeit und Erweiterbarkeit und ist das flexibelste der hier vorgestellten. Dieser Weg ist zum Beispiel dann sinnvoll, wenn sich herausstellt, dass eine Schnittstelle auch in anderen Zusammenhängen sinnvoll eingesetzt werden könnte, beziehungsweise andere Komponenten auf die gleiche Weise erweiterbar sein sollen.

Abb. 3: Abhängigkeitstyp „Standalone API“

Im Vergleich zu Erweiterungen bedeuten „Stand-alone APIs“ wiederum eine Steigerung der Komplexität. Denn es gibt insgesamt mehr Komponenten und mehr Abhängigkeiten zwischen ihnen. Alle Consumer und Provider haben eine Abhängigkeit zur API-Komponente. Im Falle des Security-Beispiels könnte die Weiterentwicklung in Richtung eines Stand-alone API erforderlich werden, weil ein anderes Projekt ebenfalls die Schnittstelle nutzen möchte, aber eine andere Art der Rechteüberprüfung implementieren muss. Um die unnötige Abhängigkeit zur originären Implementierung loszuwerden, muss das API zwingend von der Implementierung getrennt werden. Auch organisatorisch wäre ein Wechsel der Verantwortlichkeit hin zu einem Frameworkteam vorstellbar. Unten finden Sie eine Übersicht der Abhängigkeitstypen.

Abhängigkeitstypen
Abhängigkeitstyp „Komponente“

Schnittstelle und Implementierung liegen in einem Bundle.
Flexibilität

  • austauschbare Implementierung
  • beliebig viele Nutzer (Consumer)

Schnittstelle

  • anbietergetrieben

Beispiele

  • normale fachliche Komponente, zum Beispiel Kundenverwaltung in einem CRM-System
  • Third-Party-Komponente für Logging, Bildbearbeitung, Serverkommunikation u. Ä.
Abhängigkeitstyp „Erweiterbare Komponente“

Eine Komponente bietet zwecks Erweiterbarkeit ein Interface an und ruft es selbst auf (Consumer).

Flexibilität

  • Erweiterbarkeit
  • beliebig viele Implementierungen (Provider) möglich

Schnittstelle

  • nutzergetrieben

Beispiele

  • Rechnungskomponente definiert Schnittstelle zum Drucken
  • Währungsrechner definiert Schnittstelle zum Beziehen der Wechselkurse
  • Komponente definiert Callbacks für andere Events, zum Beispiel Benutzer hat sich eingeloggt, neuer Kunde wurde angelegt
Abhängigkeitstyp „Standalone API“

Die Schnittstelle liegt in einem eigenen Bundle.

Flexibilität

  • volle Flexibilität
  • mehrere Nutzer möglich
  • mehrere Implementierungen möglich

Schnittstelle

  • eigenes Artefakt
  • eigenständig versioniert

Beispiele

  • Interfaces und Basisklassen eines Frameworks
  • Security API (Authentifizierung und Autorisation)
Kommentare

Schreibe einen Kommentar

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