Rich Client Platform Architektur

Bevor die Architektur von der Rich Client Platform etwas präziser erklärt wird, ist das Lesen des Artikels Rich Client Platform – Grundlagen mit Sicherheit ein guter Einstieg.

Rich Client Platform Architektur

Einleitend ist zu erwähnen, dass im Rahmen dieses Beitrages nicht alle Module eingehend behandelt werden können, hierbei wird sich auf die wesentlichen Bestandteile der Eclipse Rich Client Architektur beschränkt.
Um die Architektur der Rich Client Platform etwas näher zu betrachten, wird zunächst die allgemeine Architektur von Eclipse veranschaulicht.Im Wesentlichen ist Eclipse eine Sammlung von Plug-ins und beruht somit auf der Plug-in-Architektur welche die zentrale Technologie von Eclipse und Eclipse-basierten Rich-Client-Anwendungen ist. Das Kernstück von Eclipse ist unbedeutend klein und hat lediglich die Aufgabe Plug-ins lauffähig zu machen. Dies geschieht über sogenannte Extension Points. Jedes Plug-in hat somit die Möglichkeit über diese Erweiterungspunkte das eigene Plug-in zu erweitern oder anzubieten. Extensions sind also Erweiterungen, die an Erweiterungspunkte anknüpfen können.

Architektur der Eclipse Plattform

