1. Was ist Vaadin?

Lassen Sie uns zum Einstieg zunächst einen Blick auf die geschichtlichen und technologischen Hintergründe des Frameworks werfen. Wir wollen erfahren, wo Vaadin herkommt und welche Besonderheiten das Framework auszeichnen.

Der Blick auf diese technologischen Besonderheiten gibt uns eine Idee davon, wie wir das Verhalten des Frameworks zur Laufzeit bewerten können. Anhand der speziellen Vor- und Nachteile, die sich daraus ergeben, können wir Szenarien ableiten, für die der Einsatz von Vaadin besonders geeignet, oder für die er eher weniger geeignet ist.

Falls Ihre Neugier auf das Vaadin Framework zu groß ist und Sie sich lieber gleich in die Programmierung mit Vaadin stürzen wollen, können Sie dieses Kapitel getrost überspringen und im nächsten Kapitel einsteigen. Es lohnt sich aber sicherlich, später noch einmal hierher zurückzukehren, um sich ein wenig mit der Herkunft von Vaadin zu beschäftigen.

1.1 Geschichtliches

Das Vaadin Framework ist unter diesem Namen seit dem Jahr 2009 auf dem Markt. Man möchte fast meinen, dass Vaadin damit ein noch recht junges und vielleicht noch nicht an jeder Stelle vollständig ausgereiftes Framework ist. Ich habe Ihnen aber nur die halbe Wahrheit erzählt.

In Wahrheit gibt es Vaadin, beziehungsweise dessen technologischen Vorgänger, schon seit dem Jahr 2000. Seit diesem Jahr wird nämlich von der finnischen Firma IT Mill Ltd. ein Webframework namens Millstone¹ entwickelt, das später einmal in unser Lieblingsframework Vaadin umgewandelt werden soll.

Die Firma IT Mill Ltd. gibt es heute unter diesem Namen nicht mehr. Sie wurde im Jahr 2009 in Vaadin Ltd. umbenannt – zeitgleich zu der Umbenennung des hauseigenen Frameworks nach Vaadin. Man wollte mit dieser Umbenennung den Wunsch unterstreichen, stärker die Community einzubeziehen.

Vaadin Ltd. ist in der südfinnischen Stadt Turku (oder auf Schwedisch Åbo) ansässig. Inzwischen gibt es aber auch schon Zweigstellen in Berlin und San Jose, USA. Firmengründer und Geschäftsführer ist Dr. Joonas Lehtinen, der mit seinem Team das Java Webframework entwickelt.

Vaadin ist ein Open Source Framework, das unter der freizügigen Apache License 2.0 steht. Die Firma Vaadin bietet neben dem kostenlosen Framework auch kommerzielle Dienstleistungen in den Bereichen Beratung, Projektunterstützung und Framework Schulungen an. Daneben gibt es einige kostenpflichtige Erweiterungen und Zusatztools für Vaadin, die das Framework um neue Funktionen und Komponenten erweitern. Beispielhaft aus diesem Bereich seien hier das Vaadin Touchkit zum Schreiben mobiler Anwendungen, der Vaadin Designer zur visuellen Gestaltung von Benutzeroberflächen oder die Vaadin Charts, eine Sammlung von Statistik- und Graph-Komponenten, erwähnt. Besuchen Sie für einen Überblick über diese Dienstleistungen und Angebote einfach die Vaadin Homepage http://www.vaadin.com.

Mit Vaadin lassen sich Webanwendungen mit rein serverseitigem Code erstellen. Das heißt, man programmiert eine Webanwendung vollständig mit Java und bewegt sich dabei komplett auf der Server-Seite. Der Teil, der den Benutzerinnen und Benutzern im Browser angezeigt wird, wird auch im Browser erzeugt. Dieser Prozess wird allerdings vom Server aus ferngesteuert. Anders als bei anderen Technologien, die z. B. auf HTML Templating aufsetzen, generieren wir hierbei HTML Markup nicht direkt. Dies wird für uns vom Framework übernommen. Wir stellen lediglich UI-Komponenten auf Layouts zusammen, die dann von Vaadin in das HTML Dokument “gezeichnet” werden. Man muss sich dadurch nicht mehr zwingend mit Technologien, wie HTML, CSS, Templating Engines oder JavaScript herumschlagen.

