Abhängen à la OSGi

Das große Ganze

Die Komponenten eines Softwaresystems zu definieren, ist nicht einfach. Es müssen zunächst die einzelnen Komponenten identifiziert werden. Ist dies erfolgt, stellt sich die Frage nach deren konkreter Umsetzung. Beide Punkte entscheiden wesentlich über die Abhängigkeiten innerhalb des Systems. Die Gefahr besteht zum einen darin, zum Wohle der Erweiterbarkeit zu viele und zu kleine Komponenten zu definieren, die womöglich zusätzliche, nicht benötigte Flexibilität beinhalten. Die daraus entstehende Komplexität ist vermeidbar. Zum anderen können das Resultat aber auch zu wenige und damit zu große Komponenten sein. Diese Komponenten sind dann zu starr entworfen und unübersichtlich, sodass neue Anforderungen nur mit hohem Aufwand oder gar nicht umgesetzt werden können.

Unsere Erfahrung hat gezeigt, dass die beschriebenen Bausteine eine stabile und erweiterbare Komponentenarchitektur ermöglichen. Die dargestellten Abhängigkeitstypen sind aufeinander aufbauend. Es ist also möglich, einfach zu beginnen und die Flexibilität einer Komponente schrittweise zu erhöhen, falls dies erforderlich ist. Die jeweiligen Anforderungen können mit möglichst wenig zusätzlicher Komplexität erfüllt werden. Im konkreten Beispiel der Security-Komponente wird dies deutlich: Eine einfache Security-Komponente, bestehend aus einer konkreten Implementierung und einem Interface, kann zu einem allgemeinen Security-Service mit ganz unterschiedlichen, gegebenenfalls erweiterbaren, Implementierungen weiterentwickelt werden. Abhängige Komponenten werden von den Änderungen in der Regel nicht beeinflusst. Die beschriebenen Abhängigkeitstypen unterstützen ein ausgewogenes Verhältnis von Komplexität und Flexibilität. Am Ende steht ein System, dass weder durch zu wenige oder zu starre Komponenten ein undurchsichtiger Monolith noch durch zu viele Komponenten ein übermäßig flexibles Designerstück wird.

Im nächsten Artikel werden diese theoretischen Grundlagen anhand einer OSGi-Beispielanwendung mit Leben gefüllt. Es wird konkret beschrieben, wie Abhängigkeiten zwischen OSGi-Bundles definiert werden können (Require Bundle, Import Package) und wie ein Consumer an die konkreten Provider-Instanzen gelangt (Service Registry, Extension Factory).

Artikelserie

Teil 1: Abhängen à la OSGi

Teil 2: OSGi erwacht zum Leben

(Teil 2 folgt in wenigen Tagen hier auf JAXenter!)

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.