JavaScript fuer Eclipse-Entwickler

Überblick über die Chancen und Möglichkeiten von GWT
    von Papick Taboada und Benjamin Barth
    Das Google Web Toolkit ist eine Sammlung von Werkzeugen und Bibliotheken für die Entwicklung von JavaScript-Anwendungen. Das Toolkit wird sowohl intern von Google als auch weltweit in vielen Projekten eingesetzt. Das Besondere an GWT ist die Vorgehensweise: Ein Compiler liest Java-Quellen ein und generiert JavaScript. Somit können Java-Entwickler auf bestehendes Wissen, Erfahrungen und Werkzeuge aufsetzen. Allerdings hat GWT nicht den Versuch unternommen, das gesamte JDK und Swing im Browser zu unterstützen. Die JDK-Unterstützung ist fragmentarisch (nicht alle Klassen können verwendet werden), und GWT liefert ein eigenes, an HTML orientiertes UI-Komponentenmodell.
    Das Google Web Toolkit hat nicht das Ziel, das Aussehen von Desktopanwendungen im Browser nachzuahmen. Der Fokus der GWT-Entwicklung liegt im Software-Engineering: Einerseits ermöglicht die Entwicklung in Java per Definition den Einsatz von Entwurfsmustern, qualitätssichernden Vorgehensweisen und Tools. Sogar das Debuggen der im Browser laufenden Webanwendung aus dem Java-Code heraus ist nicht nur möglich, sondern sogar sehr einfach. Aber was ist eine GWT-Anwendung? Prinzipiell ist eine mit GWT erzeugte Anwendung ein Script, das vom Browser ausgeführt wird. An dieser Stelle ist die Analogie zu Java und Swing angemessen: Java ist die Programmiersprache, Swing liefert das UI-Komponentenmodell. Zwar bieten Swing und GWT verschiedene Komponentenmodelle, dennoch ist das Programmiermodell vergleichbar. Daher ist eine GWT-Anwendung aus Architektursicht eher einem Rich-Client als einer Webanwendung gleichzusetzen: Die Anwendung wird heruntergeladen, im Browser ausgeführt und kommuniziert mit dem Server. Dabei wird die ursprünglich angesteuerte Webseite nie verlassen („Single Page“-Prinzip), die Anwendung bleibt im Cache des Browsers und muss bei erneutem Besuch nicht noch einmal geladen werden. Moderne Browser stellen die notwendigen Schnittstellen zur Verfügung, um lokal Daten zu speichern, sodass sogar ein Arbeiten im Offlinemodus umsetzbar ist.
    In Bezug auf den ökonomischen Umgang mit den Ressourcen sieht die Bilanz außerordentlich gut aus. Die Anwendung kann im Cache behalten werden und sogar in Scheiben (Split Points) ausgeliefert werden. Das Ausliefern der Anwendung findet also nur einmal statt, es folgt lediglich die Kommunikation mit dem Server für den Datenaustausch beziehungsweise das Ausführen von Befehlen auf dem Server. Das Rendern der Webseiten, das früher zu den Aufgaben des Webservers gehörte, wird jetzt effizient auf die Clients (Browser) verlagert. Die Kommunikation mit dem Server wird auf ein Minimum reduziert. Intelligentes Zwischenspeichern (Cachen) und die Einführung von lokal gespeicherten Daten können die Bilanz noch besser aussehen lassen. GWT bietet neben der üblichen Kommunikation mittels Austausch von mit JSON und XML formatierten Daten auch ein eigenes Verfahren namens GWT RPC, das das Umwandeln ganzer serialisierbarer Java-Objektbäume beherrscht. In Bezug auf GWT RPC gilt die Analogie zu RMI mit einem wesentlichen Unterschied: Während RMI eine generische (und somit nicht schlanke) Laufzeitumgebung für die Interprozesskommunikation umsetzt, wird bei GWT RPC im Kompiliervorgang auf die Kommunikationsschnittstelle optimierter JavaScript-Code generiert.
    Die HTTP-Spezifikation schränkt die Anzahl der offenen persistenten Verbindungen, die ein Browser zu ein- und demselben Server aufbauen kann, auf zwei ein. Da JavaScript der Same Origin Police unterliegt, darf man von einem prinzipbedingten Flaschenhals sprechen. Auch wenn sich Browser nicht an die Spezifikation halten, ist die Anzahl der Verbindungen dennoch beschränkt, meistens auf sechs oder acht Verbindungen. Wie wenig das ist, wird erst dann deutlich, wenn man Webanwendungen unter die Lupe nimmt und untersucht, wie viele Requests für die Anzeige einer Seite durchgeführt werden. Zum Beispiel hat das Laden der Einstiegsseite bei Amazon.de zu beindruckenden 90 Requests geführt (JavaScript, Bilder und CSS-Dateien, die geladen werden). Da nicht alle Anfragen parallel ausgeführt werden können, entstehen beachtliche Latenzen/Wartezeiten, bis alle Ressourcen geladen worden sind. Einerseits liegt dieses Ladeverhalten in der Natur von Webanwendungen, andererseits sind Lösungsansätze, die dieses Problem reduzieren, bekannt. Die Anzahl der möglichen Verbindungen