Einführung in das Google Web Toolkit am Beispiel eines Projektes

Einführung in das Google Web Toolkit am Beispiel eines
Projektes aus der Verkehrstelematik
Seminararbeit im Studiengang
Scientific Programming
vorgelegt von:
Sebastian Schilling
Matr.-Nr: 836371
15. Dezember 2011
1. Betreuer: Prof. Dipl.-Math. Hans Ulrich Stegelmann
2. Betreuer: Dipl.-Math. Michael Schmidt
Abstract.Die Entwicklung einer umfangreichen AJAX-Anwendung allein mit den vorhandenen Web-Techniken HTML, CSS und JavaScript ist äußerst aufwendig. Unterschiedliche
Interpretation der Browser von JavaScript und HTML, verschiedene Implementationen des
XMLHttpRequest-Objekts und Speicherlöcher erschweren die Entwicklung. Das Framework
Google Web Toolkit (GWT ) umgeht diese Probleme und gibt dem Entwickler die Möglichkeit,
AJAX-Anwendungen in der typensicheren Programmiersprache Java zu implementieren, welche später vom GWT-Compiler zu JavaScript compiliert wird.
In meiner folgenden Seminararbeit werde ich auf die grundsätzlichen Funktionen und Möglichkeiten des Frameworks eingehen. Im Schlussteil wird der Einsatz des Google Web Toolkits
am Beispiel eines Projektes aus der Verkehrstelematik dargelegt.
2
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation . . . . . . .
1.2 Allgemeines . . . . . .
1.2.1 Ajax . . . . . .
1.2.2 Was ist GWT?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
6
7
2 Grundlagen
2.1 Projektstruktur . . . . . . . . . . . . .
2.1.1 Die HTML-Datei . . . . . . . .
2.1.2 Die Java-Datei . . . . . . . . .
2.2 Die GWT-Konfiguration über Module
2.3 Hosted- und Web-Modus . . . . . . . .
2.3.1 Hosted-Modus . . . . . . . . .
2.3.2 Web-Modus . . . . . . . . . . .
2.4 Entwicklungszyklus . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
8
9
10
11
11
12
12
.
.
.
.
.
.
.
.
.
.
14
14
14
14
15
17
18
19
20
20
20
4 Der Compiler von GWT
4.1 GWT-Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 JRE-Emulationsbibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
22
23
5 Vor- und Nachteile von GWT
5.1 Vorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
24
24
6 GWT im Einsatz am Beispiel eines Projektes aus
6.1 Projektbeschreibung . . . . . . . . . . . . . .
6.1.1 Anforderungen . . . . . . . . . . . . .
6.1.2 Randbedingungen . . . . . . . . . . .
6.2 Einsatz von GWT im Projekt . . . . . . . . .
26
26
26
26
27
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 GWT-Features
3.1 Gestaltung von Benutzeroberflächen
3.2 Remote Procedure Calls . . . . . . .
3.2.1 RPC mittels RequestBuilder .
3.2.2 GWT-RPC . . . . . . . . . .
3.3 JUnit . . . . . . . . . . . . . . . . .
3.4 XML-Parser . . . . . . . . . . . . . .
3.5 Browser History . . . . . . . . . . . .
3.6 JavaScript Native Interface . . . . .
3.6.1 JSNI-Syntax . . . . . . . . .
3.6.2 Java aus JavaScript aufrufen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
der Verkehrstelematik
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Fazit
28
Abbildungsverzeichnis
29
Literaturverzeichnis
30
3
Eidesstattliche Erklärung
Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema
"Einführung in das Google Web Toolkit am Beispiel eines Projektes
aus der Verkehrstelematik"
selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt
habe, alle Ausführungen, die anderen Schriften wörtlich oder sinngemäß entnommen wurden,
kenntlich gemacht sind und die Arbeit in gleicher oder ähnlicher Fassung noch nicht Bestandteil einer Studien- oder Prüfungsleistung war.
Name: Sebastian Schilling
1 Einleitung
1.1 Motivation
In der Verkehrstelematischen Branche wird häufig eine Client-Server-Architektur für Anwendungen benutzt, da viele Systeme als Echtzeitsysteme ausgelegt sind und Daten, zum Beispiel
von der Verkehrsdichte, ständig aktualisiert werden müssen. Hierzu möchte ich gerne zwei
System-Architekturen kurz vorstellen:
Zum einem wäre ein sogenannter Fat-Client einsetzbar. Ein Fat-Client zeichnet sich dadurch
aus, dass er alle Funktionen der Präsentation und Anwendungslogik bereits implementiert
hat, und somit weitestgehend unabhängig vom Netzbetrieb arbeiten kann. Größter Nachteil
hierbei wäre der hohe Aufwand für die Aktualisierung von Updates, der aber nicht garantiert,
dass alle Systeme mit der gleichen Version laufen. Ein erhöhter Aufwand an Support ist die
Folge.
Hinzu kommen noch die Einrichtung und Wartung von eigenen Infrastrukturen. So müssen
eigene Protokolle entwickelt werden um über eigene Ports zwischen Client und Server kommunizieren zu können.
Eine andere Alternative ist der Thin-Client. Thin-Clients stellen nur die Benutzerschnittstelle zur Verfügung, sodass die Datenverarbeitung durch den Server erfolgt. Mittels der ”ZeroInstallation” wird die Applikation nicht wie üblich installiert und auf der Festplatte gespeichert, sondern nur per URL-Aufruf geladen. Hiermit wird sichergestellt, dass alle Anwender
die gleiche Version nutzen, da die Software zentral zur Verfügung gestellt wird. Nachteil dieser
Systemarchitektur liegt in der Abhängigkeit vom Netzwerk.
Es war ein Anliegen eines Kunden aus der Verkehrstelematischen Branche, bereits installierte
und bekannte Infrastrukturen zu benutzen. Laufende Systeme müssen dadurch nicht komplett
umgestellt werden, Benutzer nicht neu geschult werden und eine gewisse Erfahrung mit der
Sicherheit der Infrastruktur liegt bereits vor. Diese Voraussetzungen werden von einer RichInternet-Applikation erfüllt. Rich-Internet-Aplications sind dynamische Desktoanwendungen,
die im Browser laufen. Folglich werden alle Vorteile des Thin-Clients ausgenutzt und darüber
hinaus auf bekannte Infrastruktur, dem HTTP-Protokoll, zugegriffen.
Um eine Rich Internet Applikation im Browser Umfeld zu entwickeln, kommt zwangsläufig
entweder eine Plug-in basierte oder auf HTML/JavaScript basierte Technologie zum Einsatz.
Die Projektleitung hat sich für die Technologie mittels HTML/JavaScript entschieden. Der
clientseitige Code soll in JavaScript implementiert werden, um bestimmte Benutzeraktionen
schon auf dem Client durchführen zu können. Leider wird JavaScript in jedem Browser anders
interpretiert und für native Java-Entwickler ist ein gewisser Aufwand nötig um sich mit der
neuen Skriptsprache vertraut zu machen.
Das Google Web Toolkit bietet nun nativen Java-Entwicklern die Möglichkeit, sowohl Serveralso auch Client-Seite in Java zu programmieren. Dabei kann vorhandenes Java-Wissen, bekannte Entwicklungsumgebungen und Tools wie gewohnt weiter benutzt werden.
In dieser Seminararbeit werde ich nur die grundsätzlichen Arbeitsweisen und Funktionen
vom Google Web Toolkit vorstellen. Dabei ist es nicht mein Ziel, alle Features ausführlich
darzustellen, sondern Ihnen einen Überblick zu verschaffen. Spezielle Techniken, die für das
5
1.2. ALLGEMEINES
Verkehrstelematische Projekt benötigt werden, werden natürlich vertieft behandelt. Ich werde
mich auf die momentan aktuelle Version 2.4 von GWT beziehen, die am 8. September 2011
veröffentlicht wurde.
1.2 Allgemeines
Heutzutage gibt es immer weniger statische Internetseiten, welche meist nur sporadisch und
von einer Person aktualisiert werden. In den letzten vergangenen Jahren ging die Entwicklung
von Webseiten immer weiter in Richtung Web 2.0. Folgende Definition verfasste Eric Knorr
2003 in einem Fachmagazin für IT-Manager:
”An increase of outsourcing with web services is nothing less than the start of what
Scott Dietzen, CTO of BEA Systems, calls the Web 2.0, where the Web becomes
a universal, standards-based integration platform. Web 1.0 (HTTP, TCP/IP and
HTML) is the core of enterprise infrastructure.” – Eric Knorr [Eri]
Statische Webseiten mit reinem HTML und Hyperlinks wurden durch den User-GeneratedContent ersetzt. Es wurde versucht individuelle Seiten für Besucher bereitzustellen. Um diesen
Aufwand bewältigen zu können, mussten neue Technologien wie Ajax, JavaScript und neue
Infrastruktur auf Seiten des Servers eingesetzt werden.
In meiner Seminararbeit werde ich jedoch nur auf die Client-Seite eingehen, wie es heutzutage
mit dem Toolkit von Google (GWT) möglich ist, Rich-Internet-Apllication zu erstellen.
1.2.1 Ajax
Ajax steht für ”Asynchronous JavaScript and XML”, die das Konzept der asynchronen Datenübertragung zwischen Browser und Server beinhaltet. Dabei handelt es sich um eine Technologie, die im Grunde nur auf dem Client ausgeführt wird. Bei statischen Webseiten wird
für jede Benutzeraktion eine neue HTTP-Anfrage gestartet, da das Hypertext Transfer Protocol(HTTP), ein verbindungsloses Protokoll, keine dauerhafte Verbindung zwischen Sender
und Empfänger ermöglicht. Der Response der HTTP-Anfrage wird auch bei nur kleinen Veränderung des Seiteninhalts den kompletten Seitenaufbau wieder enthalten.
Um diesen unnötigen Traffic und Performance Verlust entgegenzuwirken kommt nun Ajax ins
Spiel. Mit Ajax ist es möglich, nur bestimmte Teile einer Webseite vom Server anzufordern,
die neue Daten enthalten. Meist wird dies durch eine asynchrone Anfrage realisiert, die in
Form, wie der ausgeschriebene Name Ajax vermuten lässt, eines XML-Dokuments erfolgen
kann. Ein anderes beliebtes Format ist das sogenannte JSON-Format(JavaScript Object Notation), welches nicht nur von JavaScript ausgelesen werden kann, sondern auch von vielen
anderen Programmiersprachen1 .
Die Verarbeitung der Benutzeraktionen, für die keine Verbindung zum Server notwendig ist,
"wie beispielsweise das Validieren von Daten, das Verändern von Daten, welche sich im Speicher befinden, und sogar das Navigieren zwischen einzelnen Elementen der Webseite"[Jes],
werden vom Client(Ajax-Engine) übernommen.
Ajax verwendet nur Techniken aus dem Umfeld von DHTML (dynamic HTML). Darunter
fällt auf der Client-Seite neben HTML auch die Skriptsprache JavaScript, mit der man mittels dem XMLHttpRequest-Objekt bei einer Ajax-Applikation, Daten asynchron vom Server
anfordern kann. Die Server-Plattform ist aus der Sicht von Ajax eine Art Blackbox, deren
Hauptaufgabe die Bereitstellung der benötigten Komponenten ist.
1
http://www.json.org/ - Stand: 08.12.2011
6
1.2. ALLGEMEINES
1.2.2 Was ist GWT?
Das Google Web Toolkit (GWT) wurde im Mai 2006 von Google veröffentlicht und unterliegt
der Opensource-Lizenz2 . Es handelt sich dabei um ein Framework, mit dem es möglich ist,
komplexe und interaktive Desktop-ähnliche Ajax-Applikationen zu erstellen. Die gesamte Entwicklung von Client und Server kann in der Programmiersprache Java durchgeführt werden.
Der mitgelieferte GWT-Compiler übersetzt den clientseitigen Java-Quelltext in JavaScipt,
HTML und CSS. Die hieraus entstandenen Dateien können in allen gängigen Browsern dargestellt werden ohne dass der Entwickler selbst auf die unterschiedlichen Interpretationen der
Browser achten muss.
Unterstützt wird das GWT von einigen Entwicklungsumgebungen, wie NetBeans, IntelliJ
IDEA oder Eclipse[UF06]. Der Java-Programmierer kann in seinem bekanntem Java-Umfeld
Swing-ähnliche Oberflächen entwickeln ohne sich speziell mit JavaScript auskennen zu müssen. Das Debuggen des Codes ist auch in Java möglich, so wie das Testen mit dem bekannten
Java-Test-Framework JUnit.
GWT bietet auch Zugriff auf beliebte JavaScript-Bibliotheken oder alten JavaScript-Code,
sodass die Integrität von GWT so flexibel wie möglich ist.
Es stehen externe, umfangreiche Bibliotheken zur Verfügung, die die Entwicklung der graphischen Oberfläche erleichtern. Unter anderem gibt es Textfelder, Dropdownmenüs, Formularfelder, Baumstrukturelemente, Dialogfenster, Menüleisten, etc.
Die Kommunikation mit dem Server kann zum einen, wie bei AJAX-Applikationen üblich, über
das XMLHttpRequest-Objekt erfolgen oder über einen integrierten Remote Prozedure CallMechanismus. Die letztere Möglichkeit setzt jedoch voraus, dass die Server-Implementierung
in Java erfolgt, wogegen dies bei dem XMLHttpRequest-Objek beliebig sein kann.
2
Einige Teile des GWT standen längere Zeit nur als ”closed source” zur Verfügung. Mittlerweile ist jedoch
das ganze GWT Open-Source[HT07]
7
2 Grundlagen
2.1 Projektstruktur
GWT wird mit dem Shell-Tool WebAppCreator ausgeliefert, dass eine typische GWT-Verzeichnisstruktur
anlegt und sie mit Beispielcode füllt. Folgende Zeile bewirkt in der Kommandozeile, das ein
neues Projekt mit der GWT-Struktur erstellt wird. Dies kann auch in einer beliebigen Entwicklungsumgebung mit Hilfe eines Assistenten durchgeführt werden.
webAppCreator -out helloWorld de.sample.helloWorld
Es werden drei Packages erstellt: client, server und shared. Alle Java-Klassen die sich später
im Package cleint befinden, werden vom GWT-Compiler zu JavaScript übersetzt. Das Package
server sollte alle Klassen umfassen, die nur für die Server-Implementation wichtig sind. Für die
Kommunikation zwischen den beiden, stellt GWT das dritte Package shared zur Verfügung.
Später stehen diese Klasse sowohl in JavaScript für den Client als auch in Java für den Server
zur Verfügung[HT07].
2.1.1 Die HTML-Datei
Ich werde im folgendem auf ein älteres HelloWorld-Beispiel von GWT eingehen, da der neue
Sample-Code bereits ein RPC-Mechanismus (s. Kapitel 3.2) beinhaltet.
Das alte GWT-Standard Beispiel,
ist ein einfache Ajax-Anwendung.
Wie in Abbildung 2.1 zu sehen ist,
befinden sich im unterm Bereich
der Webseite zwei Slots, in die später mittels GWT ein Button und
ein Label eingefügt wird. Durch das
Klicken auf den Button wird ein
Text im Label erscheinen. Also eine
einfache AJAX-Anwendung, an der
man aber gut die Struktur und Aufbau der Komponenten vom Google
Web Toolkit erfassen kann.
Folgende HTML-Datei befindet sich
neben einer CSS-Datei im Projekt- Abbildung 2.1: Darstellung der Datei HelloWorld.html
im Browser mit DOM-Elementen
unterordner ”war ”:
1
2
3
4
5
6
7
8
9
10
<html>
<head>
<meta http−e q u i v=" c o n t e n t −type " content=" t e x t / html ;
c h a r s e t=UTF−8">
<l i n k type=" t e x t / c s s " r e l=" s t y l e s h e e t " href=" B s p P r o j e k t . c s s ">
<t i t l e>Web A p p l i c a t i o n S t a r t e r P r o j e c t</ t i t l e>
<s c r i p t type=" t e x t / j a v a s c r i p t " l a n g u a g e=" j a v a s c r i p t "
src=" h e l l o W o r l d / h e l l o W o r l d . nocache . j s "></ s c r i p t>
</head>
<body>
8
2.1. PROJEKTSTRUKTUR
11
<iframe src=" j a v a s c r i p t : ’ ’ " id=" __gwt_historyFrame "
12
s t y l e=" width : 0 ; h e i g h t : 0 ; b o r d e r : 0 "></ iframe>
13
<h1>HelloWorld</h1>
14
<p>
15
This i s an example o f a h o s t page f o r t h e HelloWorld
16
a p p l i c a t i o n . You can a t t a c h a Web T o o l k i t module t o
17
[...]
18
</p>
19
<table align=center>
20
<tr>
21
<td id=" s l o t 1 "></td><td id=" s l o t 2 "></td>
22
</ tr>
23
</ table>
24
</body>
25 </html>
Listing 2.1: Inhalt der HelloWorld.html ohne Kommentare
Die wichtigsten Zeilen der HTML-Datei befinden sich in Zeilen 7/8. Hier wird die JavaScriptDatei helloWorld.nocache.js geladen, die dafür sorgt, dass die richtige GWT JavaScript Datei
für den verwendetet Browser geladen wird. Die Zeilen 11/12 beinhalten ein unsichtbares Frame, dass optional für den Browserverlauf genutzt werden kann (s. Kapitel3.5). Die TabellenElemente mit der ID slot1 und slot2 sind in der HTML-Datei nur optional anzugeben um
später hier ein Button und ein Label platzieren zu können. Alternativ kann die Gestaltung der
Oberfläche auch über sogenannte Pannels (siehe Kapitel 3.1) erfolgen, ohne dass die HTMLSeite direkt bearbeitet wird.
2.1.2 Die Java-Datei
Die wichtigste Java-Datei liegt unter dem Package client. Sie ist um das Interface EntryPoint
erweitert worden, was zwangsläufig zur Implementierung der Methode onModuleLoad() führt.
Dies stellt den Einstiegspunkt der Anwendung dar.
1 public c l a s s HelloWorld implements EntryPoint {
2
public void onModuleLoad ( ) {
3
f i n a l Button button = new Button ( " C l i c k me" ) ;
4
f i n a l L ab el l a b e l = new L ab el ( ) ;
5
6
button . a d d C l i c k H a n d l e r (new C l i c k H a n d l e r ( ) {
7
@Override
8
public void o n C l i c k ( C l i c k E v e n t e v e n t ) {
9
i f ( l a b e l . getText ( ) . e q u a l s ( "" ) ) {
10
l a b e l . s e t T e x t ( " H e l l o World ! " ) ;
11
} else {
12
label . setText ( "" ) ;
13
}
14
}
15
});
16
RootPanel . g e t ( " s l o t 1 " ) . add ( button ) ;
17
RootPanel . g e t ( " s l o t 2 " ) . add ( l a b e l ) ;
18
}
19 }
Listing 2.2: gekürzter Java-Code der alten Sampler-Codes
9
2.2. DIE GWT-KONFIGURATION ÜBER MODULE
In Zeile 3 und 4 werden sogenannte GWT-Widgets erstellt. In diesem Beispiel handelt es sich
zum einen um einen Button und zum anderen um ein Label. Im Java-Code werden sie als
normale Objekte behandelt, während sie im Web- oder Host-Modus (siehe Kapitel 2.3) später
als direkte Schaltfläche oder Label dargestellt werden. Diese Objekte werden in Zeile 16/17 in
der HTML-Seite platziert. Dabei repräsentiert das RootPanel das DOM des body-Elementes
der HTML-Datei. Die beiden Tabellen-Elemente slot1 und slot2 wurden zuvor in der HTMLDatei definiert und jetzt benutzt um die Widgets in die HTML-Seite einzufügen.
Ab Zeile 6 wird dem Button ein ClickHandler übergeben, der entsprechende Aktionen im
Falle eines Klicks ausführt.
2.2 Die GWT-Konfiguration über Module
Ein GWT-Projekt wird über eine XML-Datei konfiguriert und verwaltet. Eine Vielzahl von
Ressourcen sind auf unterschiedliche Ordnerstrukturen verteilt und müssen von der GWTShell bzw. dem GWT-Compiler zur Verfügung gestellt werden, damit der Client-Code zu
JavaScript übersetzt werden kann. Später im Web-Modus wird diese Konfigurationsdatei nicht
mehr benötigt.
Ein GWT-Projekt muss über ein oder mehrere Module verfügen. Ein Modul besteht aus
Client-Code, optional auch Server-Code, mindestens einer HTML-Datei, die den Client-Code
einbindet und anderen statischen Ressourcen, wie etwa CSS-Dateien oder Bilder.
1 <?xml version=" 1 . 0 " e n c o d i n g="UTF−8" ?>
2 <module rename−t o= ’ h e l l o w o r l d ’>
3
< !−− I n h e r i t t h e c o r e Web T o o l k i t s t u f f . −−>
4
< i n h e r i t s name= ’ com . g o o g l e . gwt . u s e r . User ’ />
5
6
< !−− I n h e r i t t h e default GWT s t y l e s h e e t . −−>
7
< i n h e r i t s name= ’ com . g o o g l e . gwt . u s e r . theme . c l e a n . Clean ’ />
8
9
< !−− Other module i n h e r i t s −−>
10
11
< !−− S p e c i f y t h e app e n t r y p o i n t c l a s s . −−>
12
<entry −p o i n t c l a s s= ’ de . sample . c l i e n t . HelloWorld ’ />
13
14
< !−− S p e c i f y t h e p a t h s f o r t r a n s l a t a b l e code −−>
15
<s o u r c e path= ’ c l i e n t ’ />
16
<s o u r c e path= ’ s h a r e d ’ />
17 </ module>
Listing 2.3: XML-Konfiurationsdatei des HelloWorld-Beispiels
Jedes Modul muss einen Einstiegspunkt definieren, der beim Starten der Applikation vom
Compiler als erstes geladen werden soll. In der XML-Datei wird, wie in Zeile 12, der gesamte
Klassenpfad angegeben, der die Schnittstelle EntryPoint aus der GWT-API implementieren
muss.
Die Pfade zum Quellcode werden über die XML-Element ”source path” (s. Zeile 15/16) hinzugefügt.
Alle Pfadangaben zu öffentlich zugänglichen Ressourcen, wie etwa Bilder oder CSS-Dateien,
werden über die XML-Element ”public path” hinzugefügt. Es werden sämtliche Ressourcen,
die unter diesem öffentlichen Pfad zu finden sind, in das Ausgabeverzeichnis des Moduls ko-
10
2.3. HOSTED- UND WEB-MODUS
piert. Der Entwickler kann nun über die Modul-URL1 auf die Ressourcen zugreifen ohne den
kompletten Pfad kennen zu müssen[HT07].
Mit dem Element ”inherits” kann ein Modul von anderen Modulen erben. Dabei werden
alle Einstellungen und Daten des angegebenen Moduls kopiert. In Zeile 4 des Listings 2.3
wird das Modul des Projektes um das GWT-Modul User erweitert, welches einen Großteil
der GWT-Funktionalität abdeckt[UF06]. Greift man auf das JUnit-Testen zurück, so muss
hier das Module JUnit hinzugefügt werden.
Die GWT-Klassenbibliothek besteht selbst aus folgenden Modulen: User, HTTP, JSON, JUnit
und XML [Goo11f].
2.3 Hosted- und Web-Modus
Unter GWT existieren zwei Modi, in der die GWT-Anwendung gestartet werden kann. Der
Hosted-Modus wird für das Entwickeln und Testen benutzt, wogegen der Web-Modus das
Endprodukt bereitstellt.
2.3.1 Hosted-Modus
Mit dem Starten der GWT-Shell wird der sogenannte Hosted-Modus, ab Version 2.0 auch
als Development Mode bezeichnet, gestartet. Dabei wird der clientseitige Java-Code nicht in
JavaScript kompiliert, sondern in der Java Virtual Machine als Java-Bytecode interpretiert.
Alle notwendigen Dateien, die zum Starten der Anwendung benötigt werden, ermittelt die
GWT-Shell durch die zuvor konfigurierte XML-Datei der Moudl-Definition.
Das Modul kann über einen beliebigen Browser, in dem das GWTPlugIn installiert wurde, über eine
von GWT generierte URL gestartet
und dargestellt werden. Die Kommunikation zwischen dem GWTModul und dem Browser erfolgt
über TCP. Die GWT-Shell sorgt im
Hosted-Modus für die Synchronisation zwischen den beiden KompoAbbildung 2.2: Kommunikation zwischen GWT-Shell nenten.
und Browser im Hosted-Modus[Goo11c] Alle Fehler und Warnungen werden
von einer GWT-Hosed-Modus-GUI
oder direkt der Entwicklungsumgebung in einem Steuerfenster dargestellt. Des Weiteren ist
ein logging auf unterschiedlichen Ebenen möglich[Goo11h].
Für die Serverseite wird von GWT eine eingebettete Version der Tomcat-Servlet-Engine mitgeliefert, die standardmäßig auf Port 8080 läuft. Konfigurationen bzgl. Tomcat können im
entsprechendem Tomcat-Verzeichnis vorgenommen werden[CC08][HT07].
Zwar sind Anwendung im Hosted-Modus langsamer, aber der größte Vorteil liegt im Debuggen
des client- oder serverseitigen Java-Quellcodes.
1
GWT.getModuleBaseURL()
11
2.4. ENTWICKLUNGSZYKLUS
2.3.2 Web-Modus
Der Web-Modus, auch als Production Mode bekannt, wird durch den GWT-Compiler erreicht.
Alle clientseitigen Java-Dateien werden durch den Java-to-JavaScript-Compiler zu reinem JavaScript übersetzt. Die resultierenden Web-Ressourcen werden im Unterordner ”www” abgelegt,
kann aber anders konfiguriert werden.
Beim Ausführen des Web-Modus wird im Client kein Browser-PlugIns oder die JVM benötigt. Der Webserver hat auch keine expliziten Voraussetzungen, sondern hängt von der eigenen
Implementierung ab. Wird das von GWT angebotene GWT-RPC benutzt, so muss auch die
Server-Implementierung in Java erfolgen.
Die Anwendung wird im Web-Modus so dargestellt, wie sie später im produktiven Einsatz
aussehen wird. Die Anwendung verhält sich deutlich schneller als im Hosted-Modus, da der
Aufwand für die Emulation entfällt.
2.4 Entwicklungszyklus
Hat man sich entschlossen in GWT ein Projekt zu entwickeln, so muss man immer wieder
einen gewissen Entwicklungszyklus durchlaufen.
Abbildung 2.3: Generischer Lebenszyklus der GWT-Anwendungsentwicklung[HT07]
Zuerst sollte immer die klassische-GWT-Projektstruktur angelegt werden. Darüber hinaus
sollten weitere benötigte Dateien, wie weitere HTML-, CSS- oder Java-Dateien, bzw. Fremdbibliotheken dem Projekt hinzugefügt werden.
In Phase 2 folgt die Entwicklungsperiode, die meist mehrere Zyklen umfasst. Sie schließt auch
das Testen der Anwendung im Hosted-Modus mithilfe des eines Browser ein. Da der clientseitige Code im Hosted-Modus in Java-Bytecode vorliegt, ist es möglich sowohl den serverseitigen
12
2.4. ENTWICKLUNGSZYKLUS
also auch den clientseitigen Code zu debuggen und Fehler schneller zu beheben.
Ist die Phase des Entwickelns und Testens abgeschlossen, so wird der Client-Code mit dem
GWT-Compiler in JavaScript konvertiert, um ihn im Webmodus ausführen zu können.
Die finalen Phasen befassen sich mit der Bereitstellung der Anwendung auf einem Webserver. Auch hier sollte das Projekt noch mal auf die Funktionalität, u.a. auch in verschiedenen
Browser, geprüft werden[HT07].
13
3 GWT-Features
3.1 Gestaltung von Benutzeroberflächen
Das Google Web Toolkit stellt nur eine kleine Sammlung an Oberflächenelementen zur Verfügung. Häufig werden in diesem Zusammenhang die Fachwörter Widget und Panel benutzt.
Widgets sind Komponenten mit den der Anwender interagiert. Darunter fallen zum Beispiel
Buttons, TextBoxes, etc.1 Panels unterstützen die Strukturierung des User-Interfaces. Mit
ihnen können die Widgets beliebig platziert werden.
Um eine größere Auswahl an Widgets zu bekommen, besteht die Möglichkeit externe Bibliotheken einzufügen. In diesem Zusammenhang sind besonders die Bibliotheken EXT-GWT 2
und SmartGWT 3 zu erwähnen, da sie zahlreiche Rich-Client-Komponenten mit sich bringen.
3.2 Remote Procedure Calls
Die meisten Web-Anwendungen benötigen eine Möglichkeit, Informationen zwischen dem Client und dem Server auszutauschen. Bei einer GWT-Applikation besteht die Möglichkeit, dass
ein Client Methoden, Funktionen oder Prozeduren aufrufen kann, die dann direkt auf dem
Server ausgeführt werden. Dieses Verfahren heißt Remote Procedure Calls (RPC ).
Da die Kommunikation nur auf der vorhandenen Infrastruktur erfolgen kann, wird hier das
HTTP-Protokoll verwendet. Das hat zur Folge, dass nur reine Zeichenketten übertragen werden können und keine dauerhafte Verbindung zwischen Client und Server vorhanden ist.
Moderne Browser enthalten ein spezielles JavaScript-Objekt namens XMLHttpRequest, welches eine asynchrone Kommunikation zwischen Client und Server ermöglicht. Dieses Objekt
ist die Basis für alle Remote Procedure Calls.
Das Google Web Toolkit bietet einen Ansatz für RPC, der dem Programmierer die Möglichkeit
bietet, Java-Objekte zu übertragen. Natürlich wird weiterhin nur über das HTTP-Protokoll
kommuniziert. Jedoch ist die Schnittstelle für den Anwender so gekapselt, dass dieser sich mit
der Emulation der Java-Klassen nicht auseinander setzen muss[Ste07].
Im Folgendem werde ich zum einem das klassische RPC mittels der Klasse RequestBuilder
vorstellen und zum anderen das gekapselte GWT-RPC.
3.2.1 RPC mittels RequestBuilder
Die Klasse RequestBuilder bietet die Möglichkeit, Anforderungen an den Server zu erstellen,
abzuschicken und auf die vom Server zurückgeschickten Daten Zugriff zu erhalten. Die Daten
können sowohl via GET als auch via POST gesendet werden. Hier liegt die Einschränkung,
dass die Daten in reiner Textform vorliegen müssen. Hier kann man jedoch das Datenformat selbst bestimmten. GWT bietet Klassen zum Parsen von XML-Dokumenten und JSONAusdrücken an.
1
http://code.google.com/intl/de-DE/webtoolkit/doc/latest/DevGuideUiWidgets.html
08.11.2011
2
http://www.sencha.com/products/extgwt - Stand 08.12.2011
3
http://code.google.com/p/smartgwt/ - Stand 08.12.2011
14
-
Stand:
3.2. REMOTE PROCEDURE CALLS
Da der Einsatz vom RequestBuilder unabhängig von der Server-Implementierung ist, betrachten wir nur die Client-Seite.
Der Konstruktor des ReuestBuilder nimmt zwei Parameter entgegen. Zum einen eine der
beiden Methoden, die als statische Konstanten repräsentiert werden: ReuestBuilder.GET oder
RequestBuilder.POST. Zum anderen muss die URL dem Konstruktor übergeben werden.
1 R e u e s t B u i l d e r b u i l d e r = new R e u e s t B u i l d e r ( R e u e s t B u i l d e r . POST,
2
"/ rpc / testingRpc " ) ;
Listing 3.1: Initialisierung des RequestBuilder
Über den RequestBuilder lassen sich auch Eigenschaften der Anforderung festlegen, wie
Header-Informationen, Anmeldeinformationen oder Timeout-Intervall. Um nun eine Anfrage
an den Server zu schicken wird die Methode sendRequest() des RequestBuilder-Objekts
aufgerufen. Hierbei werden alle Daten, die der Anfrage hinzugefügt werden sollen und ein
Handler, der die Serverantwort behandelt, angefügt. Die RequestException tritt im Falle
eines fehlerhaften Sendens auf.
1 Request r e q = null ;
2 try {
3
r e q = b u i l d e r . sendRequest ( "POSTData=myData&a c t i o n=save2Db " ,
4
new R e q u e s t C a l l b a c k ( ) {
5
public void onError ( Request r , Throwable e } ) { }
6
public void onResponeReceived ( Request r ,
7
Response r e s p o n s e } ) { . . . }
8
});
9 } catch ( R e q u e s t E x c e p t i o n e ) { }
Listing 3.2: Erstellen einer RequestBuilder -Anforderung
Erfolgt eine Ergebnisrückgabe durch den Server, so wird die Methode onResponseRecived()
aufgerufen. Den Stautscode der Server-Antwort kann über die Methode getStatusCode()
überprüft werden.
Die Methode des RPC mittels dem RequestBuilder eignet sich besonders, falls man auf alte
Server-Implementationen zurückgreifen möchte, die nicht in Java geschrieben sind.
3.2.2 GWT-RPC
Mittels des GWT-RPC-Mechanismus ist es möglich Java-Objekte ohne größeren Mehraufwand zwischen Client und Server zu verschicken. Die Verbindung wird vom Client eingeleitet
und über ein von GWT bereitgestelltes Proxy-Objekt übergeben. Dieses Objekt serialisiert
die Java-Klassen als Textdatenstrom und schickt sie an den Server weiter. Auf der Server-Seite
wird die Anforderung des Clients durch ein von GWT bereitgestellten Java-Servlet empfangen und wieder deserialisiert. Die hieraus gewonnen Daten werden an einen Dienst auf dem
Server weitergereicht. Wird eine Antwort an das GWT-Servlet übermittelt, so serialisiert das
Servlet diese Antwort und schickt sie wieder zum Client. Dort wird die Antwort wieder vom
GWT-Proxy empfangen, deserialisiert und als Objekt zur Verfügung gestellt[Ste07].
Das Datenformat von GWT-RPC ist weder JSON noch XML. GWT verwendet ein eigenes
Format[UF06].
In Java wird diese Konzept folgendermaßen umgesetzt:
Zuerst wird eine Service-Schnittstelle definiert, über die Client und Server kommunizieren
15
3.2. REMOTE PROCEDURE CALLS
Abbildung 3.1: Übersicht der GWT-RPC Klassen[Goo11g]
können. Das Interface muss um die Klasse RemoteService erweitert werden, was nur zur
Markierung der Schnittstelle als RPC-Interface dient.
1 public i n t e r f a c e MyRemoteService extends RemoteService {
2
public S t r i n g doSomething ( S t r i n g u s e r T e x t ) ;
3 }
Listing 3.3: Erweiterung der Schnittstelle RemoteService
Nun wird sowohl auf dem Client als auch auf dem Server diese Schnittstelle implementiert. Wie
in der Abbildung 3.1 zu sehen ist, muss das Servlet noch um die Klasse RemoteServiceServlet
erweitert werden. Das RemoteServiceServlet ist eine Subklasse eines gewöhnlichen HTTPServlet und kümmert sich später automatisch um das Serialisieren und Deserialisieren der
Parameter und Rückgabewerte. Zu beachten ist, dass sowohl die Methodenparameter als auch
der Rückgabewert serialisierbar sein muss.
1 public c l a s s MyServiceImpl extends R e m o t e S e r v i c e S e r v l e t
2 implements MyRemoteService {
3
public S t r i n g doSomething ( S t r i n g u s e r T e x t ) {
4
// Ausfuehrung d e s Codes a u f dem S e r v e r
5
return s t r ;
6
}
7 }
Listing 3.4: Erweiterung der Schnittstelle RemoteServiceServlet auf dem Server
Um nun eine asynchrone Kommunikation gewährleisten zu können, muss noch eine weitere
Schnittstelle definiert werden. Der Bezeichner dieser Schnittstelle ist im GWT-Konzept explizit an den Namen der Serverschnittstelle gekoppelt. Es wird nur der Token Async angehangen.
Es werden die gleichen Methoden implementiert, die in der Serviceschnittstelle definiert wurden. Jede Methode wird zusätzlich noch um den Parameter vom Typ AsyncCallback ergänzt,
16
3.3. JUNIT
an dem später erkannt werden kann, ob der asynchrone Aufruf erfolgreich war oder nicht. Dies
hat zur Folge das alle Methoden in der asynchronen Schnittstelle keine Rückgabewerte besitzen.
1 i n t e r f a c e MyRemoteServiceAsync {
2
public void doSomething ( S t r i n g userText , AsyncCallback cb ) ;
3 }
Listing 3.5: Asynchrone Schnittstelle
Um Daten zwischen Client und Server austauschen zu können, muss nur noch der Dienst aus
dem Clientbrowser aufgerufen werden. Zuvor muss noch ein Proxy-Objekt initialisiert werden,
das durch die GWT-Methode create automatisch erzeugt wird.
1
2
3
4
5
6
7
8
9
MyRemoteServiceAsync proxy =
( MyRemoteServiceAsync ) GWT. c r e a t e ( MyRemoteService . c l a s s ) ;
proxy . doSomething ( " F i r s t T e x t " , new AsyncCallback ( ) ( ) {
public void o n S u c c e s s ( Object r e s u l t ) {
// e r f o l g r e i c h e S e r v e r a n t w o r t
// do s t h .
}
public void o n F a i l u r e ( Throwable ex ) { }
});
Listing 3.6: Service Aufruf
Der in der Methode mitgelieferte AsyncCallback-Handler behandelt das vom Server zurückkommende Ergebnis.
Abschließend ist diese Variante des Remote Process Calls sicherlich einfacher für den Programmierer, da er sich um den Transport der Java-Objekte selbst nicht kümmern muss. Doch
zu beachten ist, dass diese Methode voraussetzt, dass der serverseitige Dienst auch in Java
geschrieben sein muss.
3.3 JUnit
JUnit ist ein Framework zum Testen von Java-Programmen bzw. deren Bestandteilen (Units).
Mittlerweile gibt es ähnliche Test-Frameworks für viele andere Programmiersprachen unter
dem Namen xUnit. Ziel der Test-Frameworks ist das automatisierte Testen einzelner Klassen
oder Methoden in einem umfangreichen Projekt.
Das Google Web Toolkit bietet eine Möglichkeit die JUnit-Umgebung mit der GWT-Umgebung
zu verbinden. Dies geschieht über die Klasse GWTTestCase, welche von der JUnit-Klasse
TestCase abgeleitet ist.
In der Grundeinstellung laufen Tests im Hosted-Modus als normaler Java-Bytecode in einer
JVM. Um die Test im Web-Modus laufen zu lassen, muss die Systemeigenschaft gwt.args definiert werden um Argumente an GWT weitergeben zu können. Dies ist notwendig, da die
Tests in der JUnit-Shell ausgeführt werden und nicht in der GWT-Shell[Goo11e].
Alle Testklassen müssen von der Klasse GWTTestCase abgeleitet werden, die wiederum voraussetzt, dass die Methode getModuleName implementiert wird. Diese muss den vollständigen
Namen des Moduls zurückliefern, welcher vom GWT für die Initialisierung des Toolkits benötigt.
17
3.4. XML-PARSER
Zum Erstellen eines Testfalles bietet GWT ein Tool mit dem Namen junitCreator4 . Das
Tool generiert ein Anfangstestszenario, in dem bereits Grundgerüste zum Testen vorhanden
sind, die sowohl im Host-Modus als auch im Web-Modus getestet werden können.
1 /∗ ∗
2 ∗ GWT JUnit t e s t s must extend GWTTestCase .
3 ∗/
4 public c l a s s StockWatcherTest extends GWTTestCase {
5
6
/∗ ∗
7
∗ Must r e f e r t o a v a l i d module t h a t s o u r c e s t h i s c l a s s .
8
∗/
9
public S t r i n g getModuleName ( ) {
10
return "com . g o o g l e . gwt . sample . s t o c k w a t c h e r . StockWatcher " ;
11
}
12
13
/∗ ∗
14
∗ Add a s many t e s t s a s you l i k e .
15
∗/
16
public void t e s t S i m p l e ( ) {
17
a s s e r t T r u e ( true ) ;
18
}
19 }
Listing 3.7: GWT-JUnit Testklasse
Darüber hinaus ist es mit der Klasse GWTTestCase möglich, asynchrone Abläufe, wie etwa beim
RPC, zu testen. Um den Test in den asynchronen Modus zu versetzen, bietet GWTTestCase die
Methode delayTestFinish(), welche die Verzögerung des Tests festlegt. Um einen erfolgreichen asynchronen Testfall zu bekommen, muss die Methode finishTest() explizit aufgerufen
werden. Dies soll sicherstellen, dass zum Beispiel ein RPC-Aufruf überhaupt zurückgekommen
ist.
Die JUnit-Erweiterung GWTTestCase bietet Java-Entwicklern das Testen von clientseitigen als
auch von serverseitigen Code. Vorteilhaft ist auch hier wieder, dass Entwickler sich nicht in
neue Test-Frameworks einarbeiten müssen und ihr vorhandenes Wissen nutzen können.
3.4 XML-Parser
Die Extensible Markup Language (XML) ist eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten in Form von Textdaten und wird oft zum Datenaustausch zwischen Client und Server benutzt.
GWT bietet einen auf DOM (Document Object Model) basierten XML-Parser, der die XMLDatei als Objekt-Baum aufbereitet. Dabei nutzt GWT die Tatsache, dass moderne Browser in
der Lage sind, XML zu analysieren und einen DOM-Baum zu erstellen. Auf die unterschiedlichen Browserverhalten muss nicht mehr geachtet werden, da GWT das clientseitge Parsen
über die Klasse XMLParser steuert.
1 Document doc = XMLParser . p a r s e ( r e s p o n s e T e x t ) ;
2 Element r o o t = doch . getDocumentElement ( ) ;
3
4
Genaue Syntax des junitCreator-Tool ist unter http://code.google.com/intl/de-DE/webtoolkit/doc/
latest/tutorial/JUnit.html zu finden.
18
3.5. BROWSER HISTORY
4 NodeList c h i l d r e n = r o o t . g e t C h i l d N o d e s ( ) ;
5 f o r ( int i =0; i < c h i l d r e n . g e t Le n gt h ( ) ; i ++){
6
doSthWithNode ( c h i l d r e n . item ( i ) ) ;
7 }
Listing 3.8: Parsen einer XML-Datei
Mithilfe der DOM-API kann der Baum durchlaufen werden.
3.5 Browser History
Ein klassisches Problem von Ajax-Anwendungen ist die Aufhebung des Mechanismus der
ZURÜCK-Schaltfläche des Browsers. Der Browser dokumentiert in seiner History nur das
Laden einer neuen Seite. Das asynchrone Nachladen von Daten erkennt der Browser nicht
als Aufruf einer neuen Seite an. Der Benutzter hingegen erkennt meistens, dass sich Inhalte
auf der Seite ändern, und erwartet durch das Anklicken der ZURÜCK-Schaltfläche zu den
vorherigen Inhalten zu gelangen.
GWT hat diese Problem mit Hilfe eines versteckten Frames gelöst. Dazu ist folgende Zeile in
der HTML-Datei notwendig:
<iframe src="javascript:’’" id="__gwt_historyFrame" style="width:0;
height:0;border:0"></iframe>
Um diesen Service nutzen zu können, muss ein Event-Handler geschrieben werden, der die
Schnittstelle ValueChangeHandler implementiert, und diese beim Hisotry-Objekt registriert.
1 H i s t o r y . addValueChangeHandler (new ValueChangeHandler<S t r i n g >() {
2
public void onValueChange ( ValueChangeEvent<S t r i n g > e v e n t ) {
3
i f ( e v e n t . g e t V a l u e ( ) . e q u a l s ( " token1 " ) ) {
4
// S t e l l e Zustand wie an Token1 w i e d e r h e r
5
}
6
// . . .
7
});
Listing 3.9: Registrierung der benutzerdefinierten HistoryListener beim Objekt History
Sobald der Listener registiert wurde, kann ein Seitenwechsel emuliert werden. Der Programmierer selbst muss festlegen, wann ein Stand einer neuen Seite erreicht worden ist. Dies
geschieht durch die Erstellung eines neuen Verlaufs-Token. Wird im Quelltext der Befehl
History.newItem(String) ausgeführt, so wird der URL im Browser das gesetzte Token mittels ’#’ angehängt. Dem Benutzer ist es nun möglich, durch die ZURÜCK-Schaltfläche zwischen den gesetzten Token hin und her zu springen.
Ist ein Token gesetzt, so wird im Browser im verborgenen Frame eine neue Seite geladen, was
der Browser als neu geladene Seitenansicht anerkennt und sie dem Verlauf hinzufügt. Des Weiteren wird die Methode onValueChange() der Schnittstelle ValueChangeHandler aufgerufen
um eine Inhaltsveränderung anzuzeigen, die wiederum vom Programmierer erstellt werden
muss.
19
3.6. JAVASCRIPT NATIVE INTERFACE
3.6 JavaScript Native Interface
In manchen Fällen kann es sinnvoll sein, auf bestehenden JavaScript-Code oder externe
JavaScript-Bibliotheken aus Java heraus zugreifen zu können. GWT stellt hierzu das JavaScript Native Interface (JSNI ) zur Verfügung. Darüber können JavaScript-Aufrufe direkt
als native Aufrufe in den Java-Quellcode implementiert werden, Java-Felder können aus JavaScript auslesen werden oder Java-Methoden können in JavaScript einbauen werden.
3.6.1 JSNI-Syntax
In Java werden JavaScript-Methoden als native Methoden deklariert. Der JavaScript-Code
wird hinter der Methodendeklaration als Kommentar /*-{JavaScript}-*/ implementiert,
der mit einem Semikolon abgeschlossen wird. Der Umgang der Methoden erfolgt wie mit gewöhnlichen Java-Methoden.
Um aus JavaScript auf das Browserfenster oder deren Inhalte zugreifen zu können, stellt GWT
die Variable $wnd und $doc zu Verfügung. Diese Variablen entsprechen den Variablen window
und document im JavaScript Umfeld.
3.6.2 Java aus JavaScript aufrufen
Es ist auch wieder möglich, aus der JavaScript-Umgebung Ereignisse der Java-Welt zu übermitteln oder Methoden oder auf Felder zu zugreifen. Für Felder wird folgende Syntax benutzt:
[Instanz.]@Klassenname::Feldname
und diese für Methodenaufrufe:
[Instanz.]@Klassenname::MethodenName(Signatur)(Parameter)
Die Instanz ist optional anzugeben, je nach dem ob es eine Methode einer Instanz oder eine
statische Methode ist. Der Klassenname ist immer als vollqualifizierter Namen einer Klasse
anzugeben, dh. mit der gesamten Paketstruktur.
Die Signatur der Methode setzt sich aus den Typen der Parameter zusammen. Primitive Datentypen werden dabei einem Buchstaben zugeordnet. Klassen beginnen mit einem L, gefolgt
von dem vollqualifizierten Namen.
Tabelle 3.1: Kodierung der Methodensignatur für Java-Aufrufe aus JavaScript-Methoden
Datentyp
Kodierung
boolean
Z
byte
B
char
C
short
S
int
I
long
J
float
f
double
D
vollqualifierzter Klassenname L vollqualifierzter Klassenname;
Das Austauschen von primitiven Datentypen und eines Strings kann ohne Probleme vollzogen werden. Jedoch ist die Übergabe von Objekten nur begrenzt sinnvoll. Alle Objekte aus
20
3.6. JAVASCRIPT NATIVE INTERFACE
JavaScript werden in Java als JavaScriptObjekt gespeichert. Ein Zugriff aus Java ist nicht
möglich. Einzig die Rückgabe an JavaScript, stellt das Originalobjekt wieder her.
21
4 Der Compiler von GWT
4.1 GWT-Compiler
Der GWT-Compiler stellt das Herzstück des Google Web Toolkits dar. Er compiliert den
Java-Quellcode zu JavaScript. Dabei werden zur Zeit folgende Browser unterstützt: Firefox, Internet Explorer, Safari, Google Chrome und Opera[Goo11b]. Für jeden unterstützten
Browser wird eine eigene JavaScript-Datei angelegt. Wird zusätzlich noch eine Internationalisierung für verschiedene Sprachen benutzt, so führt GWT, wie in Abbildung 6.1 dargestellt,
eine Permutation der Browser-Dateien durch.
Das sogenannte Bootstrap-Skript,
das sich in der .nocache.js Datei versteckt, entscheidet beim Seitenaufruf welche spezielle JavaScript-Datei, abhängig vom Ort
und Browser, angefordert werden
soll. Die verschiedenen JavaScriptDateien liegen als <md5>.cache.html
vor.
Der Compiler bezieht die Informationen, die für das Compilieren notwendig sind, aus der XMLModulkonfigurationsdatei. Beginnend in der Eintrittspunktklasse sucht und folgt der Compiler allen Abhängigkeiten, die für
Abbildung 4.1: Erstellung verschiedener JavaScript- das Compilieren der Java-Klassen
Dateien
je
nach
Browser
und notwendig sind. Marker-Interfaces,
Sprache[SRM08]
wie zum Beispiel IsSerializable,
kennzeichnen dem Compiler serialisierbare Klassen. Des Weiten werden auch Annotaions im
Java-Code interpretiert.
GWT nimmt auch eine Codeoptimierung vor. Im Gegensatz zum Java-Standard-Compiler
verwirft der GWT-Compiler alle Klassen, Methoden und Attribute, die nicht von der Applikation benutzt werden. Ein weiterer Aspekt, um die JavaScript-Datei so klein wie möglich
zu halten, ist die Umbenennung der Variablen und Methoden in einzelne Buchstaben. Somit
wird alles in JavaScript komprimiert und kann für den Benutzer so gut wie nicht gelesen
werden. GWT bietet aber drei verschiedene Stilmodi an, die bestimmen, wie der resultierende
JavaScript-Code aussehen soll. Der Standardmodus ist obfuscate, der den Code bestmöglich
komprimiert[HT07].
function b{return this.c + ’@’ + this.d();}
Der zweite Stil heißt pretty und stellt den gleichen Quellcode wie oben dar:
function toString{
return this._typeName + ’@’ + this._hashCode();
}
22
4.2. JRE-EMULATIONSBIBLIOTHEK
Der letzte Stil heißt detailed und enthält gegenüber dem vorherigem Stil noch den vollständigen Klassennamen im Methodennamen. Somit ist es für den Betrachter einfacher auf den
Java-Quellcode zu schließen:
function java_lang_Object_toString{
return this.java_lang_Object_typeName + ’@’ + this.hashCode()__;
}
Außerdem erfordert der GWT-Compiler ab Version 1.5, dass der Quelltext mit der Java 1.5Syntax kompatibel sein muss[Goo11a].
4.2 JRE-Emulationsbibliothek
Abhängig davon, welche GWT-Version verwendet wird, gibt es unterschiedliche Einschränkungen auf die unterstützten Klassen aus der Java-Standartklassenbibliothek. In der GWTVersion 1.4 wird die JSE-Version 1.4 unterstützt und ab der GWT-Version 1.5 die JSE-Version
5.0. Somit ist es ab der GWT-Version 1.5 unter anderem möglich, Generics, Enums, Annotations und erweiterte Schleifen zu nutzen. Aus JSE-Version 5.0 werden die meisten Klassen aus
den folgenden Packages unterstütz: java.lang, java.lang.annotation, java.math, java.io,
java.sql, java.util, java.util.logging[Goo11d].
Alle primitiven Datentypen aus Java, sowie java.lang.Object, java.lang.String und Arrays werden ohne Einschränkungen unterstützt. Das Package java.util enthält alle wichtigen
Datenstrukturen wie Maps, Lists und Arrays.
Es gibt keinen ganzzahligen 64-bit-Typ long in JavaScript. Ab GWT 1.5 wird der long-Wert
durch ein Paar von 32-bit Integer-Zahlen simuliert.
Eigene Exceptions, sowie die Schlüsselwörter try, catch, finally werden unterstützt. Die
Ausgabe des Stack Traces mit der Methode Throwable.getStackTrace() ist im Web-Modus
nicht zugelassen[Ste07].
JavaScript wird im Browser in einer sogenannten Sandbox ausgeführt. Das hat zur Folge, dass
JavaScript im Allgemeinen kein Zugriff auf das Dateisystem hat und somit weder Daten lesen
noch schreiben kann. GWT bietet mit dem Package java.io logging in eine externe Datei an.
Eine genauere Übersicht der Emulationsbibliothek ist unter http://code.google.com/intl/
de-DE/webtoolkit/doc/latest/RefJreEmulation.html (Stand: 03.12.2011) zu finden.
23
5 Vor- und Nachteile von GWT
5.1 Vorteile
Neben den ganzen Features, die das Google Web Toolkit anbietet, möchte ich noch einige
weitere Vorteile von GWT auflisten.
Das Google Web Toolkit bietet die Möglichkeit, clientseitigen Code in Java zu schreiben und
später ihn in JavaScript übersetzten zu lassen. Mit der Benutzung der Programmiersprache
Java gegenüber der Skriptsprache JavaScript entfällt die Fehlerquelle der fehlenden Typensicherheit. Entwickler, die bereits mit Java vertraut sind, können bekannte Entwicklungsumgebungen, Entwurfsmuster und bekannte Tools weiter effektiv einsetzen. Fehler die bei
Skriptsprachen erst zur Laufzeit auftreten, können mit Java-Entwicklungsumgebungen schon
vor dem Compilieren vermieden werden. Die Dokumentation und Wartung des Quellcodes
kann auch über den Java-Code erfolgen.
Ein effektiver Vorteil bei der Entwicklung einer Rich-Internet-Application mit GWT ist das
Debuggen des cleintseitigen und serverseitigen Codes auf Java-Ebene. Mit JUnit kann die
ganzen Anwendung, auch asynchrone RPC, automatisiert getestet werden.
Mit der Hilfe von externen Bibliotheken steht ein großer Umfang an Bedienelementen für
die Entwicklung von Desktop-ähnlichen Anwendungen zur Verfügung. Die Entwicklung des
User-Interfaces entspricht dabei grundlegend der Entwicklung durch AWT oder Swing. Hinzu
kommt, dass GWT die Gui-Logik auf den Client auslagert und somit den Server entlastet.
Der mitgelieferte GWT-Compiler übersetzt den cleintseitigen Java-Code in JavaScript. Dabei
werden für alle unterstützten Browser-Typen eine eigene JavaScript-Datei von GWT erstellt.
Optional werden die JavaScript-Dateien noch weiter optimiert. Zur Laufzeit sind keine Anforderungen an den Browser gerichtet. Der Entwickler muss sich Dank GWT nicht mehr um die
unterschiedlichen Interpretationen von JavaScript in den verschiedenen Browsern kümmern.
Sowohl Server als auch Client können in einer Programmiersprache entwickelt werden. Es
besteht trotzdem noch die Möglichkeit kein Java auf dem Server anzuwenden. Wird jedoch
beides in Java entwickelt, bietet es den Vorteil, dass die Anwendung leichter gewartet werden
kann.
Das Google Web Toolkit steht unter OpenSource und wird somit stetig weiterentwickelt. Gute
Dokumentationen sind ebenfalls vorhanden.
5.2 Nachteile
Trotz alldem gibt es auch Nachteile, die das Google Web Toolkit mit sich bringt.
Das Framework steht nur für Java-Entwickler zur Verfügung. Warum hat sich Google also für
Java entschieden? Nach der Statistik von TIOBE 1 (Stand Dezember 2011) ist Java auf Position eins der beliebtesten Programmiersprachen. Besonders im kommerziellen Bereich wird
Java häufig für die Server-Implementierung benutzt [See08].
1
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html - Stand: 11.12.2011
24
5.2. NACHTEILE
Die Integration von GWT in bestehende Infrastrukturen, als auch die Integration von eigenen
Komponenten, erweist sich als ziemlich aufwendig[Mic07].
Zwar sind die GWT-Klassen momentan Open-Source, aber Google behält sich vor, die Lizenzbedingung in Zukunft jederzeit zu ändern[Goo11j]. Somit sind spätere Kosten durch eine
Lizenzänderung nicht ausgeschlossen.
Anders als die GWT-Klassen ist der GWT-JavaScript-Compiler nicht Open-Source und darf
nur mit der Genehmigung durch Google weitergegeben werden. Treten Bugs im JavaScriptCompiler auf, so ist man auf die Fehlerbehebung von Google abhängig[UF06].
25
6 GWT im Einsatz am Beispiel eines
Projektes aus der Verkehrstelematik
6.1 Projektbeschreibung
Baustellen auf Autobahnen erfordern einen hohen organisatorischen Aufwand. Damit es zu
keinen unnötigen Verkehrsbehinderungen führt, muss so ein Vorhaben schon im Voraus geplant
werden. So müssen Fahrspurverengungen deutlich gekennzeichnet werden und Geschwindigkeitsangaben angepasst werden um einen möglichst flüssigen Verkehrsfluss zu erreichen. Hinzu
kommen noch viele weitere Anforderungen, auch auf rechtlicher Seite, die beachtet werden
müssen.1
Die Planung des zu regelnden Verkehrsflusses wird mit Hilfe einer schematische Karte realisiert. Die schematische Karte stellt eine geografische Umgebung auf Fahrbahnniveau dar.
Dabei ist die detaillierte Darstellung wichtiger als die genaue geographische Lage der Fahrbahnen.
6.1.1 Anforderungen
Folgende Anforderungen wurden an die Karte gestellt [SPI]. Die schematische Karte, die eine
maximale Fläche von 24km x 24km abdecken sollte, soll die in diesem Abschnitt vorhanden
Straßen auf Fahrbahnniveau darstellen. Wird der Bereich zu komplex, wie etwa bei Autobahnkreuzungen, soll der Benutzer die Möglichkeit haben, durch Zoomen eine genauere Darstellung
der Lage zu bekommen. Dabei ist die detaillierte Darstellung der einzelnen Spuren wichtiger,
als die genaue geografische Lage.
Abbildung 6.1: Schematische Karte mit Namen-Labels
Beschilderungen und Signaleinrichtungen müssen jeweils auf den Spuren dargestellt werden und editierbar sein um Sperrungen einer Spur
einzuleiten oder Geschwindigkeitsangaben der Situation anpassen
zu können. Des Weiteren müssen
Raststätten, Serice-Bereiche, Versorungsstraßen, Ab- und Ausfahrten auf der Karte ersichtlich sein.
Jede Straße muss zudem mit ihrem
Namen und ihrer Kilometrierung versehen werden.
Dabei sollen die einzelnen Informationen zu den Straßen ein- und ausschaltbar sein.
6.1.2 Randbedingungen
Wie schon in der Motivation (siehe 1.1) beschrieben, war es ein Wunsch des Kunden, bereits
vorhandene Infrastrukturen zu nutzen. Es wurde sich auf ein Thin-Client unter der Verwendung eines Browsers geeinigt, der über das HTTP-Protokoll zum Server kommunizieren kann.
Die sogenannte Rich- Internet-Applikation sollte zudem mit HTML/JavaScript Technologien
1
http://www.arbeitsschutz.nrw.de/Themenfelder/baustellen/pflichten_des_bauherren/index.php Stand: 08.12.2011
26
6.2. EINSATZ VON GWT IM PROJEKT
entwickelt werden.
6.2 Einsatz von GWT im Projekt
Bereits ähnliche Projekte existierten nicht, was den Weg zu einer neuen Technologien, hier
das Google Web Toolkit, ermöglicht hat. Entscheidender Vorteil von GWT war die Programmierung in Java für den Quellcode auf der Client- und Server-Seite. Die Entwickler konnten
dadurch wie gewohnt im Java-Umfeld programmieren, debuggen und testen. Darüber hinaus
waren die oben genannten Vorteile von GWT (siehe 5.1) auch ausschlaggebend.
Eine weitere Anforderung des Kunden ist die Wartbarkeit des Quellcodes. Die Qualität des
Quellcodes und somit die Wartbarkeit wird in Java unter einer gewissen Metrik analysiert
und bewertet2 . In JavaScript ist diese Möglichkeit der Codebewertung nicht standardisiert
und anerkannt.
Die Darstellung der Karte wird mittels einer JavaScript-Bibliothek namens OpenLayers3 gezeichnet. Hier kommt die JSNI-Funktion von GWT zum Einsatz.
Von der gekapselten GWT-RPC-Schnittstelle wird auch Gebrauch gemacht. Hiermit werden
Daten zur Darstellung der Karte vom Server übermittelt. Es hat sich im Laufe des Projektes
ergeben, dass es zu Performance Verlust führt, wenn ganze Java-Klassen über die GWT-RPCSchnittstelle verschickt werden. Die Übertragung wird deshalb in Zukunft soweit abgeändert,
dass über die klassische RPC-Schnittstelle Strings in JSON-Format übermittelt werden können.
Damit nicht zu oft eine Verbindung zum Server aufgebaut werden muss, wird versucht den
größten Teil der Arbeit auf den Client auszulagern. Dazu werden zum Beispiel schon geladene
Daten einer Zoom-Stufe gecacht um ggf. später diese nicht mehr anfordern zu müssen.
2
3
http://www.sonarsource.org/ - Stand: 9.12.2011
http://openlayers.org/ - Stand: 09.12.2011
27
7 Fazit
Das Google Web Toolkit löst die Probleme der Ajax-Entwicklung auf elegante Weise. Besonders Java-Entwickler können ihre Produktivität mit GWT steigern, da GWT die Möglichkeit
bietet, mit bekannten Tools und objektorientierten Techniken zu arbeiten. Die Entwicklung
einer Rich-Internet-Application wird damit fast so einfach wie die Gestaltung herkömmlicher
Desktop-Anwendungen mit AWT oder Swing.
Sicherlich lassen sich ähnliche gute Ergebnisse mit anderen Technologien erreichen, doch GWT
bietet besonderes für Java-Entwickler einen hohen Grad an Komfort und Produktivität. Deshalb ist der Einsatz von GWT bei neuen Projekten ohne Codebasis oder bei der Portierung
von bestehenden Java-Anwendungen zu Webanwendung als sinnvoll anzusehen.
Bei großen bestehenden Projekten ist der Einsatz von GWT abzuwägen, da ein hoher Migrationsaufwand hinzukommt.
Das Google Web Toolkit wird sicherlich einen Einfluss auf die Web-Entwicklung nehmen, da es
besonders mehr professionelle Java-Entwickler als JavaScript-Experten gibt. Interessant wird
auch die Entwicklung der Lizenzbedingungen auf kommerzielle Produkte in Zukunft sein.
28
Abbildungsverzeichnis
2.1
2.2
2.3
Darstellung der Datei HelloWorld.html im Browser mit DOM-Elementen . . .
Kommunikation zwischen GWT-Shell und Browser im Hosted-Modus[Goo11c]
Generischer Lebenszyklus der GWT-Anwendungsentwicklung[HT07] . . . . .
8
11
12
3.1
Übersicht der GWT-RPC Klassen . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.1
Erstellung verschiedener JavaScript-Dateien je nach Browser und Sprache[SRM08] 22
6.1
Schematische Karte mit Namen-Labels . . . . . . . . . . . . . . . . . . . . . .
29
26
Literaturverzeichnis
[CC08]
Cooper, Robert ; Collins, Charles: GWT in practice. Greenwich, Conn : Manning, 2008. – ISBN 9781933988290
[Eri]
Eric Knorr: Definition Web 2.0. In: CIO: Fast Forward 2010 – The Fate of IT,
2004 – The Year of Web Services 15. Dezember 2003
[Goo11a] Google Inc.: Google Web Toolkit - Compatibility with the Java Language
and Libraries. http://code.google.com/intl/de-DE/webtoolkit/doc/latest/
DevGuideCodingBasicsCompatibility.html. Version: 2011, Abruf: 03.12.2011
[Goo11b] Google Inc.:
Google Web Toolkit - FAQ, Browsers and Servers.
http://code.google.com/intl/de-DE/webtoolkit/doc/latest/FAQ_
GettingStarted.html#What_browsers_does_GWT_support?
Version: 2011,
Abruf: 03.12.2011
[Goo11c] Google Inc.: Google Web Toolkit - Hosted Modus with OOPHM. http:
//code.google.com/p/google-web-toolkit/wiki/DesignOOPHM. Version: 2011,
Abruf: 03.12.2011
[Goo11d] Google Inc.: Google Web Toolkit - JRE Emulation Reference. http://code.
google.com/intl/de-DE/webtoolkit/doc/latest/RefJreEmulation.html.
Version: 2011, Abruf: 03.12.2011
[Goo11e] Google Inc.: Google Web Toolkit - JUnit Testing. http://code.google.com/
intl/de-DE/webtoolkit/doc/latest/DevGuideTesting.html.
Version: 2011,
Abruf: 03.12.2011
[Goo11f] Google Inc.: Google Web Toolkit - Organize Projects. http://code.google.
com/intl/de-DE/webtoolkit/doc/latest/DevGuideOrganizingProjects.html.
Version: 2011, Abruf: 03.12.2011
[Goo11g] Google Inc.: Google Web Toolkit - Server Communication. http://code.google.
com/intl/de-DE/webtoolkit/doc/latest/DevGuideServerCommunication.
html. Version: 2011, Abruf: 14.12.2011
[Goo11h] Google Inc.:
Google Web Toolkit Modules.
http://code.google.com/
intl/de-DE/webtoolkit/doc/latest/DevGuideCompilingAndDebugging.html.
Version: 2011, Abruf: 03.12.2011
[Goo11i] Google Inc.: Google Web Toolkit Overview. http://code.google.com/intl/
de-DE/webtoolkit/overview.html. Version: 2011, Abruf: 03.12.2011
[Goo11j] Google Inc.: Google Web Toolkit Terms and Conditions. http://code.google.
com/intl/de-DE/webtoolkit/terms.html. Version: 2011, Abruf: 09.12.2011
[HT07]
Hanson, Robert ; Tacy, Adam: GWT im Einsatz: AJAX-Anwendungen entwickeln
mit dem Google Web Toolkit. In: GWT im Einsatz (2007)
[Jes]
Jesse James Garret:
Ajax: A New Approach to Web Applications.
http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications,
Abruf: 10.12.2011
30
Literaturverzeichnis
[Mic07]
Michael Schmut, Papick Taboada: Google Web Toolkit Presentation. http:
//pgt.de/wp-content/uploads/2008/01/gwt-short.pdf. Version: 2007, Abruf:
09.12.2011
[See08]
Seemann, Michael: Das Google Web Toolkit: GWT; [sauberes Ajax für JavaBusinessanwendungen]. Dt. Originalausg., 1. Beijing [u.a.] : O’Reilly, 2008. – ISBN
9783897217195
[SPI]
DVS.SPIN.SSS: SPIN – Systeem voor Planning en Informatie Nederland System/Subsystem Specification (SSS) DVS SPIN SSS v1.6.doc, Version 1.6, 08.07.2011
[SRM08] Sowa, Hans ; Radinger, Wolfgang ; Marinschek, Martin: Google Web Toolkit:
Ajax-Anwendungen einfach und schnell entwicklen. 1. Heidelberg : Dpunkt-Verl.,
2008. – ISBN 978–3–89864–471–6
[Ste07]
Steyer, Ralph: Google Web Toolkit: Ajax-Applikationen mit Java. [Frankfurt, M.]
: Entwickler.press, 2007. – ISBN 9783939084211
[UF06]
Uwe Friedrichsen, Dirk H.: OPEN-SOURCE. In: OBJEKTspektrum (2006),
Nr. Ausgabe 06/2006, S. 52–56
31