Einführung in die Rich Ajax Platform (RAP)

Inhaltsverzeichnis

Die Rich Client Platform (RCP) ist die Laufzeit-Technik für zahlreiche, in Java geschriebene Business-Anwendungen. Mit der Rich Ajax Platform (RAP) lassen sich diese zusätzlich im Web veröffentlichen – und das auf Basis des gleichen Codes.

Die Rich Ajax Platform (RAP) ermöglicht die Entwicklung von Webanwendungen mit Eclipse-Techniken. Die Plattform stellt eine Teilmenge der von RCP bekannten APIs zur Verfügung. Aus Sicht des Programmierers unterscheidet sich die Entwicklung mit RAP daher nicht von der mit RCP, allerdings wird die Anwendung im Browser des Benutzers dargestellt und nicht auf seinem Desktop. Aus RCP bekannte User-Interface-Konzepte wie Views und Editoren stehen zur Verfügung, ebenso erleichtern die APIs des JFace-Toolkits die UI-Programmierung. Für die Anbindung von Modelldaten an das UI lässt sich das Databinding von Eclipse benutzen, und länger dauernde Tasks lassen sich in Jobs verpacken, die Hintergrund-Threads abarbeiten. Durch asynchrone Updates kann man aus Jobs heraus schließlich das UI im Browser aktualisieren.

Mehr Infos

RAP

Das RAP-Projekt entstand 2006 auf Grundlage eines kommerziellen Frameworks. Es steht unter der Eclipse Public License und ist damit auch für kommerzielle Projekte frei nutzbar. Wie RCP ist RAP Teil des übergeordneten Eclipse-Runtime-Projekts (Eclipse RT), das Laufzeit-Techniken beherbergt (u.a.) die OSGi-Referenzimplementierung Equinox und den Servlet-Container Jetty. Das aktuelle RAP 1.3 ist zusammen mit Eclipse Helios im Juni 2010 erschienen.

Auf der Serverseite nutzt RAP Server-Side Equinox, ein Unterprojekt von Eclipse Equinox, das eine OSGi-Laufzeitumgebung mit klassischer Servlet-Technik integriert. RAP-Anwendungen lassen sich dadurch auf herkömmlichen Servlet-Containern wie Tomcat verteilen. Der Benutzer benötigt nur einen gängigen Webbrowser (Firefox 2+, IE 6+, Safari, Chrome, Opera). Da das UI ausschließlich mit JavaScript gerendert wird, sind keinerlei Browsererweiterungen nötig.

Die Abbildung 1 zeigt das RAP-UI von Toast, einer Applikation aus dem Eclipse-Examples-Projekt, die am Beispiel eines Flottenmanagementsystems den Einsatz von Eclipse-Runtime-Techniken veranschaulicht. Weitere Online-Beispiele findet man auf der RAP-Projektseite verlinkt.

Modularisierung mit OSGi

Eine Stärke von Eclipse-Anwendungen ist das Modularisierungskonzept von OSGi. Es bietet eine dynamische Laufzeitumgebung für Module, sogenannte Bundles. Diese sind versionierbar, und jedes Bundle definiert seine Abhängigkeiten von anderen Bundles und seine Export-Schnittstelle in einem Manifest. Über OSGi-Services können Module untereinander kommunizieren und andere Module erweitern. Diese Eigenschaften ermöglichen den Aufbau lose gekoppelter Systeme, bei denen sich nach Bedarf Anwendungsteile hinzufügen, weglassen oder austauschen lassen.

Die OSGi-Implementierung Equinox bildet die Basis für praktisch jedes Eclipse-Projekt. RAP stellt hierbei keine Ausnahme dar, sowohl die Plattform selbst als auch die darauf aufsetzenden Applikationen sind modular aufgebaut. Bei RAP greifen alle Benutzer auf eine einzige Equinox-Instanz auf dem Server zu, die mehrere Applikationen bereitstellen kann. Ein angenehmer Nebeneffekt dieses Anwendungsmodells ist die kurze Startzeit. Da die OSGi-Umgebung bereits hochgefahren ist, startet eine RAP-Anwendung deutlich schneller als ihr RCP-Pendant.

Rezeptur

Das Standard Widget Toolkit (SWT) bildet die Basisschicht für das UI jeder RCP-Applikation. Darauf bauen höhere Schichten wie JFace und die Eclipse Workbench auf. RAPs Grundidee ist es, SWT gegen eine Implementierung auszutauschen, die die Widgets auf dem Browser des Anwenders darstellen kann. Diese Implementierung heißt RWT (RAP Widget Toolkit) und bietet eine mit wenigen Ausnahmen deckungsgleiche API.

