OSGi erwacht zum Leben

Keep it simple, stupid!

Unsere Beispielanwendung illustriert unterschiedliche Möglichkeiten, Abhängigkeiten zwischen Bundles zu definieren und technisch umzusetzen. Der gewählte Abhängigkeitstyp richtet sich nach der benötigten Flexibilität und Erweiterbarkeit des jeweiligen Bundles. Für die Abhängigkeitstypen ist dann die passende Implementierung zu wählen. Diese Entscheidung ist von unterschiedlichen Faktoren wie beispielsweise den eingesetzten Bibliotheken abhängig. Es bietet sich an, Lösungen zunächst so einfach zu entwerfen und zu implementieren, wie es nach den Anforderungen möglich ist. Sollte sich herausstellen, dass ein Bundle mehr Flexibilität benötigt, dann kann es immer noch entsprechend angepasst werden.

Die vorgestellten Lösungen zur Implementierung bauen aufeinander auf bzw. sind kompatibel. So lassen sich die ggf. nötigten Änderungen mit vertretbarem Aufwand umsetzen. Widerstehen Sie der Versuchung, allein aus Prinzip ein vollkommen lose gekoppeltes System zu entwerfen und zu implementieren. Halten Sie es mit Kelly Johnson [5]: Keep it simple, stupid!

Require-Bundle vs. Import-Package

Paketabhängigkeiten sind implizite Abhängigkeiten, da sie ein Bundle nicht an ein bestimmtes anderes Bundle binden, sondern lediglich angeben, welches Paket benötigt wird. Welches Bundle die Funktionalität bereitstellt, ist erst zur Laufzeit relevant. Diese lose Kopplung bietet sehr viel Flexibilität. Der implizite Charakter von Paketabhängigkeiten erschwert allerdings deren Verwaltung. So führen Abhängigkeiten zu Komponenten mit vielen Paketen unter Umständen zu vielen Paketabhängigkeiten, die nur mühsam zu verwalten sind. Außerdem ist zur Entwicklungszeit ggf. nicht so leicht ersichtlich, welches Bundle ein bestimmtes Paket anbietet.

Bundle-Abhängigkeiten definieren explizit die benötigten Bundles. Es wird also nicht nur die Abhängigkeit von einer Funktionalität definiert, sondern auch deren Provider. Der explizite Charakter schränkt allerdings die Flexibilität etwas ein, da ein bestimmter Provider vorausgesetzt wird.
Die Frage, welcher Mechanismus Verwendung finden sollte, ist schwer zu beantworten. Auch hier ist es wieder notwendig, das Maß an benötigter Flexibilität zu bestimmen. Require-Bundle ist ein intuitiver Mechanismus, der einfach handhabbar ist. Für Laufzeitumgebungen, die sich unter eigener Kontrolle befinden, bei denen die Provider also bekannt sind, ist eine enge Kopplung durchaus vertretbar. In einer dynamischen Umgebung mit eventuell unbekannten oder wechselnden Providern kann die Verwendung von Require-Bundle allerdings zu starr sein. Import-Package ist in diesem Fall eine Möglichkeit, dieser Dynamik zu begegnen.

Require-Bundle:

  • explizite Abhängigkeit/enge Kopplung
  • intuitiv, einfach handhabbar
  • für bekannte Laufzeitumgebungen gut geeignet

Import-Package:

  • implizite Abhängigkeit/lose Kopplung
  • Refactoring in Bezug auf Komponentenschnitt möglich
  • aufgrund von Third-Party-Bibliotheken manchmal unumgänglich
  • mehrere (unbekannte) Provider zur Laufzeit möglich
  • Provider sind eventuell nicht leicht zu identifizieren
  • In der Regel werden deutlich mehr Packages als Bundles importiert.
  • implizite Erwartung an Implementierungen des Pakets: identisches „API“
Artikelserie

Teil 1: Abhängen à la OSGi

Teil 2: OSGi erwacht zum Leben

Stefan Reichert, Diplom-Wirtschaftsinformatiker (FH), arbeitet als Software Engineer bei Zühlke Engineering in Hamburg. Er beschäftigt sich seit mehreren Jahren mit verteilten Java-Enterprise-Anwendungen, serviceorientierten Architekturen, Eclipse und Eclipse RCP. Darüber hinaus ist er Autor mehrerer Fachartikel. Im August 2009 erschien sein Buch „Eclipse RCP im Unternehmenseinsatz“. Kontakt: stefan [at] wickedshell.net,
http://www.wickedshell.net/blog

Pascal Alich, Diplom-Wirtschaftsinformatiker (FH), arbeitet als Software Engineer bei Zühlke Engineering in Hamburg. Er setzt Projekte im Bereich Java Enterprise und Eclipse RCP. Seine Erfahrungsschwerpunkte liegen in den Branchen Versicherungen, Banken und Logistik. Er lebt mit seiner Familie in Hamburg. Kontakt: pascal [at] alichs.de, http://blog.alichs.de

Kommentare

Schreibe einen Kommentar

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