Das Vaadin Framework verwendete ursprünglich (als es noch Millstone Framework hieß) ein proprietäres, AJAX-basiertes Kommunikationsmodell zwischen der Client- und der Server-Seite. Die clientseitige Render Engine, der Teil also, der die UI Komponenten in den Browser zeichnet, und die Client-Server-Kommunikation waren Eigenentwicklungen. In dieser Version war es nur sehr schwer möglich, das Framework um eigene clientseitige Komponenten zu erweitern. Eine bessere Alternative für den proprietären Client-Teil musste gefunden werden.

Integration des Google Web Toolkits

Im Jahr 2006 wurde von Google das Google Web Toolkit (GWT oder auch Gwit ausgesprochen) veröffentlicht. Das GWT ist ein Framework, das es Entwicklerinnen und Entwicklern ermöglicht, JavaScript-Anwendungen für den Browser rein mit Java zu entwickeln. Das funktioniert über einen sogenannten Cross Compiler. Das heißt, man schreibt mit Hilfe einer speziellen Programmierschnittstelle Java Code, der später mit dem GWT Compiler nach JavaScript übersetzt wird. Der GWT Cross Compiler arbeitet dabei direkt mit dem Java Source Code und nicht mit den kompilierten Class-Dateien. Am Ende wird der übersetzte JavaScript-Code im Browser ausgeführt.

Das Besondere am Google Web Toolkit ist, dass die komplette Webanwendung – sprich die gesamte Fachlogik – im Browser läuft. Es kann (muss aber nicht) mit Hilfe von Remote Procedure Calls (entfernten Prozeduraufrufen) mit einem Server-Backend kommuniziert werden, um bspw. Daten aus einer Datenbank nachzuladen oder diese dort zu persistieren.

Eine weitere Besonderheit ist, dass das GWT JavaScript-Code erzeugt, der genau auf die Eigenheiten der einzelnen Browser abgestimmt ist. Das bedeutet, dass für jede gewünschte Browser-Zielplattform genau eine spezielle JavaScript-Datei kompiliert wird, die nur von dem jeweiligen Browser geladen wird. Man kann damit sichergehen, dass seine Anwendung ohne gesonderte Anpassung auch in jedem Browser problemlos funktioniert.

Ein solches clientseitiges Framework, das browserabhängigen JavaScript-Code auf Basis von Java-Quellcode erstellen kann, ist natürlich der ideale Kandidat für den Client-Teil von Vaadin. GWT-Code kann komplett mit Java geschrieben werden, was gut zu einem Java-Framework wie Vaadin passt. Und über die Möglichkeit von GWT, auch per Remote Procedure Calls (RPC) mit einem Server-Backend kommunizieren zu können, kann eine GWT-Anwendung problemlos an den serverseitigen Teil von Vaadin – in dem ja die Fachlogik läuft – angebunden werden.

Im Jahr 2007 wurde der proprietäre clientseitige Teil von Vaadin über Bord geworfen und durch eine GWT-Implementierung ersetzt. Dies brachte einige große Vorteile mit sich:

• Das Vaadin-Team muss sich nun nicht mehr um die Weiterpflege einer eigenen clientseitigen Implementierung kümmern und kann sich voll und ganz auf die Verbesserung des eigentlichen Vaadin-Kerns konzentrieren.
• Vaadin wurde komplette browserunabhängig, ohne dass dafür ein gesonderter Aufwand betrieben werden musste.
• Die Weiterentwicklung des clientseitigen Basisframeworks (GWT) erfolgt durch das Team eines großen Herstellers, nämlich Google. Vaadin hat hier keine großen Aufwände mehr.
• Die Entwicklung clientseitiger Komponenten kann von jedermann durchgeführt werden, der sich mit dem Google Web Toolkit auskennt. Eine Einarbeitung in eine proprietäre Programmierschnittstelle ist damit nicht mehr notwendig. Vorhandenes Wissen kann also zum Einsatz kommen, sodass auf dem Arbeitsmarkt auch eine größere Menge an potentiellen Entwicklerinnen und Entwicklern für den Einsatz in Vaadin-Projekten verfügbar ist.

1.2 Technologischer Hintergrund

