Die Java-Technologie war von Beginn an eng mit dem Internet verknüpft. Das ist vor allem Java-Applets zu verdanken. Diese Miniprogramme werden einfach in eine HTML-Seite eingebettet und können so von Internet-Browsern direkt ausgeführt werden. So einfach und problemlos sich dies zunächst anhört, birgt die Applet-Technologie eine ganze Reihe von Tücken wie lange Lade- und Initialisierungszeiten sowie Problemen mit Firewalls - Gründe, warum man heute fast nur noch von Servlets im Zusammenhang mit Java-Web-Anwendungen spricht.
Java-Servlets wurde von Sun Microsystems Mitte 1997 eingeführt (Siehe Abbildung oben). Mit dieser Java-API lassen sich Java-Webanwendungen mit einer dynamischen HTML-GUI entwickeln. Bevor die ersten Web-Frameworks auf Servlet-Basis entstanden, übernahmen Servlets sowohl die Präsentation als auch die Steuerung innerhalb von Java-Web-Anwendungen. Das war nicht nur sehr unproduktiv, sondern führte auch zu schwer wartbaren Anwendungen. Abhilfe schafften die 1999 vorgestellten JavaServer Pages (JSPs). Mit JavaServer Pages konnte Präsentation und Logik sauber getrennt werden.
Die Arbeitsteilung zwischen Servlet und JSP funktioniert so, dass das Servlet ausschließlich für die Steuerung (Controller) der Web-Anwendungen zuständig ist, während JSPs die Präsentation (Views) übernehmen. Zusammen mit Klassen für die Datenhaltung und Geschäftslogik entsteht eine Model-View-Controller-Architektur (Siehe Abbildung unten). Eine Web-Anwendungen auf dieser Basis ohne ein Web-Framework zu entwickeln, ist zwar möglich, aber für größere Anwendungen zu aufwändig. Um die Entwicklung von Web-Anwendungen zu erleichtern, sind im Lauf der Jahre viele Java-Web-Frameworks entstanden.
Struts
Apache Struts war eines der ersten Java-Web-Frameworks. Die erste Generation des Struts-Frameworks wurde schon kurz nach der Einführung der JavaServer Pages Mitte 2000 vorgestellt und war über lange Jahre der Quasistandard für Java-Web-Frameworks schlechthin. Im Jahr 2007 erschien die zweite Generation von Struts. Struts 2 ist eine Abspaltung von Struts 1 und aus dem Java-Web-Framework WebWork entstanden. Struts 1 wird nicht mehr länger unterstützt (siehe Press-Release). Aktuell gibt es die Version 2.3 des von der Apache Software Foundation gehosteten Frameworks. Es steht unter der Apache Lizenz 2.0 und kann somit bedenkenlos auch für kommerzielle Anwendungen eingesetzt werden.
Struts 2 gehört zu den Frameworks, die auf einer MVC-Architektur aufbauen (siehe Abbildung). Das Model einer Struts-Web-Anwendung beinhaltet wie üblich die Geschäftslogik und die zur Anzeige benötigten Daten. Bei Struts bezeichnet man diese Teile als Action-Klassen. Den Part der Views übernehmen JavaServer Pages. Sie bestehen aus HTML-Code, der mittels einer Struts-Tag-Library um spezifische Tags zum Beispiel für Oberflächenkomponenten wie Textfelder angereichert wird. Die Steuerung übernimmt ein eigenes Struts-Servlet auf Basis einer speziellen Konfigurationsdatei. In dieser Datei ist unter anderem das Verhalten für die Actions definiert.
Einer der wichtigsten Bestandteile eines Web-Frameworks ist die Unterstützung der Eingabevalidierung. Struts verfügt über ein eigenes Validation-Framework namens XWork, dessen Ursprünge auf WebWork zurückgehen. Das Validation-Framework kennt zwei Arten von Validatoren: Feldvalidatoren und globale Validatoren. Mit den Feldvalidatoren lassen sich Plausibilisierungen auf Feldebene vornehmen, wie zum Beispiel eine E-Mail-Adresse oder eine Kreditkartennummer. Globale Validatoren sind hingegen in der Lage ganze Formulare zu überprüfen.
Wer nach komplexen GUI-Komponenten wie Ajax-DataTables im Basis-Framework sucht, wie sie bei der JSF-Konkurrenz PrimeFaces zu finden sind, wird enttäuscht. Abhilfe kommt mit entsprechenden Plug-ins, zum Beispiel aus dem Fundus der JavaScript-Bibliothek jQuery Javascript Library (siehe Textkasten unten: "JavaScript-Bibliotheken). Die Dokumentation ist, wie inzwischen bei allen Apache-Top-Level-Projekten, sehr gut. Sie wird durch reichlich Fachliteratur ergänzt. Struts-2-Anwendungen haben keine großen Ansprüche an die Laufzeitumgebung. Sie können mit jedem einfachen Servlet-Container wie beispielsweise Jetty oder Tomcat betrieben werden.
Fazit: Struts 1 war der De-Facto-Standard bei Java-Webframework. Aufgrund der Entwicklung von JavaServer Faces konnte Struts 2 niemals die Bedeutung der ersten Generation erlangen. Das hat nichts mit seiner Qualität zu tun, sondern ist einfach dem sehr ähnlichen JSF-Standard geschuldet. Hinter der Zukunft dieses Web-Frameworks muss man daher ein Fragezeichen setzen. Es ist zu erwarten, dass viele Firmen ihre Struts-1-Anwendungen lieber auf JSF als auf Struts 2 migrieren.
Spring MVC
Der Auslöser, das Framework Spring zu entwickeln, war der mangelhafte JEE-Standard vor rund zehn Jahren. Besonders die Kritik an den komplizierten und unausgereiften Enterprise JavaBeans hat zu der JEE-Konkurrenz Spring beigetragen. Ein eigenes Spring-Web-Framework war laut Rod Johnson zu Anfang überhaupt nicht geplant (siehe Introduction to the Spring Framework). Da es aber keinen JEE-Standard für ein Java-Web-Framework gab und die damalige Version von Struts nicht überzeugen konnte, entschied man sich für die Entwicklung eines eigenen MVC-Web-Frameworks namens Spring MVC, dem später Grails folgende sollte (siehe Textkasten JVM-Frameworks).
Das Web-Framework Spring MVC kann mit den anderen hier genannten Frameworks nur bedingt verglichen werden: Spring MVC ist genau genommen lediglich ein Modul des gesamten Spring Frameworks und daher nur als Ergänzung des Spring Frameworks gedacht. Es erweitert dieses Basis-Framework zusammen mit anderen Modulen wie Spring Roo zu einem Full-Stack-Framework. In diesem Full-Stack-Framework gibt es Vorlagen und Konnektoren für die unterschiedlichsten Einsatzbereiche, zum Beispiel Spring Data JPA oder Konnektoren zu NoSQL-Datenbanken.
Spring MVC arbeitet wie die anderen Frameworks dieses Vergleichs nach dem MVC-Prinzip (siehe Abbildung). Die Anfrage (Request) eines Webclients wird gegebenenfalls gefiltert und danach von einem Spring-eigenen Dispatcher-Servlet verarbeitet. Dieses Servlet leitet die Anfrage an einen Handler (Controller) weiter, der für das Data Bindung und die Validierung der Anfrage sorgt. Von da an geht es weiter zu einem Model, dessen Daten zur Anzeige benötigt werden oder dessen Daten aktualisiert werden sollen. Die Daten werden im Anschluss daran vom Dispatcher-Servlet über einen View-Resolver an die zuständige View weitergeleitet. Erst danach wird die View als Antwort an den Web-Client zurückgegeben.
Wer von einem komponentenbasierten Framework wie Swing oder JSF kommt, wird bei Spring MVC vergeblich nach komplexen GUI-Komponenten wie Ajax-DataTables Ausschau halten. Solche Komponenten lassen sich aber durch Plug-ins der JavaScript-Bibliothek jQuery ergänzen. Die Dokumentation ist wie bei allen Spring-Bestandteilen ausgezeichnet. Zudem gibt es eine Fülle von Fachliteratur. Dadurch, dass Spring MVC auf der Servlet-API ohne proprietäre Zusätze aufsetzt, laufen Spring-Anwendungen in jedem einfachen Webcontainer wie beispielsweise Jetty oder Tomcat.
Fazit: Spring MVC ist ein Modul des Spring Frameworks. Das Spring Framework ist weit verbreitet und genießt einen sehr guten Ruf in Entwicklerkreisen. Wer ohnehin Anwendungen auf Basis des Spring Frameworks entwickelt, für den ist Spring MVC sowohl technologisch als auch strategisch eine gute Alternative zum JEE-Standard.
JavaServer Faces
Im Gegensatz zu den anderen hier genannten Frameworks ist JavaServer Faces kein Framework, sondern eine Spezifikation. Sie ist das Ergebnis der Arbeit vieler Firmen, ein JEE-Web-Framework zu definieren (siehe Spezifikation-Requests). Trotz der Beteiligung vieler Firmen, muss man die erste JSF-Spezifikation als Fehlschlag ansehen. Die erste Referenzimplementierung enthielt so viele Fehler und Ungereimtheiten, dass der Ruf der JavaServer Faces schwer beschädigt wurde. Auch heute raten bekannte Firmen wie ThoughtWorks kategorisch von JavaServer Faces ab (siehe Technology Radar von ThoughtWorks vom Januar 2014, Seite 12). Das ist aber nicht mehr begründet, denn mit JSF 2.2 liegt mittlerweile eine ausgereifte Spezifikation mit sehr guten Implementierungen vor.
Neben der Referenzimplementierung "Mojarra" können JSF-Entwickler auch "MyFaces" von der Apache Software Foundation als Basis-Framework verwenden. MyFaces ist vollständig kompatibel zum Standard und hat darüber hinaus noch einige weitere Oberflächenkomponenten im Lieferumfang. Wem das nicht reicht, der kann das Basis-Framework um weitere Komponenten aus Erweiterungen wie ICEfaces, RichFaces oder PrimeFaces ergänzen. Besonders PrimeFaces bietet exzellente Ajax-UI-Komponenten wie zum Beispiel Datentabellen, ImageCropper und Menüs. Hier gibt es praktisch keine Konkurrenz unter allen Frameworks dieses Vergleichs.
JavaServer Faces ähnelt im grundsätzlichen Aufbau Struts. Wie der Vorläufer propagiert JSF eine Model-View-Controller-Architektur. Das Model sind hierbei Plain-Old-Java-Objects (POJOs), die die Geschäftslogik und die zur Anzeige benötigten Daten beinhalten. Views sind seit JSF 2.0 nicht mehr JavaServer Pages, sondern Facelets. Sie bestehen aus XHTML-Code. Jede View ist in der Regel mit einer so genannten Backing Bean gekoppelt. Backing Beans dienen Mittler zwischen Model, View und dem Faces-Servlet, das die eigentliche Steuerung der Webanwendung übernimmt (Controller). Sie werden vom Container (Tomcat etc.) verwaltet.
Wichtig ist der Request-Response-Lebenszyklus: Eine Anfrage durchläuft verschiedenen Phasen bevor die Antwort an den Client geschickt wird (siehe Abbildung). Sie beginnt mit der Wiederherstellung der View (Schritt 1), geht weiter mit dem Anwenden der Request-Parameter (Schritt 2) und der Eingabevalidierung (Schritt 3), dem sich die Aktualisierung des Models anschließt (Schritt 4). Ist die Validierung abgeschlossen, wird die Anwendung weiter ausgeführt (Schritt 5) und die Antwort gerendert (Schritt 6). Zu vielen Missverständnissen führt die Einflussnahme auf den Lebenszyklus, zum Beispiel dem Immediate-Attribut, denn dadurch werden unter Umständen bestimmte Phasen übersprungen.
Wie Struts enthält auch JSF ein Validations-Framework mit einigen bereits einsatzbereiten Validatoren (E-Mail, Kreditkarten etc.). Validatoren können pro Feld definiert werden oder auch global eine gesamte View validieren. Eine weitere wichtige Eigenschaft von JSF ist die Konfigurierung des Page-Flows. Dazu gibt es in Entwicklungsumgebungen wie NetBeans und Eclipse einen grafischen Editor, mit dem der Page-Flow der gesamten Anwendung festgelegt werden kann, zum Beispiel wohin die Anwendung zum Beispiel nach der erfolgreichen Anmeldung eines Anwender verzweigen soll. Die Konfiguration wird in einer JSF-spezifischen Konfigurationsdatei abgelegt.
Fazit: JavaServer Faces ist heute nicht nur der JEE-Standard, sondern ein Web-Framework, das seine Kinderkrankheiten endlich überwunden hat. Gerade durch Komponentensammlungen wie zum Beispiel PrimeFaces ist JSF eine sehr gute Alternative zu allen anderen Java-Web-Frameworks. Firmen, die auf diesen Standard setzen, werden keine Probleme bekommen, ausreichend qualifizierte Fachkräfte zu bekommen.
Vaadin
Abseits der klassischen Web-Frameworks wie Struts hatte eine Gruppe von Entwicklern die Idee, Web-Frameworks noch stärker als bisher mit JSF, Spring MVC und Struts von der Webentwicklung zu abstrahieren. Das erste Framework dieser Art war das Google Web Toolkit (GWT), ein Java-Web-Framework, das im Jahr 2006 vorgestellt wurde. Verglichen mit den bisher genannten klassischen MVC-Frameworks sind relativ wenige Web-Kenntnisse notwendig, um eine Java-Webanwendung zu entwickeln. Stattdessen wird hauptsächlich in Java entwickelt. Ein Cross-Compiler übersetzt dann den Java-Quellcode in eine komplizierte Java-Script-Anwendung. Die starke Abstraktion von der Web-Entwicklung setzt Vaadin fort.
Vaadin erschien im Jahr 2002 unter dem Namen "IT Mill Toolkit" als Teil des Millstone-Web-Frameworks. Erst im Jahr 2009 wurde es in Vaadin umbenannt. Aktuell ist die Version 7.2.2 die unter der Apache-Lizenz steht. Seit Vaadin das GWT zur Darstellung von Web-Seiten adaptierte, ist das Framework einer breiteren Öffentlichkeit bekannt (siehe Die Zukunft von GWT heißt Vaadin). Mittlerweile haben einige populäre Anwendungen das Web-Framework für sich entdeckt wie zum Beispiel das Java-CMS Magnolia (siehe Magnolia-Präsentation zum Thema). Vaadin erlaubt es wie GWT, eine Web-Anwendung komplett in Java zu entwickeln.
Die Architektur basiert auf dem Google Web Toolkit. Die Arbeitsteilung zwischen Client und Server ist so, dass auf der Client-Seite Vaadin-Widgets und eigene Widgets ausgeführt werden. Sie kommunizieren auf der Serverseite mit einem speziellen Vaadin-Servlet (siehe Abbildung). Das Programmiermodell erinnert an Swing. Die Programmierung findet wie bei beim Google Web Toolkit ausschließlich in Java statt. Das bedeutet, dass Views nicht gescripted, sondern in Java programmiert werden. Dazu stehen die gängigen Komponenten und Layouts zur Verfügung. Eigene Komponenten können leicht ergänzt werden.
Für die Eclipse-Programmierung gibt es ein Vaadin-Plug-in, das vor allem das Anlegen von Vaadin-Web-Projekten erleichtert. Die Dokumentation ist ausgezeichnet. Es steht ein frei verfügbares Buch auf der Vaadin-Homepage zur Verfügung, das von der Architektur, über die Einrichtung der Entwicklungsumgebung bis zur Programmierung alles Wissenswerte leicht verständlich erklärt. Vaadin-Anwendungen sind zur Servlet-API 2.5 kompatibel und können in einem einfachen Servlet-Container wie Jetty oder Tomcat ausgeführt werden.
Fazit: Vaadin ist sicher das modernste der hier vorgestellten Frameworks. Die hohe Abstraktion von der Webentwicklung wird Seiteneinsteigern von Struts oder JavaServer Faces zwar nicht unbedingt gefallen. Reine Java-Entwickler, die sich mit GWT oder RAP beschäftigt haben oder von der Swing- oder SWT-Entwicklung kommen, werden es aber umso mehr begrüssen. Der Markt an Vaadin-Entwicklern ist zwar nicht gerade gross, aber das sollte das niemand abhalten, dieses interessante Framework zu evaluieren.
Fazit: Das Warten hat sich gelohnt
Die lange Wartezeit auf ein JavaEE-Webframework hat für einen vielfältiger Markt von Web-Frameworks gesorgt. Sowohl die JSF-Frameworks als auch die Alternativen Struts und Spring MVC haben eine sehr große Community und hohe Marktdurchdringung. Besonders Spring MVC und JSF sind für viele Webanwendungen auch langfristig eine sehr gute Wahl. Wer innovativere technologische Lösungen sucht, sollte Vaadin evaluieren. Bei der Auswahl ist beachten, dass auf lange Hinsicht eine Marktkonsolidierung einsetzen wird. Der JavaEE-Standard hat hierbei sehr gute Karten, sich weiter durchzusetzen.