Google Web Toolkit und Ultra Light Client

Stefan Thomas

Viele neue Anwendungen werden darum als HTML-basierte Web-Anwendungen implementiert, die leicht verteilt und aktualisiert werden können und von überall, zu jeder Zeit genutzt werden können. Durch den Einsatz von AJAX-Technologien konnte die Benutzerfreundlichkeit der Oberflächen in den letzten Jahren deutlich gesteigert werden, allerdings bei gleichzeitig wachsender Komplexität in der Anwendungsentwicklung. Bibliotheken, Toolkits und Frameworks versprechen hier eine Erleichterung. Beispielsweise durch die Abstraktion der unterschiedlichen JavaScript-Implementierungen der Browser oder durch vorgefertigte, komplexere Bedienelemente wie Menübalken, Tabreiter oder Baumstrukturen.

Das Google Web Toolkit (GWT) [1] geht dabei einen besonderen Weg: Das Layout der Benutzeroberfläche, das Interaktionsverhalten der Bedienelemente und die Kommunikation mit den Backend-Komponenten wird vollständig in Java programmiert und anschliessend durch einen speziellen Compiler in AJAX-basierte JavaScript- und HTML-Fragmente übersetzt. Der Entwickler kann sich so stärker auf die Implementierung der eigentlichen Anwendungslogik konzentrieren und benötigt keine intimen Kenntnisse der verschiedenen Web-Technologien (HTML, CSS, JavaScript).

Daneben konkurrieren vollständig Java-basierte Architekturen mit AJAX-erweiterten Web-Anwendungen, die ebenfalls eine durchgängige Implementierung der Backend- und Präsentationsschicht in Java ermöglichen [2]. So implementiert das Ultra Light Client (ULC) [3] Framework der Canoo Engineering AG ein Half-Object plus Protocol (HOPP) Pattern [4] für die transparente, verteilte Ausführung der Präsentationsschicht zwischen einer Presentation Engine im Browser und der ULC-Anwendung auf dem Server.

Das Google Web Toolkit und die Ultra Light Client Architektur bieten aus Entwicklersicht beide ein sehr ähnliches, vergleichsweise komfortables Programmiermodell. Die Zieltechnologien sind aber vollkommen verschieden, so dass sich ganz unterschiedliche Rahmenbedingungen und Einsatzmöglichkeiten ergeben.

Das Google Web Toolkit wurde im Mai 2006 veröffentlicht und unterliegt der Apache 2.0 Lizenz. Das Toolkit unterstützt den Entwicklungsprozess durch mehrere Elemente: Java-Bibliotheken stellen einfache HTML-Elemente, komplexere Widgets und Kommunikationsklassen für Remote Procedure Calls zur Verfügung. Die Entwicklung der Präsentationsschicht erfolgt in einem ereignisgesteuerten Programmiermodell, das an Swing angelehnt ist. Das Toolkit umfasst weiter eine Java-Laufzeitumgebung, so dass der Java-Code in einem ,,Hosted Mode" direkt ausgeführt und getestet werden kann. So können beispielsweise Break-Punkte in Event Listener oder Server Callbacks gesetzt werden, um das Zusammenspiel zwischen Präsentationsschicht und Backend zu debuggen. Erst für das Deployment auf einem Server werden dann die Java-Klassen durch einen Compiler in HTML-Seiten und JavaScript-Funktionen übersetzt. Dabei werden gleichzeitig 4 Varianten generiert, je eine für die spezifische Unterstützung von Internet Explorer, Firefox/Mozilla, Safari und Opera.

Remote Procedure Calls zu Backend Services werden in GWT grundsätzlich asynchron abgewickelt. Die Bibliotheken stellen hierzu eine Reihe von Basisklassen und Interfaces zur Verfügung, welche dann im Hintergrund die Übertragung von Java-Objekten über das HTTP-Protokoll abwickeln. Für jeden Service, der eingebunden werden soll, sind drei Klassen zu entwickeln: Die Service-Implementierung, die von der GWT-Klasse RemoteServiceServletabgeleitet wird und auf dem Server ausgeführt wird. Das dazugehörige Interface, welches die öffentliche Methoden beschreibt und eine dazugehörige asynchrone Variante ohne Rückgabewert und einem Callback-Objekt als zusätzlicher Übergabeparameter.

