Wicket - Komponentenbasiert und objektorientiert - das alternative Java-Webframework

3 Java im Web

Der Startschuss zum World Wide Web (WWW), wie wir es heute kennen, erfolgte im Jahr 1993 mit der Freigabe von Mosaic, dem ersten freien Webbrowser. War das damalige Netz noch stark auf die Auslieferung statischer Inhalte fokussiert, bot das neue Medium deutlich mehr.

Um dieses Potenzial zu nutzen, wurde die Basis für einen neuen Standard zur Auslieferung dynamischer Inhalte entwickelt. Unter dem Namen Common Gateway Interface (CGI) wurde eine Laufzeitumgebung für Serverseitige Skripte und Programme definiert. Die größte Schwäche dieser Spezifikation waren die hohen Anforderungen an den Server. Für jeden Request wurde ein eigener Prozess erzeugt, in dem das jeweilige Programm ausgeführt wurde. Das wurde vor allem deshalb zum Problem, weil praktisch alle diese Programme in irgendeiner Skriptsprache geschrieben waren. So musste für jeden Request der Interpreter gestartet werden, was oft ein Vielfaches der Laufzeit des eigentlichen Skripts darstellte. Schnell wurde eine Erweiterung des bestehenden Standards unter dem Namen FastCGI entwickelt, um die Serverlast zu reduzieren. FastCGI erlaubte es, mit Programmen via TCP oder Unix Domain Sockets zu kommunizieren. Ein entsprechendes Programm musste nur einmal instanziiert werden und konnte dann für beliebig viele Requests verwendet werden. Durch die Verwendung von Sockets war es sogar möglich, die entsprechenden Programme auf anderen Servern zu betreiben.

Aber selbst dieser Ansatz wurde bald an seine Grenzen getrieben und man begann, nach Werkzeugen zu suchen, die für die Erstellung dynamischer Webpräsenzen besser geeignet waren. Der wichtigste Schritt auf diesem Gebiet war die Einführung eines Modul Layers in Apache, dem wichtigsten Webserver. Damit war es möglich, eigene Module zu registrieren, die ähnlich wie FastCGI nur einmal geladen wurden und dann so viele Requests wie nötig beantworten konnten. Meist verbargen sich Interpreter von Skriptsprachen hinter folgenden Modulen:

• mod_perl: Die wohl älteste für diese Aufgabe eingesetzte Skriptsprache. In diesem Buch soll sie aber nicht näher betrachtet werden
• mod_python: Python ist eine sehr elegante Sprache. Meine erste Begegnung mit Python für Webapplikationen war allerdings Zope.
• mod_php: Wohl das bekannteste installierbare Sicherheitsloch im Webumfeld.

Java fristete in der Anfangszeit noch ein Schattendasein, was sich im Jahr 1997 durch die Freigabe der Servlet-Spezifikation änderte.

3.1 Servlets und JSPs

Die Geschichte des Servlet API scheint durchaus Anlass für Diskussionen zu geben, weshalb ich hier nur auf einen kurzen, aber informativen Blog-Post1 von Jim Driscoll verweisen will. Viel wichtiger für uns sind die Auswirkungen von Servlets auf Java. Aus der Spezifikation ergaben sich mehrere wichtige Grundlagen für heutige Java-Webanwendungen. Da wäre zum einen das Servlet API. Hier wurden sowohl Protokolleigenschaften von HTTP als auch Erweiterungen wie HTTP-Sessions verfügbar gemacht. Auf diesem API aufsetzend wurden die Java Server Pages (JSP) geschaffen. JSPs erlaubten es, Markup und spezielle Tags samt eingebettetem Java-Code zu vereinen (Listing 3.1). Das Ergebnis wurde dann von einem speziellen Compiler on the Fly in Servlets umgesetzt.

Listing 3.1: JSP-Beispiel

Ein neues Deployment-Format wurde geschaffen, um Servlet-API-basierte Applikationen zu bündeln. Diese so genannten Web Application Archives (WAR) stellten eine Erweiterung der bereits existierenden Java Archives (JAR) dar. Jetzt war es möglich, Webressourcen und den Deployment-Deskriptor in Form der web.xml innerhalb des Archivs zu hinterlegen (Listing 3.2).

Listing 3.2: Aufbau einer WAR-Datei

All diese Neuerungen machen natürlich nur Sinn, wenn auch eine entsprechende Laufzeitumgebung existiert. Sie wurde und wird durch sogenannte Servlet-Container bereitgestellt. Heute gibt es dutzende davon, sowohl kommerziell als auch Open Source. Die bekanntesten Open-Source-Vertreter dürften wohl Tomcat und Jetty sein. Es wurde auch nötig, neue Herangehensweisen an die Entwicklung von Applikationen anzupassen. Das Ergebnis waren zwei neue Entwicklungsmodelle.

3.1.1 Model 1

Der als Model 1 bezeichnete Ansatz war die einfachste Form der Webanwendung. Hier wurde alle Logik innerhalb der JSP abgebildet. Eine Trennung zwischen Darstellung und Logik fand nicht statt. Das führte bei komplexeren Anwendungen zu starker Codeduplizierung und unverhältnismäßig hohem Wartungsaufwand. Ich habe hier die Vergangenheitsform gewählt, weil die Anwendung von Model 1 heutzutage eher unter dem Begriff „Antipattern“ einzuordnen ist.