[ad#co-3]

Eclipse wurde dadurch sukzessiv erweitert, dass alle Eclipse Module in separate Pakete aufgeteilt wurden. Dies hat nicht nur den Vorteil größtmöglicher Flexibilität, sondern ebenfalls der Einbindung einzelner separat entwickelter Features. Um Extensions sowie Extension Point nutzen zu können, werden diese in einem speziellen Plug-in Manifest, der plugin.xml Datei, definiert. Die Beschreibung eines solchen Punktes erfolgt über das übliche XML Schema. Aufgrund der automatischen Auswertung beim Start der Eclipse Plattform muss die XML Datei nicht ausdrücklich registriert werden.
Die Rich Client Platform wird in dem oben abgebildeten Diagramm im unteren Abschnitt abgebildet. Die im oberen Abschnitt gezeigten Komponenten gehören nicht zur Minimaldistribution, können jedoch bei Bedarf hinzugefügt werden. Das Fundament der Rich Clients basiert auf OSGi. Standardmäßig wird zur Veranschaulichung der jeweiligen Anwendung das SWT (Standard Widget Toolkit) sowie die JFace API verwendet.

OSGi

OSGi ist eine Java basierte plattformunabhängige Service-Plattform, welche ab der Eclipse Version 3.0 als Standard Ablaufumgebung mitgeliefert wird. Innerhalb eines OSGi-Servers werden sogenannte OSGi Bundles genutzt. Das Hauptziel von OSGi ist die Modularisierung von komplexen Softwaresystemen. Grundsätzlich lässt sich sagen, das alle Plug-ins der Eclipse Plattform als OSGi Bundle implementiert werden. Konkret bedeutet dies, dass ein Eclipse Plug-in ein OSGi-Bundle ist.
Eine Besonderheit ist das dynamische Hinzufügen, Starten, Stoppen, Ändern oder Deinstallieren eines OSGi-Bundles im laufenden Betrieb. Dieses Verfahren wird auch Hot Plugging genannt und kann ohne Severneustart durchgeführt werden. Dies sind zugleich die unterschiedlichen Zustände eines Bundles. Jedes Bundle besitzt einen spezifischen Lebenszyklus welcher in der nachfolgenden Abbildung veranschaulicht wird.

Zustandsdiagramm eines OSGi Bundles

[ad#co-3]

Dabei hat jedes Bundle zu einem Zeitpunkt einen bestimmten Zustand. Zusammenfassend zeichnet OSGi Modularisierung, Serviceorientierung und dynamische Zustandsänderung das Bundle aus.

Equinox

OSGi bietet verschiedene Open-Source Implementierungen, darunter auch Equinox. Die Eclipse-Plattform verwendet Equinox als Implementierung des OSGi-R4-Standards. Zu den OSGi Basismodulen bringt Equinox weitere zusätzliche Bundles mit. Dazu zählen unter anderem die Extension Registry welche für die Erweiterungsregistratur zuständig ist oder auch die Preference Klasse welche für die Speicherung von Benutzereinstellungen verantwortlich ist.

Standard Widget Toolkit (SWT)

Das Standard Widget Toolkit ist ein wesentlicher Bestandteil der Eclipse-Plattform beziehungsweise der Rich Client Platform. SWT ist eine auf Equinox basierende Schicht und bildet die Grundlagen der Oberflächendarstellung. Hinsichtlich der Tatsache, das AWT nicht weiterentwickelt wurde und Swing nicht schnell genug, vollständig und speichereffizient zu sein schien, entschied sich die Firma IBM mit dem Standard Widget Toolkit eine bessere Alternative zu entwickeln welche sich komplett von AWT abkapselt. Hierbei wird sich aber nicht auf den kleinsten gemeinsamen Nenner einer Plattform gestützt. Elemente, die auf einer bestimmten Plattform nicht vorhanden sind werden entweder emuliert oder ganz simpel nicht benutzt. Ähnlich wie Swing, basiert auch die GUI von SWT auf den nativen Widgets der entsprechenden Plattform welche das Look and Feel der Plattform wiedergibt und diese damit schwer von anderen Applikationen unterscheiden lässt. Eine Beispielanwendung die mit dem Standard Widget Toolkit geschrieben ist und auf verschiedenen Betriebssystemen gestartet wurde, wird in der folgenden Abbildung veranschaulicht.

Hinzuzufügen ist, dass nicht nur die nativen Widgets genutzt, sondern auch plattformspezifische Widgets angeboten werden. So kann beispielsweise unter Windows mit einem Zugriff auf das OLE Dokument der Internet Explorer angesprochen werden. Die Eclipse Rich Client Platform, welche im nachfolgenden noch detaillierter beschrieben wird, arbeitet mit dem Standard Widget Toolkit um komplexe Oberflächen darstellen zu können.

JFace

Basierend auf der SWT Schicht liegt die JFace Schicht. Die JFace-API ist fester Bestandteil der Eclipse-Plattform. JFace ist mit Swing bei AWT zu vergleichen und somit eine Ergänzung zu SWT womit nun auch komplexe Widgets wie Listen, Bäume, Dialoge oder Wizards verwaltet werden können. Des Weiteren ist es durch die JFace API möglich, einen Model-View-Controller zu implementieren welches standardmäßig durch SWT nicht möglich ist. Mit JFace ist es im Zusammenhang mit SWT möglich, nativ aussehende Programme und performante Rich Clients zu entwickeln.

Grafische Oberfläche

Wie bereits angesprochen, ist die Eclipse IDE das beste Beispiel einer Rich-Client Anwendung.

Grafische Oberfläche der Eclipse IDE

[ad#co-3]

Anhand dieser Entwicklungsumgebung werden nun die Komponenten im Einzelnen veranschaulicht. Hierzu soll der Screenshot als Unterstützung dienen. Zunächst fällt auf, dass die Eclipse IDE im nativen Look and Feel des Betriebssystems
ausgeführt wird. In diesem Beispiel wird die Anwendung unter Ubuntu 9.10 betrieben. Die Software unterteilt sich in verschiedene Komponenten, welche zusammen eine Einheit bilden. Eine bessere Übersicht der einzelnen Komponenten soll die folgende Abbildung veranschaulichen.

Struktur der Workbench

Workbench
Im Allgemeinen ist die Workbench für die Präsentation der Benutzeroberfläche verantwortlich. Hierbei handelt es sich lediglich um einen leeren Anwendungsrahmen welcher mittels Plug-ins im Laufe des Anwendungslebenszyklus gefüllt wird.

Workbench-Fenster
Die Workbench kann generell aus einem oder mehreren Workbench-Fenstern bestehen, wobei in dem vorliegenden Beispiel der Eclipse IDE lediglich ein Workbench-Fenster existiert. Das Öffnen einer weiteren Eclipse Instanz hätte zur Folge, dass es
weiterhin eine Workbench gäbe mit jedoch zwei Workbench-Fenstern.

Menübar
Die Menübar erleichtert das Navigieren und Handling der Software. Aber nicht immer ist eine Menübar erwünscht, weshalb sie auch wahlweise ausgeschaltet werden kann.

Toolbar
Oft werden wichtige hierarchisch versteckte Menüpunkte in der Toolbar abgebildet um eine schnelle Bedienung zu ermöglichen. Icons wie Speichern, Öffnen oder Erstellen sind in der Toolbar oft wiederzufinden.

Statusbar
Wie in vielen Anwendungen vorhanden, gibt es bei der Rich Client Programmierung ebenfalls eine Statusbar. Diese weist in der Regel auf zusätzliche Statusinformationen wie zum Beispiel den eingeloggten Benutzernamen, Uhrzeit oder Fortschrittsinformationen hin.

Workbench-Seite
Der innere Bereich eines einzelnen Workbench-Fensters wird als Workbench-Seite bezeichnet. An dieser Stelle ist zu erwähnen, dass jedes Workbench-Fenster genau eine Workbench-Seite beinhaltet.

Workbench-Komponente
Jede Workbench-Seite kann ein oder mehrere Workbench-Komponenten besitzen. Unter Komponenten sind beispielsweise Views oder Editoren zu verstehen, die letztendlich nur einmal geöffnet sein können.

Perspektive
Für gewöhnlich hat jede Rich-Client-Anwendung mindestens eine Perspektive. Eine Perspektive visualisiert eine Anordnung der Workbench-Komponente in einer Workbench-Seite. Üblicherweise stellt eine Perspektive eine bestimmte Benutzeroberfläche bereit. Ein Beispiel für eine separate Perspektive wären die Pflege oder Monatsabrechnung der Mitarbeiter. Diese Perspektive ist durch den Anwender nach Belieben zu ändern indem er sie beispielsweise verschiebt, vergrößert, verkleinert oder schließt.

[ad#co-3]