Das Google Web Toolkit: GWT

Kapitel 3 Von der Idee über die Architektur zur Projektstruktur (S. 33-34)

Ein kleines Beispiel zu erstellen, ist eine Sache, ein reales Projekt durchzuführen, eine ganz andere. Man muss sich dabei nicht nur über die Anforderungen des Kunden Gedanken machen, sondern steht auch in der Pflicht, ein wartbares und ausbaufähiges Produkt zu erstellen. Und das beginnt bereits bei der Architektur der zukünftigen Software.

In diesem Kapitel werden Sie erfahren, welche Softwarearchitekturen mit dem Google Web Toolkit möglich sind und welcher Weg der von mir bevorzugte ist. Dabei werde ich grundsätzlich vom Remote Procedure Call-Mechanismus des GWT ausgehen. Auf andere Formen der Datenübertragung zwischen Client und Server sind die hier dargestellten Prinzipien aber ohne weiteres übertragbar. Am Ende des Kapitels werden die beiden hier erläuterten Architekturentscheidungen in die Projektstruktur von Eclipse übersetzt. Dazu wird das Fitnesstagebuch, das ich in der Einleitung kurz vorgestellt habe, als Beispiel verwendet. Sie werden dabei gleichzeitig erfahren, wie Eclipse so konfiguriert werden kann, dass Teamarbeit einfach möglich wird.

Natürlich wird die mit dem Google Web Toolkit erstellte Anwendung immer ein Client- Server-System sein. Der Client ist der Browser, in dem unsere Ajax-Anwendung abläuft. Dieser kommuniziert über einen der vom GWT unterstützten Wege mit dem Server, auf dem die Fachlogik und die Datenhaltung angesiedelt sind. Im Gegensatz zum herkömmlichen Request-Response-Verfahren wird hier aber nicht mehr eine vollständige HTMLSeite erstellt und an den Client ausgeliefert, sondern nur noch minimale Informationen. Das können HTML-Fragmente oder im besten Fall einfach nur serialisierte Objekte sein. Diese Objekte übertragen den Zustand des Anwendungsmodells vom Server zum Client und umgekehrt. Die Zuständigkeit für die Aktualisierung der View ist damit nicht mehr zweigeteilt auf dem Server und auf dem Client angesiedelt, sondern nur noch auf dem Client zu finden.

Lassen Sie uns zunächst einen Blick auf zwei unterschiedliche Architekturansätze werfen, wie sie mit dem Google Web Toolkit umgesetzt werden können.

Mehr-Schichten-Architektur oder eine Schicht?

Eine Schicht verbietet sich eigentlich prinzipbedingt, wenn man Webanwendungen entwickelt, weil die Trennung von Client und Server mindestens zwei Schichten erfordert. Es ist aber durchaus üblich, den serverseitigen Code einer Webanwendung zur Präsentationsschicht zu zählen. Zumindest beim Einsatz des herkömmlichen Request-Response- Verfahrens ist das eine sinnvolle Abstraktion, weshalb man durchaus von einer schichtenlosen Architektur sprechen kann.

Setzt man das Google Web Toolkit ein, dann ist diese Zusammenfassung der Präsentationsschicht nicht mehr sinnvoll. Zum einen kann die View vollständig ohne Server im Browser erstellt werden, und zum anderen können die Komponenten der View völlig ohne die Hilfe eines Servers auf Benutzerinteraktion reagieren. Deshalb besteht die minimale Architektur für eine Ajax-Anwendung aus zwei Schichten: nämlich der im Browser dargestellten Oberfläche, mit der der Anwender interagiert, und der Implementierung der serverseitigen Dienste.

Diese serverseitigen Dienste sind bei der Verwendung des GWT-RPC-Mechanismus Klassen, welche die vorzugebenden Schnittstellenbeschreibungen (in Form von Java- Interfaces) implementieren. Da diese Interfaces von RemoteService abgeleitet sein müssen, bezeichne ich diese Implementierungen als GWT-Services. Bei einer mehrschichtigen Architektur ist die Trennung der View in den clientseitigen Code und die Implementierung der Dienste natürlich auch erforderlich. Allerdings wird die Logik nicht vollständig in den GWT-Services implementiert. Vielmehr benutzen die GWT-Services ein System, das aus mehreren Schichten besteht, die über ein Fach- (auch Domain-) Modell miteinander kommunizieren.