Die Listings 1 und 2 zeigen die Interfaces und Implementierung eines Services CityService, der zu dem Namen einer Region eine Liste von Städtenamen liefert und beispielsweise für die dynamische Befüllung eines Paares von Drop-Down-Listen: ,,Region" und ,,Stadt" in einem Suchformular eingesetzt werden könnte.

Listing 1: Interface und Implementierung eines Services, der eine Liste von Städten zu einer Region liefert

Listing 2: Asynchrones Interface ohne Rückgabewert mit Callback-Parameter

Jede Benutzeraktion, die mit einem Backend-Aufruf verbunden ist, wird somit in zwei Stufen abgehandelt: Im ersten Schritt wird der Event Listener des betätigten Bedienelements ausgelöst. Von dort aus erfolgt dann der asynchrone Aufruf des Backend Services, der die Programmkontrolle sofort zurückgibt. Später, wenn das Ergebnis vom Server beim Client angekommen ist, wird dann die onSuccess-Methode des Callbacks abgearbeitet.

Das nachfolgende Listing 3 zeigt eine konkrete Implementierung der zwei Drop-Down Listen ,,Region" und ,,Stadt". Die Drop-Down Listen werden nebeneinander in einem Flow-Layout dargestellt. RootPanel.get()liefert eine Referenz auf den Body einer HTML Host Page, welche das GWT-Modul enthält.

Die Regionen ,,Nord" bis "Süd" sind fest vorgegeben. Beim Umschalten der Region wird die Liste der Städte vom Server neu geladen und aktualisiert. Die Drop-Down Liste cbRegions ist hierzu mit einem Change Listener versehen. Innerhalb der onChange-Methode wird ein Handle zu dem Backend Service erzeugt und die aktuell gewählte Region übergeben. Danach kehrt die Methode des Change Listeners sofort zurück und die Verarbeitung setzt sich erst in der onSuccess-Methode des Callbacks fort.

Listing 3: Implementierung eines Paares von Drop-Down Listen ,,Region" und ,,Stadt" in GWT

Eine ULC-Anwendung wird auf dem Client und dem Server verteilt ausgeführt. Die Verteilung der client- und serverseitigen Halbobjekte und die Kommunikation zwischen diesen erfolgt für den Entwickler transparent durch die Bibliotheken des Frameworks. Auf dem Client erfolgt das Rendering der Benutzeroberfläche durch eine Presentation Engine. Die Presentation Engine wird als Java-Applet ausgeführt. Alternativ ist das Deployment auf dem Client auch ohne Browser mittels Java Web Start oder in einem Stand Alone Mode möglich.

Die Presentation Engine überträgt die Benutzeraktionen über ein schlankes Protokoll zu der ULC-Anwendung auf dem Server. Dort werden die Ereignisse durch Event Listener verarbeitet und die resultierenden Veränderungen der Benutzeroberfläche (z.B. Aktualisierung einer Tabelle mit Suchergebnissen) wieder an die Presentation Engine auf dem Client übertragen. Eine ULC-Anwendung kann dabei als Servlet oder statefull Session Bean auf dem Server deployed werden. Die Kommunikation erfolgt dann entsprechend mittels HTTP- oder RMI/IIOP-Protokoll.

Die Presentation Engine rendert die Benutzeroberfläche auf dem Client durch Swing-Objekte. Die ULC-Bibliotheken für die Anwendungsentwicklung orientieren sich somit auch an dem Widget-Set von Swing. Viele Swing-Objekte stehen in ULC 1:1 zur Verfügung und erleichtern so den Einstieg in dieses Programmiermodell. Durch die automatische Verteilung der Halbobjekte durch das Framework, können ULC-Anwendungen wie klassische Fat Client Benutzeroberflächen entwickelt werden. Restriktionen ergeben sich - wie bei allen internetbasierten Ansätzen - nur bei der Realisierung von Push-Konzepten, d.h. Aktualisierungen der Benutzeroberfläche durch Hintergrundaktionen. Die Aktion muss hier immer vom Benutzer ausgehen (oder durch ein unsichtbares Polling Timer-Objekt vom Client aus regelmässig getriggert werden).

