GWT: Evolution der Internet-Anwendung

Im Rahmen unserer Reihe von Artikeln über das Google-Web-Toolkit (kurz GWT) gehen wir in diesem Beitrag auf die grundsätzliche Funktionsweise des Frameworks ein und stellen dar, welche Unterschiede es zwischen der Entwicklung klassischer Web-Seiten und GWT-Anwendungen gibt.

Eine Chronologie der Web-Applikation

Internet-Anwendungen gibt es seit vielen Jahren, gestatten wir uns einen kurzen Rückblick. Zunächst lief die Erstellung einer Web-Seite folgendermaßen ab: Der Browser forderte die Seite an und der Server übernahm deren Zusammenstellung und ihre Auslieferung „in einem Stück“. Rief der Nutzer eine andere Seite auf – beispielsweise durch den Klick auf einen Link oder ein abgeschicktes Formular –, begann der gesamte Prozess von vorne: Die Server-Anwendung stellte erneut eine komplette Seite mit Navigation, Informationen zum Login, Footer usw. usf. zusammen, selbst wenn sich nur ein kleiner Teil der Seite änderte. Um die Krawatte zu wechseln, wurde also jedes Mal der ganze Koffer ausgepackt.

Um die Generierungszeiten von Seiten zu beschleunigen, kamen bald Caches zum Einsatz, die bestimmte Teile des Inhalts vorhielten, sobald diese einmal erstellt waren. Kompliziert wurde es jedoch dann, wenn sich einer dieser inhaltlichen Bestandteile änderte.

In den letzten Jahren wurde dann verstärkt Ajax genutzt. Mit Hilfe dieser Technologie können bestimmte Teile einer Seite ausgetauscht werden. Dazu stellt der Browser des Nutzers aufgrund eines Auslösers eine Anfrage an den Server, der die neu darzustellenden Daten oder Inhaltselemente zurückliefert. Ein solcher Auslöser kann eine zeitliche Steuerung oder aber eine User-Aktion wie etwa ein Klick sein. Allerdings erfordert der Einsatz von Ajax viel Handarbeit: Häufig werden Seiten deshalb nach wie vor am Stück vom Server erstellt, die Ajax-Komponenten kommen nur an spezifischen Stellen zum Einsatz.

GWT geht diese Entwicklung konsequent weiter und stellt die Anwendung komplett aus Teilstücken zusammen. Den klassischen Seitenwechsel, bei dem sich der Pfad der URL oder zumindest die Parameter ändern, gibt es nicht mehr. Die Seite wird nur einmal vollständig geladen: Alles, was sich danach verändert, wird durch GWT nur noch ausgetauscht bzw. neu dargestellt. So ist z.B. beim Laden der Startseite einer Anwendung das Login-Fenster bereits im Browser vorhanden.

Dadurch ist es möglich, in einer für den Nutzer nicht spürbaren Zeit neue Seiten darzustellen. Kommuniziert der Browser mit dem Server, werden nur noch Daten ausgetauscht, um die Darstellung der Daten kümmert sich der Browser selbstständig. Damit entfällt die Wartezeit für den User: Es passiert sofort etwas, z.B. wird eine neue Maske angezeigt.

Werden die Daten für die Maske erst noch vom Server geladen, kann es freilich sein, dass diese zunächst leer ist. Es ist also wichtig, dem Nutzer entsprechendes Feedback zu geben, dass die Daten geladen werden.

GWT – das reine Frontend

Das eigentliche GWT-Framework ist zunächst auf reines Frontend beschränkt. Es enthält selbst keine Bestandteile, die auf einem Server betrieben werden.

Der Entwickler schreibt die GWT-Anwendung in reinem Java-Code, ein spezieller Übersetzer (Compiler) übersetzt die Anwendung danach in JavaScript-Code, der im Browser des User ausführbar ist. Dieser Compiler ist die eigentliche Besonderheit von GWT: Der Entwickler kann sich alle Vorteile der typsicheren Programmiersprache Java und der vorhandenen mächtigen Entwicklungswerkzeuge zunutze machen, während der GWT-Compiler sich um die Erzeugung von JavaScript-Code kümmert, der in jedem Browser funktioniert – eine Herausforderung, die bei der JavaScript-Entwicklung für gewöhnlich einen sehr hohen Aufwand verursacht.

Mithilfe von GWT wird also eine Anwendung erstellt, die mittels eines Browsers von einem Server geladen und danach im Web-Browser des Benutzers ausgeführt wird. Zudem kann die Anwendung – sofern sie einmal geladen wurde und keine Schnittstellen zum Server hat – auch ohne Internet-Verbindung im Browser laufen.

Noch hat die Anwendung ohne Schnittstelle zum Server jedoch einige Einschränkungen. So hat sie unter anderem keine Möglichkeit, Eingaben des Nutzers dauerhaft zu speichern. Wird der Browser geschlossen und neu geöffnet, ist die Anwendung wieder in ihrem ursprünglichen Zustand, alle Nutzereingaben sind verloren.

Kommunikation mit einem Server