RWT besteht aus einem Server- und einem Client-Teil, der im Browser läuft. Der Client ist ausschließlich in JavaScript geschrieben und kommuniziert mit dem Server über Ajax-Requests. Der Server ist kompatibel zur Servlet-Spezifikation 2.3 und neuer. Damit sind RAP-Anwendungen auf allen gängigen Servlet-Containern lauffähig, und herkömmliche Werkzeuge und Infrastruktur etwa für Lasttests oder zur Lastverteilung lassen sich dadurch einfach auf RAP anwenden.

Das RAP-Anwendungsmodell ist mit einem Terminalserver vergleichbar. Die gesamte Anwendungslogik bleibt auf dem Server. Für jeden Benutzer unterhält er eine Applikationsinstanz, auf die man vom Browser aus zugreift. Der Client schickt für jede relevante Benutzerinteraktion einen Ajax-Request ab, der vom Server verarbeitet und mit den nötigen UI-Änderungen beantwortet wird. Die Antwort ist so optimiert, dass sie nur Informationen über tatsächlich geänderte UI-Teile enthält.

Trotz der häufigen Synchronisierung von Client und Server lässt sich die Oberfläche flüssig bedienen. In der Regel sind die Datenmengen, die ein solcher Ajax-Request/-Response übermittelt, so gering, dass sie in einem einzigen TCP-Paket Platz finden.

Einstieg

Erste Schritte

Um die Entwicklung von RAP-Applikationen zu erleichtern, stellt das RAP-Projekt Tool-Unterstützung für die Eclipse-IDE bereit. Man findet es auf den RAP-Downloadseiten. Unter den Eclipse-Downloads gibt es zudem eine vollständige Eclipse-IDE mit vorinstalliertem RAP-Tooling ("Eclipse for RCP and RAP Developers"). Nach der Installation ist die RAP-Runtime als Zielplattform einzustellen, gegen die die IDE alle Projekte kompiliert. Auf Wunsch übernimmt das RAP-Tooling diese Aufgabe.

Als Einstieg empfiehlt es sich, ein neues Plug-in-Projekt zu erzeugen und im letzten Schritt der Projekterstellung eines der mitgelieferten Templates auszuwählen. Die so entstandene Beispielanwendung lässt sich mit dem integrierten RAP-Launcher direkt aus der IDE starten. Die Anwendungsentwicklung unterscheidet sich nicht von der mit RCP. Die Abbildung 2 illustriert die Erstellung einer View in RAP mit identischem Code wie in RCP. Zunächst wird eine Unterklasse von ViewPart implementiert, die den Inhalt der View steuert, darauf folgt die Registrierung der Klasse per Extension.

Das RAP-Tooling enthält zudem den "RAP Developer Guide", der neben Artikeln zu Themen wie Deployment, Theming, Custom Widgets und Internationalisierung die komplette Referenzdokumentation enthält. Durch die Kompatibilität zu RCP ist ist das meiste Informationsmaterial zu RCP auch auf RAP anwendbar. Eine Auswahl grundlegender Artikel zu den Basistechniken findet sich auf der RAP-Projektseite unter "Documentation".

Feinabstimmung

Obwohl sich Weboberflächen optisch stark von klassischen Desktop-UIs unterscheiden, liegen doch beiden ähnliche Konzepte zugrunde. Letztlich setzen sich die Oberflächen aus Widgets zusammen. Allerdings liegt es nahe, das Aussehen der Widgets in RAP an das Webumfeld anzupassen. Das geschieht über CSS. Ein Theme definiert die Default-Eigenschaften der Widgets, etwa Farben, Schriftarten und Ränder. Auch Farbverläufe, abgerundete Ecken und Animationen unterstützt RAP.

Die Anpassung an das Webumfeld kann weit über bloßes Theming hinausgehen. Mit einer zusätzlichen API lässt sich das gesamte Layout der Anwendung umgestalten. Damit können Entwickler UI-Bestandteile wie Menü und Toolbar an geeigneten Stellen platzieren. Sie können zudem für die Anordung und Erscheinungsform der Inhalte, die RCP mit TabFolder organisiert, im Web eine passende Darstellung wählen, beispielsweise um ein Firmenlogo in den Kopfbereich der Webanwendung zu platzieren. Zwei Default-Implementierungen dieser API liefert RAP aus, eigene sind zusätzlich möglich.

Aus einer Quelle

Mit RAP kann man identischen UI-Code für Desktop und Webclients verwenden. Dafür hat sich der Begriff Single Sourcing eingebürgert. Mit der Verfügbarkeit einer SWT API lässt sich theoretisch jeglicher darauf aufbauende Anwendungscode in RAP nutzen. In der Praxis gibt es jedoch kleine Abweichungen zwischen der RAP- und der RCP-Version, denn RWT kann den Umfang von SWT nicht vollständig abdecken. Einige Funktionen, wie MouseMoveListener oder FileDialog, sind durch die unvermeidbare Netzwerk-Latenz beziehungsweise die abweichende Laufzeitumgebung nicht sinnvoll realisierbar.