Mit Hilfe des sog. Development Runners können Entwickler die Verteilung der Halbobjekte zwischen Client und Server simulieren. Die Presentation Engine und die ULC-Anwendung werden dann in der gleichen Java Virtual Machine ausgeführt und können so ohne ein Deployment auf dem Server getestet werden. Der Developmen tRunner liefert dabei Informationen über die Anzahl der Server Round Trips und das Datenvolumen. Durch die Simulation der Netzwerkparameter Bandbreite und Latenz kann ausserdem das Antwortzeitverhalten der Anwendung bei feingranularer Ereignisbehandlung überprüft werden.

Ein Beispiel: Wie Swing unterstützt ULC die Aktualisierung eines Table Models wenn Zelleninhalte einer Tabelle editiert werden. Auf diese Weise kann ein Verhalten wie in einem Excel-Arbeitsblatt erreicht werden. Jede Aktualisierung ist hier allerdings mit einem Server Round Trip verbunden. Bei grossen Latenzzeiten, verhält sich die Anwendung dann relativ zäh. Abhilfe versprechen dann asynchrone Event Delivery Modes oder die Entwicklung von sog. Extensions.

Der Widget Set der ULC-Bibliotheken lässt sich problemlos erweitern. Hierzu muss die gewünschte neue Funktionalität in client- und serverseitigen Halbobjekten implementiert werden, die von ULC-Basisklassen abgeleitet werden und somit das ULC-Protokoll verwenden können, um Ereignisse und Daten auszutauschen. Clientseitig ist man dabei nicht nur auf Swing-Objekte beschränkt; AWT und SWT sind ebenfalls möglich. Ein typisches Beispiel wäre ein Texteingabefeld für Datumseingaben, welches mit einem Kalender-Popup verbunden ist und vollständig auf dem Client ausgeführt wird.

Das folgende Listing 4 zeigt die Implementierung der zwei Drop-Down Listen ,,Region" und ,,Stadt" in ULC. Durch die Ausführung der Anwendung auf dem Server kann die Service-Implementation ohne Callback direkt aufgerufen werden.

Listing 4: Implementierung der Drop-Down Listen in ULC

Ähnlich wie bei AJAX-unterstützten Web Anwendungen verändert sich auch hier die Struktur des Netzwerkverkehrs. Während in einer einfachen HTML-Anwendung grössere Mengen (ganze HTML-Seiten) in grösseren Zeitabständen (z.B. bei einem Click auf den Submit Button nach dem Ausfüllen eines Formulars) übertragen werden, werden hier kleinere Datenpakete häufiger übertragen.

GWT und ULC weisen aus Entwicklersicht viele Gemeinsamkeiten auf:

- Ein ereignisgesteuertes Programmiermodell, das vollständig in Java implementiert wird. Mit Hilfe der unterstützten Widget Sets können mit beiden Ansätzen komfortable Rich Internet Applications sehr produktiv realisiert werden, ohne dass sich der Entwickler mit den klassischen Rahmenbedingungen der Web-Anwendungsentwicklung (vielfältige Sprachen/Standards, Browser-Inkompatibilitäten) beschäftigen muss.

- Komfortables, integriertes Debugging der Präsentationsschicht durch Hosted Mode bzw. Development Runner ohne zeitaufwendiges Re-Deployment auf einem Server. Dadurch sehr schnelle Code-Test-Debug Zyklen.

In Wirklichkeit sind die Architekturkonzepte - nicht nur Aufgrund der unterschiedliche Zieltechnologie HTML+AJAX vs. Java - grundverschieden: GWT ist ein client-seitiges Framework. Für die Zugriffe auf den Server muss ein Remote Business-Interface programmiert werden. Vergleichbar zu einer Fat-Client Swing-Anwendung, die mit SessionBeans auf einem Server mittels RMI kommuniziert. ULC wird hingegen server-seitig ausgeführt und Backend-Aufrufe sind unmittelbar möglich.

Auch hinsichtlich der Reife beider Produkte ergeben sich vielfältige Konsequenzen, die abzuwägen sind:

- ULC ist bereits seit mehreren Jahren am Markt erhältlich und verfügt mittlerweile über einen sehr umfangreichen Widget Set, der sich sehr nahe an Swing orientiert. So werden beispielsweise die verschiedenen Swing-Layouts (GridBagLayout, BorderLayouts, FlowLayout...) unterstützt. Für die Migration einer Fat Client Swing-Anwendung in eine internetfähige, servergestützte Anwendung ist ULC somit besonders geeignet, da ein Grossteil des Codes der Präsentationsschicht direkt wieder verwendet werden kann (teilweise sogar durch ein Search & Replace von Klassennamen und Import-Anweisungen).

