Rich Ajax Platform Architektur

Bevor die Architektur der Rich Ajax Platform vertieft wird, ist ein Hinweis auf den Artikel Rich Ajax Platform – Einführung und Geschichte angebracht.

Architektur der Rich Ajax Platform

Wird die Gegenüberstellung der RCP sowie RAP Architektur betrachtet, sind einige Gemeinsamkeiten zu entdecken.

Gegenüberstellung der RCP und RAP Architektur

Auf der linken Seite ist die RCP Architektur zu erkennen, rechts die der Rich Ajax Platform. In Folge dessen ist festzustellen, dass die oberen Schichten der Architektur absolut identisch sind und lediglich die beiden unteren Schichten der RCP Architektur ausgetauscht wurden.
Zum einen wird die Anwendung nicht auf dem lokalen Rechner ausgeführt, sondern auf einem Server womit sich Clients verbinden können und zum anderen wird das Standard Widget Toolkit durch das RAP Widget Toolkit ersetzt, da der Zugriff auf native Methoden des Betriebssysteme vom Browser nicht erlaubt ist.

RAP Widget Toolkit

Wie in der oben gezeigten Abbildung abgebildet, ersetzt das RAP Widget Toolkit das Standard Widget Toolkit. Hierbei handelt es sich jedoch nicht um einen einhundert prozentigen Ersatz aller Funktionalitäten aus dem Standard Widget Toolkit. RWT ist genau genommen eine große Teilmenge von SWT. Bei dem ersten Release von RAP war diese Teilmenge noch etwas rar, doch mit jeder weiteren Version der Rich Ajax Platform nahm das RWT zunehmend Ähnlichkeit mit dem Standard Widget Toolkit an. Demzufolge ist damit zu rechnen, dass in Zukunft nahezu alle Funktionalitäten von SWT auch in RAP zur Verfügung stehen.