Ein weiterer Grund für Abweichungen ist eine für RCP-Anwendungen gängige Annahme, dass es pro Anwendungsinstanz nur einen einzigen Benutzer gibt. Das trifft auf RAP nicht zu. Auf einem RAP-Server wird in einer einzigen OSGi-Instanz für jeden Benutzer eine eigene Applikation gestartet. Deshalb sind benutzerspezifische Daten (klassisches Beispiel: der Warenkorb) nicht in Singletons zu speichern. RAP bietet jedoch eine Option, solche Singletons in Session-spezifische Singletons umzuformen.

Dank der geeigneten Strategie lässt sich letztlich mit gemeinsamer Codebasis entwickeln und der plattformspezifische Code in gesonderte Artefakte auslagern. Erst beim Deployment sind diese mit dem plattformunabhängigen Code zusammenzulegen, mit dem Resultat einer auf der jeweiligen Plattform lauffähigen Anwendung. Ein Single Sourcing Guide, der Best Practices zur Entwicklung solcher Anwendungen aufzeigt, findet man auf den Seiten des Unternehmens EclipseSource.

Feinheiten

Individualisierung erwünscht

Manchmal ist es nötig, das SWT-Widget-Set für eigene Bedürfnisse zu erweitern. Mit Composite Widgets lassen sich Custom Widgets einfach aus vorhandenen Widgets zusammensetzen. Beispielsweise kann man aus einem Text- und einem Image-Label ein wiederverwendbares Widget erstellen, das ein Bild und einen Text in einer bestimmten Anordnung anzeigt.

Darüber hinaus können Entwickler mit "nativen" Custom Widgets direkt auf die Techniken der zugrunde liegenden Plattform zugreifen. Im Fall von RAP lassen sich so Browsertechniken wie JavaScript oder Flash in wiederverwendbare Widgets einbinden. Das Custom-Widget-Tutorial im "RAP Developer Guide" zeigt, wie man Google Maps in ein Widget integriert. Im RAP Incubator gibt es zudem einige fertige Custom Widgets, darunter eine File-Upload-Komponente und eine Integration von Googles Visualisierungs-Widgets.

Für Mash-ups aus populären Web-2.0-Services bietet das SWT-Browser-Widget eine einfache Alternative zum Schreiben von Custom Widgets. Es ermöglicht das Einbinden beliebiger Webinhalte in die Oberfläche einer Anwendung. RAP stellt diese Inhalte in einem IFRAME dar. Die BrowserFunction API ermöglicht sogar eine Kommunikation zwischen dem im Browser-Widget laufenden JavaScript und dem Java-Code der RAP-Anwendung.

Variable Verteilung

Für das Deployment einer RAP-Anwendung stehen grundsätzlich zwei Wege zur Auswahl. Im einfachen, auch "standalone" genannten Fall wird eine Instanz des Equinox-OSGi-Frameworks gestartet. Ein Bundle, das eine Servlet-Engine enthält (zum Beispiel Jetty), stellt hierbei einen OSGi-HttpService zur Verfügung, über den die RAP-Anwendung mit der Außenwelt kommuniziert. Beim Starten einer Applikation aus der Entwicklungsumgebung heraus kommt diese Art des Deployments zum Tragen. Auch auf Virgo, dem ehemaligen Spring dm Server, können RAP-Applikationen nach diesem Modell installiert werden.

Eine RAP-Applikation lässt sich aber auch als WAR-Archiv verpacken und in einen Servlet-Container wie Tomcat deployen, wodurch man RAP in bestehende "Java EE"-Infrastruktur integrieren kann. Diese als "Embedded" bezeichnete Variante bettet das OSGi-Framework und alle Bundles der Anwendung in ein WAR-Archiv ein. Hierbei stellt die sogenannte Servlet-Bridge die Dienste des Servlet-Containers über den HttpService bereit. Außerdem ist sie dafür zuständig, die im WAR enthaltenen OSGi-Bundles zu installieren sowie das OSGi-Framework zu starten und zu beenden. Die Servlet-Bridge ist Bestandteil des Server-Side-Equinox-Projekts.

Um Anwender bei diesem Deployment zu unterstützen, ist im Rahmen eines von Googles "Summer of Code" geförderten Projekts eine Tooling-Erweiterung für den komfortablen WAR-Export aus der IDE entstanden. Sie ermöglicht, eine Liste von Funktionen oder Plug-ins zusammenzustellen, zu validieren und als WAR-Archiv zu exportieren. Details sind im Blog-Eintrag von Holger Staudacher beschrieben. Geplant ist, dieses Tooling in den kommenden Eclipse-Release aufzunehmen.