- ULC-Anwendungen präsentieren sich auf dem Client mit allen Features einer Fat Client Swing-Anwendung. Eine GWT-Anwendung ist und bleibt eine HTML-basierte Web-Anwendung. Viele Komfortfunktionen, wie Kontextmenüs, Drag & Drop, oder vollständige Tastatursteuerung werden auch von GWT standardmässig nicht unterstützt, so dass GWT-Anwendungen im Look & Feel und Benutzerkomfort bereits eine beachtliche Verbesserung zu einfachem HTML darstellen aber noch nicht an rein Java-basierte GUIs heranreichen.
Ein Beispiel soll dies verdeutlichen: Tabellen werden in GWT - wie in HTML - aus einer Layoutperspektive heraus entwickelt, d.h. durch das Hinzufügen und Setzen von Zellen, Style-Formatierung etc. In ULC werden Tabellen - wie in Swing - mit einem Table Model datenorientiert implementiert und viele Funktionen stehen standardmässig zur Verfügung: Scrollen statt Blättern (mit Lazy-Loading der Zeilen), Änderung von Spaltenbreiten oder der Spaltenreihenfolge durch Drag & Drop, Markieren einer oder mehrerer Zeilen (oder Zellen), Doppelklick, Kontextmenüs.

- GWT-Anwendungen werden in einfaches HTML und JavaScript übersetzt, welches in allen gängigen Browsern sofort ausgeführt werden kann. Die Presentation Engine von ULC setzt auf dem Client-Rechner mindestens ein Java Runtime Environment 1.4 oder höher voraus, was für viele Endanwender einen zusätzlichen Installationsaufwand darstellt.

- GWT führt die Präsentationsschicht vollständig im Client aus. Hierdurch ergeben sich Vorteile bei der Serverlast - insbesondere bei sehr grossen Benutzerzahlen. In der Programmierung muss diese Entkopplung durch eine zweistufige Ereignisbehandlung überbrückt werden, die per Definition immer asynchron erfolgt. In ULC gibt es diese Trennung nicht.

- GWT generiert HTML- und JavaScript-Fragmente, die auch in bereits existierende Web-Anwendungen integriert werden können. Eine Integration von ULC in eine bestehende Web-Anwendung ist nur auf Applet-Ebene möglich und macht nur dann Sinn, wenn grössere Funktionsbereiche (z.B. ganze Seitenabfolgen) neu entwickelt werden sollen.

- ULC wird als kommerzielles Produkt kostenpflichtig vertrieben und supported (Entwickler müssen Lizenzen erwerben, das Hosting von ULC-Anwendungen ist dann kostenfrei). Die Bibliotheken und das Protokoll sind somit zwar Closed Source und proprietär, Erweiterungen des Widget Sets können aber leicht implementiert werden. Das relativ junge GWT wird unter der Apache 2.0 Lizenz als Open Source kostenfrei zur Verfügung gestellt. Die Entwicklung vollständig neuer Widgets erfordert eigene JavaScript-Programmierung und setzt wieder Kenntnisse über die verschiedenen Browser-Implementierungen voraus.

Durch das ereignisgesteuerte Java-Programmiermodell steigern beide Ansätze die Produktivität der Entwicklung von RIA im Vergleich zu klassischen Web-Anwendungen deutlich. Die Vor- und Nachteile beider Technologien sind im Hinblick auf das Einsatzszenario einer Anwendung zu bewerten: Wer sind die Endanwender? Welchen Komfort benötigen sie?

Eine bekannte, geschlossene Benutzergruppe (Extranet), die eine Anwendung tagtäglich, viele Stunden verwendet, kann von dem besonderen Komfort einer ULC-Anwendung hinsichtlich Produktivität (und Akzeptanz) profitieren. Der initiale Aufwand für die Installation einer lokalen JVM fällt dort nicht ins Gewicht. Eine unbekannte, grosse Benutzergruppe (Internet), die eine Anwendung gelegentlich verwendet, kann durch eine GWT-Anwendung hinreichend komfortabel bedient werden und ohne notwendige Installationen auch leichter erreicht werden.