Saros Komponenten


Saros, welches als Basis für RCP Applikationen verwendet werden kann, wird permanent weiterentwickelt und an die neusten Releases der Eclipse RCP angepasst. Nachfolgend werden die in Saros enthaltenen Komponenten näher erläutert.

Application Lifecycle Support
Die „Application Lifecycle Support“ Komponente ermöglicht es, beliebige Jobs während des Aufstartens oder des Herunterfahrens der Applikation auszuführen. Der Ablauf (Reihenfolge, Parallelität) kann konfiguriert werden. Ein Job kann das Beenden oder den Neustart der Applikation initiieren (Konfigurationsfehler, Update der Applikation). Beispiel eines Lifecycles: (Start) – Update Konfiguration – Update der Applikation – Login Dialog – (Interaktion des Users) – Logout - (Stopp)

Automated Update
Die „Automated Update“ Komponente erweitert den Eclipse Update Mechanismus. Es muss unterschieden werden zwischen dem Update der Konfiguration der Applikation und dem Update der Applikation selbst. Ein Konzept zum Updaten einer Konfiguration (zum Beispiel die des Lifecycles) existiert in Eclipse bis jetzt nicht. Das Updaten wird im Gegensatz zur Eclipse RCP ohne User Interaktion ausgeführt. Er muss vor dem ersten Serviceaufruf erfolgen und ist deshalb bereits als Lifecycle Job konfiguriert. Die Kommunikationsparameter des automatisierten Updatemechanismus können ohne Programmieraufwand konfiguriert werden.

Remoting [Client/Server]

Die „Remoting“ Komponente ist für die Kommunikation zwischen dem Client und dem Server verantwortlich. Diese Komponente ist beliebig konfigurier- und erweiterbar. So kann sie auch als Abstraktionsschicht innerhalb des Client genutzt werden, um den Datenfluss beliebiger Quellen mit dem Rest unserer Komponenten zu vereinheitlichen und kompatibel zu machen. Die wichtigsten Features im Überblick:
  • Synchrone / asynchrone Kommunikation
  • Mehrere Kommunikationskanäle mit eigenen Sicherheitsstufen
  • Konfiguration von Protokoll und Handlern im Plugin
  • Konfiguration von Kommunikationsparametern in Konfigurationsfiles
  • Sessionhandling mit Callback für Security Komponente
Security
Die „Security“ Komponente stellt für diverse Authentisierungsverfahren GUI Komponenten zur Verfügung. Es sind einstufige Verfahren wie User/Passwort und mehrstufige Verfahren wie User/Passwort/Secure-ID implementiert. Die Implementation ist dabei voll JAAS kompatibel.

DataBinding

Die „DataBinding“ Komponente ist ein zentraler Bestandteil eines jeden modernen Java Clients. Die Eclipse RCP bietet bis Release 3.1 überhaupt keine und mit 3.2 nur rudimentäre Hilfe für ein effizientes und zweckmässiges Verknüpfen von Daten und Model. Je besser das DataBinding das Model mit den Widgets verknüpft, desto schneller, fehlerfreier und wartbarer kann eine Applikation entwickelt werden. Folgende Anforderungen werden durch die DataBinding Komponente erfüllt:
  • Synchronisation zwischen Model-Attributen und Widgets
  • Konversion zwischen Model-Attributen und den darzustellenden Werten (z.B. Date zu String bzw. String zu Date)
  • Formatierung der darzustellenden Werte (z.B. Anzahl Stellen bei Beträgen)
  • Auslösen der Validierung des Models und Markierung der fehlerhaften Widgets, wobei die Validierung durch die Businesslogik erledigt wird
  • Darstellung von Warnungen abhängig vom Inhalt des Models
  • Abhängigkeiten zwischen Widgets (refresh, enable/disable, visibility)
  • Kontext Abhängigkeiten (automatisches Aktivieren/Deaktivieren von Widgets, je nach Rolle des Benutzers)
  • Konsequente Trennung der Darstellung von der Businesslogik

Custom Widgets

Die „Custom Widgets“ Komponente beinhaltet diverse komplexe Widgets, die immer wieder benötigt werden. Beispiele dafür sind ein Kalender Widget zum Auswählen eines Datums oder kombinierte Text/Listen Widgets, die einerseits eine schnelle, andererseits eine sichere Eingabe von vordefinierten Werten garantiert. Die Widgets sind voll kompatibel mit der DataBinding Komponente.

Data Access Cache

Die „Data Access Cache“ (DataStore/Repository) Komponente ist ein intelligenter Cache für Model-Objekte. Intelligent deshalb, weil er automatisch die Resultate von Service Aufrufen analysieren und sich selbst aufdatieren kann. Wird ein Model-Objekt durch einen Service Aufruf geändert, werden interessierte Beobachter benachrichtigt. Der Cache kennt Model-Objekt Bäume mit Referenzen als Verknüpfung (1:1 oder 1:n Referenzen) und sendet Delete-, Update oder Add-Events, wenn Referenzen eines Models geändert werden. Interessierte Beobachter können sich auf solche Events registrieren.

Der Cache gewährt jederzeit den Zugriff auf ein Model-Objekt, dass eindeutig mit einer GUID identifiziert werden kann. Jedes Model-Objekt kommt nur einmal im Cache vor. Man kann den Cache so konfigurieren, dass er das Lesen eines Model-Objektes oder einer Referenz bei Bedarf vom Server (synchron/asynchron) auslöst.

Configurable Tree/Table/Treetables
Bäume, Tabellen und kombinierte Baumtabellen sind sehr komplexe GUI Komponenten und sind entsprechend aufwändig zu programmieren. Um den Entwickler zu entlasten und einen möglichst effizienten Auf- bzw. Abbau dieser Komponenten zu garantieren, bietet Saros konfigurierbare Bäume und Tabellen, sowie deren Kombination. Dabei werden die Konzepte von Eclipse nicht ersetzt, sondern darauf aufgebaut. Eine Tabelle zum Beispiel kann so mit diversen Inhalten vollständig in XML mittels Eclipse Erweiterungsmechanismus konfiguriert werden. Dies gilt ebenso für Bäume und Baumtabellen. Neben der Konfigurierbarkeit, wird auch die Sortierung nach mehreren Spalten ermöglicht. Auch das Ein- und Ausblenden von Spalten via GUI ist ohne Programmieraufwand möglich.
Diese user-spezifischen Modifikationen werden mittels Eclipse Mechanismus persistent gemacht. Das Rücksetzen der Konfigurationsmodifikation durch den User ist jederzeit möglich. Müssen die Daten asynchron geladen werden, was für ein benutzerfreundliches GUI insbesondere bei grossen Datenmengen notwendig ist, spielen diese GUI Komponenten mit dem Data Access Cache zusammen. Die Daten werden dabei vollautomatisch bei Bedarf asynchron vom Server geladen und dargestellt. Bäume, Tabellen und Baumtabellen sind ein Gebiet in Eclipse, welches in Zukunft stark erweitert werden wird. Unter Berücksichtigung dieses Umstandes ist eine generische, zentrale Implementation dieser GUI Komponenten wichtig, um mit wenig Aufwand mit den Fortschritten der Eclipse Plattform Schritt zu halten.

Role Based GUI

Das Konzept eines rollenabhängigen GUIs ist in Eclipse nicht vorhanden. Allerdings kann man den Activity Mechanismus von Eclipse dazu nutzen, ein solches Konzept zu realisieren. Im Zusammenspiel mit dem DataBinding können wir mit der „Role Based GUI“ Komponente so auch beliebig Widgets auf Grund der Rolle aktivieren oder deaktivieren.

Configurable Editors/Wizards/Views/Dialogs

Die konfigurierbaren Editoren, Wizards, Views und Dialoge haben gemeinsam, dass sie einen beliebigen Inhalt (Composite Content) darstellen können, der losgelöst von dem umgebenden Container erstellt und als Eclipse Extension in XML definiert wird. Zum Beispiel können die Inhalte von Wizards, also die einzelnen Seiten, ebenso als Tabs in Editoren dargestellt werden. Die Wiederverwendung und die einfache, sehr kompakte Erstellung dieser Inhalte steht dabei im Vordergrund und ermöglicht somit eine schnelle Entwicklung vieler GUI Layouts. Die Container wie Wizards, Editoren und Views werden nach wie vor als Standard Eclipse Extensions in XML definiert. Somit lassen sich einerseits die Möglichkeiten von Eclipse und andererseits das Bedürfnis nach einer effizienten und trotzdem qualitativ hochstehenden Entwicklung koppeln.

Plugable Formatters/Converters/Labelproviders

Diese Komponente ermöglicht es, Formatters und Labelproviders nicht nur in Java Code, sondern auch in anderen konfigurierbaren GUI Komponenten (z.B. Bäume, Tabellen, Baumtabellen) wieder zu verwenden. Damit kann sichergestellt werden, dass die graphische Darstellung eines Model-Objektes, oder eines seiner Attribute, zentral an einem Ort programmiert ist, egal ob es sich um den Titel eines Editors, einen Baumknoten oder einen Eintrag in einer Tabelle handelt.

Error Handling

Das Error Handling zieht sich durch alle Komponenten hindurch und ist meistens schwierig zu implementieren, wenn es nicht von Anfang an eingeplant wird. Bei den oben beschriebenen Projectware Komponenten wurde das Errorhandling entsprechend gewichtet und findet sich an diversen Orten wieder. Angefangen beim Remoting, wo beliebige Errorhandlers angefügt werden können, bis hin zum DataBinding, wo bei einem Validierungsfehler auf einem Attribut auch beim entsprechenden GUI Element der richtige Text angezeigt werden soll. Auch Fehler,
die in einem Service Aufruf auftreten, müssen dem entsprechenden GUI Element zugeordnet werden können.

Enterprise Business Object (EBO) Framework Libraries

Die EBO Framework Libraries sind nicht von Eclipse abhängig und beinhalten vorwiegend Interfaces und Basis Implementationen, die den generischen Aspekt von Model-Objekten garantieren. Solch generische Aspekte sind zum Beispiel:
  • Generischer Zugriff auf Attribute
  • Generischer Zugriff auf Referenzen
  • Generischer Zugriff auf ein Attribut, welches nur z.B. via Referenz erreichbar ist
  • Generische Validierung und Validierungsausnahmen