© DrHitch/Shutterstock.com
Vaadin mit Eclipse, Clojure und OSGi

3 Modular auf ganzer Linie - Projekt Ripla: eine Plattform mit OSGi und Vaadin bauen


Die Stärke des Plattformansatzes wurde von Eclipse beispielhaft durchgespielt. Die Eclipse Rich Client Platform (RCP) wird von einem verhältnismäßig knappen Satz an OSGi Bundles gebildet. Die eigentliche Anwendung entsteht dadurch, dass die Plattform durch eine beliebige Anzahl von Komponenten aus dem Eclipse-Ökosystem angereichert wird. So existieren unzählige Anwendungen, die im Kern alle aus Eclipse bestehen, aber ganz unterschiedliche Verwendungszwecke haben und ebenso unterschiedliche Anwendungsprobleme lösen.

Während das Plattformmodell im Fat-Client-Bereich, d.h. im Bereich der Applikationen, die auf einem PC installiert werden, weite Verbreitung gefunden hat, werden im Bereich der Webapplikationen die meisten Anwendungen in traditioneller Weise ausgeliefert und installiert. Das mag damit zusammenhängen, dass der Deployment-Aufwand von Webapplikationen im Vergleich zu Fat-Clients von untergeordneter Bedeutung ist. Im Fat-Client-Modell muss die Anwendung auf jedem Kundenrechner installiert werden. Dies gilt auch für jede neue Version der Anwendung. Das allein macht den Vorteil eines Plattformansatzes augenfällig. Besteht die Applikation aus einem Kern, z.B. Eclipse RCP, und einer Sammlung von Komponenten, die in einem lockeren Verbund an diesen Kern angehängt werden, so besteht die Möglichkeit, eine solche Applikation aus sich heraus zu aktualisieren. Es reicht aus, dass der Applikationskern weiß, wie die umgebenden Komponenten auszuwechseln sind. Auf diese Weise kann der Installationsaufwand auf die einmalige Installation der Applikation reduziert werden. Alle Aktualisierungen erfolgen aus der installierten Plattform heraus.

Webapplikationen dagegen sind üblicherweise Thin-Clients. Die eigentliche Applikation wird auf einem zentralen Server installiert. Was die Benutzer sehen, wird in einem Browser dargestellt. Bei Webapplikationen beschränkt sich das Deployment also auf die Installation auf dem zentralen Server. Damit ist das Deployment, verglichen mit den übrigen Aufwendungen zur Entwicklung der Anwendung, von untergeordneter Bedeutung. Dies hat dazu geführt, dass man bei Webapplikationen zumeist noch in Unikaten denkt und effizientere Applikationsentwicklungsmodelle nicht in Erwägung gezogen werden.

Der Vorteil einer Plattform zeigt sich, wenn man den Blick von der Deployment-Problematik abwendet und untersucht, welche Vorteile sich ergeben, wenn Applikationen nicht als Unikate, sondern als Produkte – oder besser noch: im Rahmen von Produktlinien – erzeugt werden.

Produktlinien

In einem 2007 im Java erschienenen Artikel erläutert Roger Zacharias den Produktlinienansatz [1]. Produktlinien sind eine zweite Abstraktionsebene in der Softwareentwicklung. Bei einer schnell und aus dem Handgelenk heraus erzeugten Softwarelösung, die ausschließlich die unmittelbar gestellten Anforderungen löst, handelt es sich um ein Unikat. Wenn ein Anbieter verschiedene Kunden hat, wird er schnell feststellen, dass ein Arbeiten mit Unikaten zu aufwändig wird. Um seinen Aufwand zu reduzieren, wird der Anbieter versuchen, Gemeinsamkeiten in den verschiedenen Projekten zu finden und diese Invarianten auf eine erste Abstraktionsebene zu verschieben. Aus Unikaten werden Produkte: Die Gemeinsamkeiten sind abstrahiert und die Variabilität wird durch projektspezifische Anpassungen und Konfigurationen abgedeckt.

Wenn ein Unternehmen mehrere Produkte aus einem ähnlichen fachlichen Bereich anbietet, kann es diesen Abstraktionsprozess fortsetzen. Die Invarianten der Produkte werden auf die nächste Ebene ausgelagert: auf die Ebene der Produktlinie (Abb. 3.1). Hat der Anbieter Produktlinien eingerichtet, muss er innerhalb der Produkte nur noch die Unterschiede und Einzigartigkeiten managen. Die Softwareprodukte werden wie in einer Fertigungsstraße fabriziert: Mit dem gleichen Herstellungsprozess und unter gemeinsamer Verwendung unterschiedlicher Komponenten werden unterschiedliche Softwareanwendungen erzeugt. Dies führt dazu, dass die Fertigungstiefe verringert wird, weil konsequent darauf geachtet wird, die Produkte aus existierenden Komponenten zusammenzubauen. Damit können die knappen Ressourcen für die Kernkompetenzen des Unternehmens eingesetzt werden.

Abb.3_1.png

Abbildung 3.1: Abstraktionsebenen der Entwicklung (R. Zacharias, [1])

Für einen Anbieter ist es aus verschiedenen Gründen vorteilhaft, Produktlinien zu realisiere...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang