19.14 Zum Weiterlesen 
Sun hat zum Thema Webtechnologien viel auf den Webseiten http://java.sun.com/products/jsp/ und http://java.sun.com/products/servlet/ veröffentlicht. Allerdings reicht das Wissen nicht aus, um wirklich moderne Web-Applikationen zu entwickeln. Vielmehr sind JSP und Servlets die Basis jeder HTTP-getriebenen Anwendung. Tag Libraries (http://java.sun.com/products/jsp/taglibraries/) – unter ihnen besonders die JavaServer Pages Standard Tag Library (http://java.sun.com/products/jsp/jstl/) und Jakarta Taglibs (http://jakarta.apache.org/taglibs/) – sind die Gewürze, die JSPs erst richtig schmackhaft machen. Servlets dienen (neben der seltenen Generierung von binären Dokumenten) lediglich dazu, als Front-Controller (http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html) Anfragen vom Client entgegenzunehmen und an die View weiterzuleiten. Diese Weiterleitung selbst zu schreiben, erübrigt sich mit der Masse an MCV-Frameworks; Sun dokumentiert die Notwendigkeit im »Dokument Designing Enterprise Applications« (http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html). Als Standard-Framework kristallisiert sich mehr und mehr JavaServer Faces (http://java.sun.com/javaee/javaserverfaces/) heraus, was dem klassischen Struts (http://struts.apache.org/) für Neuapplikationen den Rang abläuft. Facelets (https://facelets.dev.java.net/) basiert auf Faces, erzwingt aber eine saubere Trennung von HTML und Logik.
Webanwendungen nur mit einem einfachen Editor zu schreiben, ist aufwändig und fehlerträchtig. Entwickler-Teams sollten sich von Tools unter die Arme greifen lassen, um zum Beispiel den Pageflow visuell zu modellieren und die Konfigurationsdateien schnell über Wizards zu generieren. Im Eclipse-Umfeld macht das »JavaServer Faces Tooling Project« (http://www.eclipse.org/webtools/jsf/) – ein Teil vom WTP – eine gute Figur.
Webanwendungen wirken auf den ersten Blick – mit einigen Klicks – so, als wären sie leicht zu entwickeln, sind aber bei genauerem Hinsehen in puncto Lastverteilung/Clustering (Tomcats Clustering wird immer besser) und Ausfallsicherheit bei großen Sites mit Sicherheit nicht trivial. Besonders die Sicherheit (Web Application Security) vernachlässigen Entwickler gern bis zum Ende, um dann Teile wie unzureichend geprüfte Eingaben oder Authentifizierung anpassen zu müssen. Peinlich war zum Beispiel die Situation für die Firma Gateway, die jedem registrierten Benutzer eine sechsstellige ID zuwies und als Identifizierung an den Server schickte. Natürlich war es kein großes Problem, diese ID anders zu generieren und Informationen anderer Benutzer abzurufen. Der zeitlose Report »The Ten Most Critical Web Application Security Vulnerabilities« (http://prdownloads.sourceforge.net/owasp/OWASPTopTen2004.pdf) sensibilisiert für die Problematik. Injizierungsfehler (wie SQL-Injection, mit Beispielen etwa unter http://www.unixwiz.net/techtips/sql-injection.html beschrieben) und Cross-Site-Scripting (http://de.wikipedia.org/wiki/Cross-Site_Scripting) sind mittlerweile Fehler-Klassiker, die es zu vermeiden gilt.