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.