RESTful JavaServer Faces

Wenn man möchte, dass eine Webapplikation offen für unterschiedliche Anwendungsszenarien bleibt, dann hätte man in einem Szenario mit einer bereits existierenden JSF-Applikation die Möglichkeit, die gesamte Funktionalität noch einmal über zusätzliche REST-Schnittstellen anzubieten. Das könnte beispielsweise auf der Basis von JAX-RS [5] geschehen. Man müsste den gesamten Workflow der JSF-Applikation allerdings ein zweites Mal implementieren. Gemeinsame Fachlogik könnte man in Stateless Session Beans ausgelagert. Diese könnten dann sowohl von der JSF-Applikation als auch von den REST-Schnittstellen verwendet werden. Alternativ kann man allerdings auch von Anfang an ein Webframework verwenden, das es konzeptionell vorsieht, dass Views für Browser und Repräsentationen für andere Applikationen über dieselben Mechanismen angeboten werden. Als Beispiel für diesen Ansatz sind die Webframeworks Play [6] oder Spring Web MVC 3.x [7] zu nennen.

Schlussfolgerungen

Im Rahmen diese Artikels sollte deutlich geworden sein, dass JavaServer Faces in einem grundsätzlichen Widerspruch zur REST-Architektur steht. Man kann sich leicht auf den Standpunkt stellen, dass die Unterstützung von REST nicht die Zielsetzung der JSF-Spezifikation war. Das ist natürlich richtig. Die dargestellten Eigenschaften von JavaServer Faces haben allerdings Konsequenzen für jede Applikation, die mit JSF entwickelt wird. Das eigene Programmiermodell von JSF versetzt Entwickler in die Lage, dass sie sich nicht mit den Einzelheiten der HTTP-Spezifikation auseinandersetzen müssen. Die Folge ist aber, dass die Funktionalität einer JSF-Applikation hinter einer Benutzeroberfläche versteckt wird und nicht von anderen Applikationen verwendet werden kann. Eine JSF-Applikation ist ein geschlossenes System, auch wenn über GET zumindest lesender Zugriff auf Applikationsinhalte ermöglich werden kann.

Das bedeutet aber nicht, dass vom Einsatz von JavaServer Faces grundsätzlich abzuraten ist. JSF ist Teil der Java Enterprise Edition und funktioniert hervorragend im Zusammenspiel mit anderen JEE-Technologien. Das Programmiermodell von JavaServer Faces begünstigt eine saubere, klar strukturierte Architektur. Und der Komponentenansatz versetzt Java-Entwickler in die Lage, anspruchsvolle webbasierte Benutzeroberfläche zu implementieren, für die sonst unter Umständen umfangreiche JavaScript-Kenntnisse notwendig wären. Der Einsatz von JSF führt aber, wie dargestellt, zu einem geschlossenen System. Das sollte bei der Entscheidung für oder gegen JavaServer Faces aus Sicht des Autors nicht unberücksichtigt bleiben. Die Antwort auf die Frage „Kann mit man mit JSF eigentlich Webapplikationen entwickeln?“ ist letztlich davon abhängig, ob man anstrebt, die zu implementierende Funktionalität zu einem Bestandteil des Webs zu machen.

Holger Kraus ist bei der innoQ Deutschland GmbH als Senior Consultant tätig. Er beschäftigt sich mit der Architektur und Realisierung verteilter Anwendungen. An REST fasziniert ihn der nur scheinbare Widerspruch von Einfachheit und Mächtigkeit.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.