GWT bietet darüber hinaus verschiedene Schnittstellen zur Kommunikation mit einem Server. (Als Server ist hier eine Anwendung zu verstehen, die auf einem Web-Server ausgeführt wird.) Die GWT-Applikation im Browser hat dadurch die Möglichkeit, Daten an den Server zu schicken und auch abzurufen.

Dabei besteht zunächst für die auf dem Server ausgeführte Anwendung keine Einschränkung hinsichtlich der Programmiersprache, sie muss nur die entsprechende Schnittstelle zur Kommunikation abbilden. Die Server-Anwendung kann also durchaus auch in Perl, PHP, Haskel oder C++ erstellt sein. Es ist außerdem möglich, eine bereits vorhandene Anwendung mit einem GWT-Frontend auszustatten.

Eine ebenfalls mit Java entwickelte Server-Anwendung hat aber den entscheidenden Vorteil, dass einmal geschriebener Java-Code sowohl im Client als auch im Server verwendet werden kann. Ein Anwendungsbeispiel ist die Überprüfung von Benutzereingaben. Soll der User ein Datum in ein Textfeld in einem bestimmten Format eingeben, kann die Gültigkeitsprüfung ebenso im Browser wie auch in der Server-Anwendung verwendet werden. Der Browser kann dem User sofort Feedback über die Korrektheit seiner Angaben geben, ohne mit dem Server kommunizieren zu müssen. Für den Nutzer hat dies den Vorteil, dass die Anwendung spürbar schneller läuft.

Um eine Klasse auch im Browser des Clients zu nutzen, muss sie allerdings gewisse Anforderungen erfüllen. So kann sie nicht einfach beliebige Java-Bibliotheken verwenden, wie es bei einem gewöhnlichen Java-Programm der Fall ist, vielmehr sind die im Frontend verwendbaren Elemente beschränkt. Das liegt daran, dass Google einen Teil der Java-Sprache in JavaScript nachgebildet hat. Nur diese Elemente können von Java in JavaScript übersetzt werden. Allerdings ist es durchaus möglich, aus diesen zur Verfügung stehenden Elementen größere Elemente zusammenzusetzen und auch im Frontend zu nutzen.

Umdenken beim Erstellen des Frontends und der Server-Anwendung

Bei GWT-Anwendungen mit einem GWT-Frontend und einem Backend auf dem Server handelt es sich um eine sog. verteilte Anwendung: Ein Teil des Codes der Applikation läuft im Browser des Users ab, der andere im Server. Die Synchronisation der Daten zwischen Browser und Server ist nun ein Aufgabenbereich, der stark an Bedeutung gewinnt. War früher der Server das maßgebliche System, das sämtliche Anwendungslogik enthielt, ist diese nun auf beide Seiten verteilt. Mit GWT muss der Entwickler einer Internet-Anwendung also umdenken.

Eine Herausforderung ist die asynchrone Kommunikation zwischen Client und Server. Das bedeutet, dass der Browser nach der Anforderung von Daten vom Server nicht einfach still steht. Vielmehr hat er eine Routine zur Behandlung der Daten definiert, die er vom Server erwartet, und arbeitet, während die Anfrage noch läuft, bereits die nächsten Schritte ab. Trifft dann die Antwort vom Server ein, ruft der Browser die zuvor definierte Routine auf und verarbeitet die Daten.

Auf die Reihenfolge, in der die Daten eintreffen, kann sich der Entwickler allerdings nicht verlassen. Wenn beispielsweise erst die Informationen zum eingeloggten Nutzer und anschließend Daten über dessen Rechte innerhalb der Applikation vom Server angefordert werden, muss der Entwickler damit rechnen, dass die Informationen zu den Rechten zuerst eintreffen können.

Ein ebenfalls neuer Gesichtspunkt bei der Anwendungsentwicklung ist der Aufbau/Ablauf der Client-Server-Kommunikation. Der Browser ruft viele kleine Services auf, deren Fokus jeweils auf der Erfüllung von Einzelaufgaben liegt.

Es gibt also deutlich mehr Kommunikation zwischen Browser und Server. Sie betrifft jedoch immer nur kleine Datenpakete. In einer Standard-Anwendung gibt es beispielsweise eine Login-Funktion, die nur die Eingaben „Kennwort“ und „Benutzername“ zum Server schickt. Der spezifische Server-Service (Handler) führt die notwendigen Prüfungen durch und meldet einen Fehler oder kommuniziert im Erfolgsfall die Daten des Nutzers, die die Client-Seite zur Anzeige der Login-Informationen benötigt (letzter Login, Benutzername, Anzahl Logins, ...).

Zur Verarbeitung der Daten im Frontend setzt GWT auf ein Event-System. Diese Software-Technik hat insbesondere diese Vorteile:

  • Zwischen verschiedenen Code-Teilen besteht keine feste Bindung.
  • Der Programmfluss ist nicht linear.
  • Die Technik eignet sich hervorragend zur Realisierung von Oberflächen.