[ad#co-3]

Das Rich Ajax Platform Widget Toolkit arbeitet mit denselben Softwareschnittstellen wie das SWT, jedoch werden die Ergebnisse mit Hilfe der Ajax-Technologie im Webbrowser umgesetzt. Bei der Entwicklung von RWT konnten allerdings nicht alle Ereignisse portiert werden die aus der Java Oberfläche bekannt sind. In RWT wird es zum Beispiel nicht möglich sein, Kreise, Linien oder andere grafische Objekte mit Canvas zu zeichnen, da Frameworks wie GEF und GMF nicht durch RAP unterstützt werden.
Bei der Verwendung von RWT geht es also darum, die Komponenten nicht auf dem Desktop, sondern im Browser des Anwenders darzustellen. Dabei werden die entsprechenden Aufrufe in Ajax über das Qooxdoo Framework umgesetzt.

In den nachfolgenden Abbildungen ist eine Demoanwendung veranschaulicht, in der fundamental der gleiche Code genutzt wird, jedoch oben die Anwendung mit RWT und unten die Anwendung mit SWT gerendert worden ist.

Maildemo - RAP

Maildemo - RCP

Bei der Ausführung einer Rich Ajax Anwendung liegt ein Teil der RWT-Logik auf dem Java geschriebenen Webserver Jetty sowie ein Teil auf dem Client. Der Client realisiert die zugesendeten Informationen über das JavaScript Framework Qooxdoo. Nachdem eine Anwendung im Browser aufgerufen wurde, bestehen von jedem GUI-Objekt zwei Instanzen, wobei eine Instanz auf dem Server liegt und die andere sich auf dem Client befindet. Hierbei besitzt jedes dieser Objekte einen bestimmten Zustand und spezielle Eigenschaften, die im Laufe der Verwendung immer wieder synchronisiert werden müssen. Die Synchronisation wird beispielsweise durch bestimmte User-Events wie das Auswählen eines Menüeintrages ausgelöst. Detaillierte Informationen zum Synchronisationsprozess mittels Ajax wurde bereits im Artikel Ajax Architektur erläutert.

[ad#co-3]

Im nächsten Abschnitt, RWT Life Cycle, wird im Detail auf den RAP Lebenszyklus eingegangen.
Zusammenfassend lässt sich sagen, das RWT in der Rich Ajax Platform Version 1.3 noch nicht alle Funktionalitäten von SWT umsetzen kann, die Entwicklung von RWT aber permanent weitergeführt wird, so dass in Zukunft mit mehr SWT Funktionalitäten zu rechnen ist.

RAP Life Cycle
An dieser Stelle möchte ich den RWT Lebenszyklus etwas näher erklären. Ein GUI-Element besteht aus einer Server Instanz sowie einer Client Instanz. Weil sich die Client Instanz häufig ändert, muss diese mit dem Server synchronisiert werden. Die Synchronisation geschieht immer in einer bestimmten Reihenfolge welche in der nachfolgenden Abbildung abgebildet ist.

RAP Life Cycle

Auch wenn es vier eindeutige Phasen im RWT Life Cycle gibt, heißt dies nicht, dass jedes Event diese Phasen durchläuft. Um den Server nicht unnötig zu überlasten können Events gesammelt werden um sie anschließend gemeinsam zum Server zu schicken.

  1. PrepareUIRoot
  2. Diese Phase ist lediglich für die erste Anfrage interessant. Dabei werden die von der RAP Anwendung erforderlichen Startpunkte (entrypoints) aufgerufen. Auf der Client-Seite wird die HTML-Seite mittels des Ajax-Framework Qooxdoo erstellt und gerendert.

  3. ReadData
  4. Events die auf der Client-Seite ausgelöst wurden, werden serverseitig empfangen.

  5. ProcessAction
  6. Bei der ProcessAction Phase werden die ausgelösten Events verarbeitet. Am Ende dieser Phase sind alle Widget-Attribute des Clients mit den Widget-Attributen des Servers synchronisiert. Ist diese Phase abgeschlossen werden keine weiteren Attribute manipuliert.

  7. Render
  8. In der Render Phase wird der JavaScript Code generiert und anschließend zum Client übertragen. Hierbei werden nur geänderte Widget-Attribute zum Client übermittelt und anschließend clientseitig gerendert.

Multi-User

Gewöhnlicher weise ist die Bedeutung „Multi-User“ bei den World Wide Web Anwendungen heutzutage nichts Besonderes mehr. Allerdings ist RAP keine neu programmierte Webtechnologie, sondern basiert auf der Basis von RCP. Rich Client Applikationen sind nicht für den Gebrauch im World Wide Web entwickelt worden und somit wurde der Faktor Multi-User nie berücksichtigt. Natürlich ist es möglich, RCP Anwendungen mit geringem Aufwand zu RAP zu portieren, jedoch muss hierbei unter Umständen folgendes berücksichtigt werden: Nicht selten wird bei der Benutzung von Rich Clients das Singleton Entwurfsmuster eingesetzt. Bei der Umsetzung mit einem Singleton-Objekte würden jedoch nach der Migration alle Webuser auf dasselbe Objekt zugreifen. Damit würden Änderungen einzelner Datensätze für alle Nutzer sichtbar werden. Oft ist dies zwar erwünscht, sollte jedoch bei der Speicherung persönlicher Daten aus Sicherheitsgründen nicht der Fall sein. Genau aus diesem Grund musste bei der Entstehung von RAP eine zusätzliche Architekturschicht eingebunden werden.

[ad#co-3]

Die Entwickler der Rich Ajax Platform haben dieses Problem mit dem Einführen von „Session-Singletons“ gelöst. Ein Session Singleton ist für jeden Benutzer einmalig und kann von den RAP Entwicklern wie folgt eingesetzt werden:

Beispielcode eines SessionSingletons

Im Hinblick auf die Skalierbarkeit hat das RAP Team Webserver getestet, in denen in etwa 250 Nutzer auf einem Gigabyte RAM und pro CPU Kern bearbeitet werden können.

Qooxdoo

Bei der Entwicklung einer Rich Ajax Anwendung stellt sich die Frage, wie die Applikation im Browser dargestellt wird, wo doch das Standard Widget Toolkit und JFace nicht zum tragen kommen.
Wie der Name Rich Ajax Platform bereits vermuten lässt, greift auch diese Technologie auf Ajax zurück, genauer gesagt auf Qooxdoo. Qooxdoo ist ein von 1&1 51 sowie GMX Mitarbeitern frei erhältliches Ajax Framework zur Erstellung von grafisch desktopähnlichen Benutzeroberflächen im World Wide Web. Dabei wird die SWT Schicht durch die RWT Schicht ausgetauscht. Das RWT, basiert genau auf diesem Ajax-Framework. Dabei wird die Oberfläche der Applikationen über das Ajax-Framework in dem Browser gerendert. Weitere Demo Beispiele des Qooxdoo Frameworks sind unter http://qooxdoo.org/demo zu finden.