3.1.2 Model 2

Model 2 markierte einen wichtigen Wendepunkt in der Java-Webentwicklung. Zum ersten Mal wurde eine strikte Trennung zwischen dem Darstellungs- und dem Kontroll-Layer eingeführt (Abbildung 3.1). Diese Trennung kann durchaus als Fundament des Model-View-Controller-Patterns angesehen werden (mehr hierzu in Kapitel 9).

Abbildung 3.1: Model 2

Bei Model-2-Anwendungen übernimmt das Servlet die Aufgabe des Controllers. Es nimmt eingehende Requests entgegen und wertet sie aus. Um die Response zu erzeugen, delegiert das Servlet an eine entsprechende JSP. Die JSP verwendet vom Controller bereitgestellte Java Beans, um auf die darzustellenden Daten zuzugreifen. Durch diese Trennung von Verantwortlichkeiten war es nun möglich, auch äußerst komplexe Anwendungen zu entwickeln.

3.2 Wickets Vorfahren

Programmiermodelle wie Model 2 oder MVC bilden das Fundament vieler Webanwendungen, jedoch erschlagen sie nur die grundlegendsten Designprobleme. Durch immer komplexere Anforderungen wurde bald ersichtlich, dass Entwickler und Architekten weitere Hilfsmittel benötigen, um funktionierende Anwendungen zu entwickeln. Aus Bibliotheken zur Ablaufsteuerung, Ressourcenverwaltung und Backend-Konnektivität entwickelten sich vollständige Webframeworks. Unter ihnen gab es eine Reihe wichtiger Vertreter, die das Fundament für ihre heutigen Nachkommen bildeten. Im Folgenden möchte ich eine Auswahl der einflussreichsten Webframeworks vorstellen.

3.2.1 Struts

Struts ist ein Vertreter des Model-2-Prinzips und wurde im Jahr 2000 verfügbar gemacht. Es verbreitete sich vergleichsweise schnell und wurde traditionell insbesondere in großen Unternehmen der Banken- und Logistikbranche eingesetzt. Heute wird man es nur dann antreffen, wenn ein Kunde eine „kleine“ Zusatzfunktionalität oder die Ablösung seiner Applikation wünscht. Struts war und ist ein harter Brocken, an dem sich viele Entwickler die Zähne ausgebissen haben, und trotz seiner weiten Verbreitung gibt es mehr Kritik als an anderen Frameworks. Dieser Kritik war in meinen Augen ein wichtiger Katalysator für die Welle an Neuentwicklungen in diesem Bereich, die in den Jahren nach seiner Veröffentlichung über die Java-Welt hereinbrach.

3.2.2 Apache Velocity

Ähnlich wie Wicket ist Apache Velocity kein Fullstack-Webframework. Es ist eine reinrassige Templating Engine, die neben ihrer Anwendung im Webbereich auch für Codegenerierung eingesetzt wurde und wird. Dabei wird vor allem Wert auf die saubere Trennung von Logik und Darstellung durch die Anwendung des MVC-Patterns wertgelegt. Bis heute erfreut sich Velocity großer Beliebtheit und seine Art, Templates mit Java zu verbinden, kann durchaus mit der in Wicket verwendeten Variante verglichen werden.

3.2.3 Spring MVC

Lange Zeit war Spring MVC mein Favorit. Wie der Name verrät, basiert es auf dem beliebten Dependency-Injection-Container Spring und baut auf dem MVC-Pattern auf. Mein Interesse wurde aber erst so richtig durch die Verbindung mit Spring Web Flow geweckt. Das ermöglichte die Definition von Abläufen innerhalb der Applikation. Navigationspfade zwischen den Seiten der Applikation werden in separaten Flow-Definitionen abgelegt. Diese XML-Dateien können toolgestützt bearbeitet werden und bieten eine Entsprechung für die bereits in der Modellierung genutzten Aktivitätsdiagramme. Das bedeutete einen riesigen Fortschritt gegenüber seinen Vorgängern, da der Applikationsfluss nicht mehr durch das mühsame Interpretieren von Links oder Aktionen definiert wurde. Seiten wurden damit zu eigenständigen Entitäten, die durch eine separate Sprache miteinander verbunden wurden.

3.2.4 Ruby on Rails

Keine Liste wichtiger Webframeworks, egal in welcher Sprache, wäre vollständig ohne Ruby on Rails (RoR). RoR hat seinen großen Erfolg nicht irgendeinem neuen Designpattern oder anderen Gimmicks zu verdanken. Vielmehr zeichnet es sich durch die saubere Integration vieler bereits existierender Technologien und Ideen aus. Mit seiner Einführung im Jahr 2004 besann man sich zurück auf die Tugenden der Softwareentwicklung. Objektorientierte Prinzipien und die Bemühung, dem XML-Wildwuchs ein Ende zu bereiten, wurden schnell zum neuen Mantra in der Entwicklergemeinde. Das resultierende Convention-over-Configuration-Prinzip hatte gewaltigen Einfluss auf alles, was danach kam. Heute wirbt fast jedes neue Framework...