Wie auch in vielen anderen Frameworks zur Erstellung von Desktop-Anwendungen ist die Event-gesteuerte Entwicklung sehr sinnvoll, um an verschiedenen Stellen der Oberfläche auf sich ändernde Bedingungen zu reagieren. Ein beliebiger Bestandteil der Oberfläche, für den ein bestimmtes Ereignis relevant ist, kann sich als sog. Event-Listener registrieren und wird so beim Auftreten des jeweiligen Ereignisses automatisch aktiviert. Somit reagiert er eigenständig auf das Ereignis und passt z.B. die Darstellung an.

Fazit

GWT überführt viele Ansätze aus der klassischen Programmierung von Oberflächen in die Internet-Anwendung. Für die Erstellung der Webseite ergeben sich hieraus neue Möglichkeiten v. a. hinsichtlich der Komplexität der Oberflächen. Aufwändige Programme werden durch eine strukturierte Umsetzung der Oberflächen besser kalkulierbar, aber auch die Ansprüche an den Entwickler der Oberfläche steigen.

Und: Ein gutes Software-Design gewinnt auch im Frontend-Bereich enorm an Bedeutung. Eine GWT-Anwendung ohne eine durchdachte Struktur ist nur schwierig zu warten und weiterzuentwickeln. Außerdem werden Sicherheitsaspekte in der Oberfläche immer wichtiger. Welche Daten und welche Logik sollten in der Oberfläche verwendet werden und welche nicht? Auf diese Fragen gehen wir in den nächsten Artikeln über Sicherheitsaspekte im Hinblick auf die Andwendungslogik und Datensicherheit ein.

//SEIBERT/MEDIA entwickelt mit GWT

Derzeit realisiert //SEIBERT/MEDIA zwei große Projekte mit GWT und verfügt über umfassende Erfahrungen. Unser aktuelles Projekt TwentyFeet, das Auswertungs-Tool für professionelle Social-Media-Aktivitäten, gibt Ihnen einen kompakten Überblick über die Möglichkeiten des Frameworks.

Planen Sie ein Software-Projekt? Möchten Sie Ihre bestehende Applikation mit neuen Funktionen ausstatten oder optimieren? Die Entwickler von //SEIBERT/MEDIA/TECHNOLOGIES sind Experten in der Anwendungsentwicklung mit Java, GWT, Groovy & Grails und Perl und helfen Ihnen gerne weiter. Bitte sprechen Sie uns unverbindlich an!

Weiterführende Informationen

Oops! Phone not supported
GWT JRE Emulation Reference
Sicherheitsaspekte in GWT-Anwendungen: Anwendungslogik und Manipulationen
Sicherheitsaspekte in GWT-Anwendungen: Datensicherheit und gefälschte HTTP-Requests
Dynamische Internet-Anwendungen: GWT im Projekteinsatz
Dynamische Internet-Anwendungen: GWT aus Entwicklerperspektive


Mehr über die Creative-Commons-Lizenz erfahren

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

3 thoughts on “GWT: Evolution der Internet-Anwendung”

  1. Hi Micha,

    danke für den guten Überblick. Ich finde es auch sehr angenehm mit GWT zu arbeiten.

    Man kommt kaum noch in Berührung mit den syntaktischen Unzulänglichkeiten von Javaskript und kann auf angenehme Weise mächtige und performante “RIA” Anwendungen entwickeln.

    Ein Punkt den ich persönlich jedoch wichtig finde ist, dass sich GWT am besten eignet, wenn man tatsächlich Anwendungen entwickelt. Das heißt, anstatt zu versuchen klassische voll designte und dynamische Webseiten damit zu bauen.
    Die mitgebrachten Widgets und Layouts kommen nun einmal aus der AWT/Swing Ecke und gliedern sich auch am natürlichsten in solch eine Art Anwendung ein.
    Eine voll designte Anwendung, in der man auf das look and feel von Standardelementen zwecks Individualismus verzichtet, ist zwar möglich, bedeutet hier aber etwas mehr Aufwand als bei klassisch Server-Seitig erzeugten HTML Seiten.

    Dass solche eine GWT Anwendung dennoch gut aussehen kann, beweist meiner Meinung nach der PostgreSQL GWT Client aus dem GWT Showcase http://demo.teampostgresql.com/

    Sehr schön sieht natürlich auch https://www.twentyfeet.com/app/ aus, auch wenn es hier viele klassische Webseiten Elemente gibt, deren Umsetzung aufwändiger ist als bei Server generierten Seiten.

    Ich finde es gut, dass wir viele Tools in unsere Werkzeugkiste aufnehmen und so die Chance haben, das beste für den jeweiligen Zweck auszuwählen.

    Gruß Ben.

  2. Danke für diesen Kommentar. Ich halte auch eine offene Kultur und Einstellung gegenüber Technologie für deutlich wertvoller und zielführender als ein monolithischer Dogmatismus.

  3. Der Aussage “Es gibt also deutlich mehr Kommunikation zwischen Browser und Server.” würde ich jetzt so nicht zustimmen. Wenn man Bilder und andere Dinge die immer neu geladen werden mit einbezieht, werden dort sicher mehr Requests gemacht. Auch gibt es fuer GWT Möglichkeiten Batch-Calls zu machen um mehrere Calls an das Backend in einen zu bündeln.

Schreibe einen Kommentar