Seit 2007 basiert also der clientseitige Teil von Vaadin auf dem Google Web Toolkit. Was bedeutet das aus technischer Sicht?

Eine typische GWT-Anwendung besteht aus einer Reihe von Ansichten (Views), die über eine spezielle Fachlogik miteinander verbunden sind. Damit behandelt eine GWT-Anwendung immer ein ganz bestimmtes, klar umrissenes fachliches Thema, z. B. eine Kundendatenverwaltung oder einen Web Shop. Wie kann man dies nun mit einer Technologie wie Vaadin zusammenbringen, bei der wir eine Webanwendung rein serverseitig implementieren wollen? Wir wollen ja gerade nicht dazu gezwungen werden, zusätzlich noch clientseitigen Code schreiben zu müssen.

Die Lösung ist, dass Vaadin eine generische GWT-Anwendung für den Client-Teil mitbringt, mit der sich jegliche Anwendungslogik umsetzen lässt, ohne dass dieser clientseitige Teil von uns angepasst werden müsste. Diese generische GWT-Anwendung bildet dabei keine bestimmte, anwendungsfallbezogene Fachlogik ab, sondern stellt eine Schnittstelle dar, welche UI-Komponenten im Browser darstellen und mit dem Vaadin-Backend kommunizieren kann.

Diese generische GWT-Anwendung wird in der Vaadin-Terminologie Widget Set (oder auch Client-Side Engine) genannt. In diesem Widget Set ist die Menge aller verfügbaren Vaadin UI-Komponenten vorhanden. Zudem enthält es ein Kommunikationsmodul, mit dessen Hilfe dieses Widget Set mit der serverseitigen Anwendung kommunizieren kann.

Das Grundprinzip einer Vaadin-Anwendung sieht damit wie folgt aus. Wir stellen in unserem serverseitigen Code eine Benutzerschnittstelle zusammen, indem wir UI-Komponenten (Textfelder, Checkboxen, Tabellen etc.) auf Layout-Komponenten anordnen. Es ergibt sich dadurch eine baumartige Struktur von instanziierten UI-Objekten, die innerhalb der HTTP Session eines Benutzers (also im Speicherbereich des Servers) verwaltet wird. Vaadin kümmert sich nun für uns hinter den Kulissen darum, dass an den Browser spezielle Anweisungen geschickt werden, welche vom Widget Set interpretiert und ausgeführt werden können. Diese Anweisungen führen dazu, dass das Widget Set die UI-Komponenten, die wir auf Server-Seite zusammengestellt haben, in Form von HTML Markup in den DOM-Baum (Document Object Model) gezeichnet werden. Wir steuern also mit unserem serverseitigen Code den Vaadin-Teil im Browser indirekt fern.

Was geschieht als nächstes, wenn die Benutzerin oder der Benutzer mit der Vaadin-Anwendung im Browser interagiert? Interaktion bedeutet bei Vaadin immer, dass in irgendeiner Form ein Ereignis ausgelöst wird. Das kann geschehen, wenn auf eine Schaltfläche geklickt wird, oder wenn ein Textfeld den Eingabefokus verliert, oder wenn man die Sortierung einer Tabelle ändert und so weiter. Das Widget Set sorgt nun dafür, dass derartige Ereignisse (Events) registriert und an den Server geschickt werden. Dort werden diese Ereignisse in Form von komponentenspezifischen Events (z. B. ein Button.ClickEvent wenn auf eine Schaltfläche geklickt wurde) von unserem Anwendungscode weiterverarbeitet.

Auf jedes Event folgt typischerweise eine anwendungsspezifische Reaktion. Zum Beispiel können Daten aus einer Datenbank nachgeladen werden, die in einer Tabelle oder einer Liste angezeigt werden sollen. Oder es werden Formulareingaben in der Datenbank persistiert, und auf der Benutzeroberfläche wird ein entsprechender Hinweistext angezeigt. In den allermeisten Fällen muss also in irgendeiner Weise die Benutzeroberfläche angepasst werden. Als Antwort auf ein solches Anwendungsevent manipulieren wir also in unserem serverseitigen Code die UI-Komponenten, auf die wir über die HTTP Session Zugriff haben. Beispielsweise ändern wir den Text, der von einem bestimmten Label angezeigt wird. Diese Änderungen an der dargestellten Komponentenhierarchie werden von Vaadin als Antwort auf ein Ereignis an das Widget Set im Browser zurückgeschickt. Dieses sorgt dafür, dass die clientseitig dargestellten UI-Komponenten entsprechend aktualisiert werden. Dafür werden einfach die jeweiligen HTML-Elemente im DOM-Baum angepasst, entfernt, oder es werden neue hinzugefügt.