Anschluss an das Eclipse-Ökosystem

Durch OSGi als Unterbau lässt sich RAP mit anderen Eclipse-Projekten kombinieren. Beispiele sind die Verknüpfung der Reporting-Engine BIRT (Business Intelligence and Reporting Tools) zur Generierung von Charts und Reports oder die Verwendung der EMF-Runtime (Eclipse Modeling Framework). Mit Equinox Security steht eine Anbindung an den Standard-Sicherheitsmechanismus von Java (JAAS) zur Verfügung. Zudem bringen andere Eclipse-Projekte mittlerweile Unterstützung für RAP mit. EMF erzeugt seit Eclipse Helios wahlweise RCP- oder RAP-Editoren für beliebige EMF-Modelle. Riena, ein Applikationsframework, das auf die Bedürfnisse von Enterprise-Anwendungen zugeschnitten ist, wird in der kommenden Version ebenfalls vollständig auf RAP laufen.

Auch im Kontext der nächsten Generation der Eclipse-Applikationsplattform (e4) tut sich bei RAP etwas. Zu den Hauptzielen der e4-Entwicklung gehört die Vereinfachung der Anwendungsentwicklung mit RCP. Ein einheitlicher Event-Bus ersetzt die schier unzählbaren Listener-Interfaces. Die unterschiedlichen Bauteile der Workbench-Oberfläche (Views, Editoren, Menüs und Werkzeugleisten) fasst ein einheitliches Modell zusammen. Dependency Injection ersetzt an vielen Stellen die Notwendigkeit, bestimmte Interfaces zu implementieren. Auch hebt e4 einige Einschränkungen der bestehenden Plattform auf. So soll der Kern der Eclipse-Workbench unabhängig von SWT werden, was das Single Sourcing weiter vereinfacht. Zudem steht die Multi-User-Fähigkeit der Workbench auf dem Plan.

Während des Entwicklungszyklus der letzten Version hat sich RAP durch die Nachrüstung bislang fehlender APIs kontinuierlich auf e4 hinzubewegt. Den aktuellen Stand der Entwicklung bei e4 auf RAP zeigt die Online-Version der e4 Contacts Demo. Weitere e4-Details behandelt der Artikel "Gemeinschaftswerk".

Ausblick

Ausblick

Das aktuelle RAP-Release enthält als neue Funktionen unter anderem Drag&Drop-Fähigkeit und einen GraphicsContext für Zeichenoperationen auf dem Client. Bis zu der Version hat sich die Entwicklung auf eine möglichst hohe API-Abdeckung konzentriert, um eine gute Wiederverwendung von Anwendungen zu gewährleisten. Mittlerweile ist die API so umfangreich, dass es nur noch wenige Hindernisse beim Single Sourcing bestehender Anwendungen gibt.

In der im Sommer erscheinenden kommenden Version wird der Schwerpunkt nun auf der Modernisierung des Clients liegen. Ein wichtiger Punkt ist dabei die Unterstützung mobiler Endgeräte, deren Multitouch-Oberflächen neue Anforderungen an den Client stellen. Apples iPad unterstützen aktuelle Milestones bereits gut. Anpassungen für Android und andere Plattformen sind ebenfalls geplant.

Zu einer modernen Webapplikation gehört ein zeitgemäßes Styling. Für RAP  1.4 stehen deswegen Neuerungen im Theming auf dem Programm, darunter Schatteneffekte und anpassbare Scrollleisten. Um RAP in der Zukunft für neue Client-Techniken zu öffnen, steht ein einheitliches Kommunikationsprotokoll für den Austausch von Statusänderungen zwischen Server und Client auf dem Plan. Damit soll es beispielsweise ermöglicht werden, RAP-Clients für ausgewählte Plattformen zu entwickeln.

Mit der Verfügbarkeit der SWT-Zeichenfläche in RAP rückt nun auch eine Unterstützung grafischer Editoren auf Grundlage von Draw2D und GEF (Graphical Editing Framework) in den Bereich des Möglichen. Die Arbeit an einem Port dieser APIs wird demnächst im RAP-Incubator aufgenommen. Weitere Details findet man auf der Projektsite. Bei Fragen oder Problemen hilft eine Newsgroup weiter.

Rüdiger Herrmann
ist freier Softwareentwickler und Co-Lead des RAP-Projekts. Als einer der initialen Committer war er verantwortlich für die Entwicklung von RWT.

Ralf Sternberg
arbeitet seit 2007 im RAP-Projekt mit und leitet nun das RAP-Entwicklungsteam bei EclipseSource. (ane)