Frameworks

Java als objektorientierte Sprache tendiert dazu, große Sammlungen von Klassen zu bilden. Jede Klasse für sich betrachtet ist verständlich und hat eine klar umrissene Aufgabe. Für sich genommen nützen die einzelnen Klassen jedoch nichts, da sie nur einen kleinen Bereich der nötigen Funktionalität abdecken. Frameworks bündeln daher Klassen, die die oft sehr ähnlichen Anforderungen von Webanwendungen abdecken, und ersparen es, das Rad neu zu erfinden. Für die Webentwicklung bedeutet der Einsatz eines Framework, dass der Entwickler mit den Low-Level-APIs programmieren kann, aber nicht muss.

Wer innerhalb von Firmen entwickelt, hat in Sachen Frameworks meist konkrete Vorgaben. Viele Applikationsserver bringen ihr eigenes Framework mit. Wer aber frei von solchen Voraussetzungen mit Java-Programmierung beginnt, sollte sich zumindest die Frameworks der Apache Foundation näher ansehen.

Mit Struts [2] steht ein über die Jahre gut gepflegtes Framework für die Webentwicklung zur Verfügung, das in vielen Projekten erfolgreich zum Einsatz kommt. Struts verwendet das klassische MVC-Design (Model View Controller). Besonders hervorzuheben ist die gute Dokumentation. Neben Wikis und Online-Ressourcen gibt es auch viele Bücher. Cocoon [3] ist eine Alternative, die bereits mächtige Features für den Publishing-Bereich enthält.

Nicht von der Apache Foundation stammt das Projekt Spring [4]. Es eignet sich für viele unterschiedliche Anwendungsbereiche, ist sehr mächtig und dient inzwischen auch anderen Projekten als Basis. Cocoon zum Beispiel setzt in der neuesten Version auf Spring.

Mehr als Webentwicklung

Alle bisher vorgestellten Technologien dienen dazu, den HTML-Code einer Webseite zu erzeugen und an den Benutzer auszuliefern. Das ist aber nur ein Aspekt der Webentwicklung. Nur kleine "Hello World"-Anwendungen kommen ohne Datenbank aus. Wichtig ist auch die Zugriffskontrolle, die gewährleistet, dass nur identifizierte Nutzer Aktionen auslösen oder Daten einsehen dürfen. Hier zeigt sich der große Unterschied zwischen Java-Webanwendungen und jenen in anderen Sprachen: Der Java-Ansatz verlagert die Verantwortung aus der Webanwendung in die Laufzeitumgebung, den Applikationsserver.

Die Spezifikation Java 2 Enterprise Edition (J2EE) hat in bester Java-Tradition Services für die Ablaufumgebung von Webanwendungen in Form von Interfaces definiert. Damit war und ist es recht einfach, Anwendungen, die diesem Standard entsprechen, in beliebige Applikationsserver-Umgebungen zu installieren. Wie bei den anderen APIs gab es jedoch mehrere Fassungen der J2EE-Spezifikation. Die ersten Versionen versuchten Datenbankzugriffe, Rollen- und Rechteverwaltung und vieles andere zu kapseln und vor der Webanwendung zu verbergen. Dieser Ansatz scheiterte.

Der Deployment-Deskriptor, der den Installationsprozess in einen Anwendungsserver in XML-Form beschreibt, verdeutlicht beispielhaft das Problem, es war ähnlich gelagert wie bei den Applets: Die Theorie abstrahierte in den frühen J2EE-Standards zu sehr von den realen Bedingungen. Als Folge entwickelten die einzelnen Applikationsserver proprietäre Erweiterungen des Deployment-Deskriptors, was die Anwendungen an einen bestimmten Server band. Die aktuelle J2EE-Spezifikation hat sich daher vom deklarativen XML abgewandt und setzt wieder verstärkt auf handgeschriebenen Programmcode.