Die Ereignisbehandlung geschieht bei Vaadin über AJAX-ähnliche Aufrufe. Die Abkürzung AJAX steht, wie Sie sicherlich wissen, für Asynchronous JavaScript and XML, also asynchrone JavaScript-Verarbeitung, bei der Nachrichten im XML-Format verschickt werden. Die Idee hinter AJAX-basierten Webanwendungen ist, dass Daten zwischen Server und Browser ausgetauscht und der Inhalt einer aktuell angezeigten Seite verändert werden kann, ohne dass die Seite komplett neu geladen werden muss. Vaadin arbeitet nach demselben Prinzip: Es wird eine einzige Seite geladen (die sogenannte Host Page), die als erstes den JavaScript-Code des Widget Sets lädt und ausführt. Anschließend werden nur noch Teile der Seite ereignisgetrieben abgeändert oder ausgetauscht. Die Kommunikation mit dem Server geschieht dabei im Hintergrund. Es werden hierbei nur die Daten zwischen Client und Server ausgetauscht, die zur Bearbeitung des aktuellen Events notwendig sind. Ein Neuladen der Seite findet nicht statt.

Es gibt bei Vaadin zwei wichtige Unterschiede zum klassischen AJAX: erstens ist die Kommunikation von Vaadin nicht asynchron. Wenn ein Ereignis zum Server geschickt wurde, wartet das Widget Set zuerst auf eine Antwort, bevor die Anwendung weiter benutzt werden kann. Zumeist fällt das gar nicht weiter auf, da die Ereignisbehandlung so schnell abläuft, dass die Benutzeroberfläche nur für den Bruchteil einer Sekunde blockiert ist — so schnell kann man gar nicht klicken. Wenn die Ereignisbehandlung allerdings besonders lange dauert, etwa weil eine langlaufende Berechnung angestoßen wurde, dann wird dies für die Anwenderin oder den Anwender spürbar.

Zweitens verwendet Vaadin keine XML Nachrichten für die Kommunikation mit dem Server. Stattdessen setzt das Framework auf JSON²-kodierte Nachrichten, welche durch JavaScript-Code wesentlich besser interpretierbar und verarbeitbar ist als XML.

Zusammenfassend können wir festhalten, dass eine Vaadin-Anwendung einmalig über eine Host Page geladen und dann nur noch über leichtgewichtige Serveranfragen gesteuert wird. Die gesamte Anwendung wird dabei auf einer einzigen Seite betrieben — nämlich die Host Page, die beim ersten Aufruf der Vaadin-Anwendung geladen wurde. Aus diesem Grund spricht man bei einer solchen Art von Anwendung auch von einer Single-Page Application: es wird eine Seite geladen, die den notwendigen JavaScript-Code nachlädt, der dann im Folgenden dynamisch die Inhalte dieser Seite austauscht.

Durch diese Eigenschaften und durch die damit möglichen dynamischen UI-Komponenten (z. B. Menüleisten, Drop-Down Vorschlagslisten, Dialogfenster, Möglichkeiten für Drag-and-Drop-Verarbeitung, Baumkomponenten usw.) zeigen derartige Anwendungen ein ähnliches Verhalten, wie herkömmliche Desktop-Applikationen. Sie zeigen ein reichhaltiges Verhalten mit Bezug auf die Interaktionsmöglichkeiten, und das Ganze findet im Browser über das Internet statt. Aus diesem Grund werden derartige Anwendungen auch Rich Internet Applications genannt.

Damit haben wir die Grundeigenschaften von Vaadin herausgearbeitet: Vaadin ist ein Framework für Rich Internet Applications, welches nicht auf einer Browser-Plugin-Infrastruktur aufsetzt, sondern nach dem Prinzip einer JavaScript Single-Page Application funktioniert.