Turbine - das Apache Web Application Framework, Teil 1

Power aus der Turbine

Fabian J. Theis

Das Apache-Projekt Turbine [1] hat sich mittlerweile zu einem professionell einsetzbaren Framework zum Erstellen komplexer Web-Applikationen entwickelt. Im praktischen Umfeld erprobt, stellt es dem Java-Entwickler eine Vielzahl verschiedener Tools, Techniken und Frameworks zur Verfügung. Model View Controller (MVC)-basiert, bietet es eine interessante Alternative für Datenbankanwendungen mit HTML-Präsentationsschicht.

Von Sun wird der J2EE-Ansatz in einem Model-View-Controlling (MVC)-Muster als Standard vorgeschlagen. Hierbei pictureen typischerweise Enterprise JavaBeans das Business-Modell, das in einem Applikationsserver mit der Datenbank kommuniziert. Zur Präsentation, also für die View, sollen Java Server Pages (JSPs) benutzt werden, welche sich die Daten aus dem Modell holen. Die Controlling-Struktur stellt dann ein Servlet dar, das auf Userrequests reagiert, das Modell ändert und eine neue View setzt. Sun nennt diese Architektur Model 2 MVC, im Gegensatz zur Model 1 MVC der Anfangszeit, das gar kein konsequentes MVC-Muster war, sondern in den JSPs sowohl als View als auch als Controller genutzt wurde [5], [3].
Durch diese Aufteilung ergeben sich bei größeren Anwendungen schnell einige Probleme: Hier ist es wichtig, den Entwicklungsprozess so weit wie möglich aufteilen zu können und durch komponentenbasierte Architektur die Wartbarkeit zu erhöhen. Beim Einsatz des Servlets als Controller ohne weitere Tools ergibt sich aber mit zunehmender Projektgröße ein fast nicht zu bewältigendes Switchstatement, das die Kontrollfunktionalität darstellt und Actions auf neue Views abpictureet. Um für große Projekte dieses Problem in den Griff zu bekommen, muss man daher nach sinnvoller Aufteilung der Architektur in Komponenten suchen (hierarchical MVC) und diese in das Servlet einbauen. Natürlich sollte man dies nicht in jeder Anwendung von Grund auf neu erfinden; beispielsweise könnte man sich des hauptsächlich JSP-basierten MVC Frameworks Struts [4], ebenfalls Teil des Apache Jakarta-Projektes, bedienen.
Ein weiteres Problem aber ist, dass man zwar MVC praktizieren kann, aber nicht dazu gezwungen wird! Das mag sich zunächst absurd anhören, doch ganz dem objektorientierten Paradigma folgend ist es nur logisch, nicht nur Kapselung auf dem Klassenlevel auszuüben, sondern auch eine Verpflichtung zur Einhaltung eines Design-Patterns zu fordern. Konkret bedeutet das, dass man JSPs zwar auf Wunsch ausschließlich zur Darstellung des Modells benutzen kann, man aber auch ohne weiteres Kontroll- und – weitaus schlimmer – Modellfunktionalität in eine Seite hineinprogrammieren kann. Häufig ist bei einer kleinen Änderung oder einem schnell einzubauenden Zusatzfeature die Versuchung zu groß, schnell ein paar Zeilen Code in das JSP einzufügen.
Für sehr große Anwendungen, bei denen die Userzahlen nicht von vornherein begrenzt sind und die womöglich strenge Zusatzanforderungen an Ausfallsicherheit oder ähnliches besitzen, geht sicher kein Weg an EJBs vorbei. In vielen Fällen jedoch wird man feststellen, dass ein unbedingter Einsatz von EJBs nur die Projektkosten (sowohl Implementierungszeit als auch Hardwarebedarf) in die Höhe treibt, ohne von den Skalierbarkeitsvorteilen profitieren zu können. In solchen Fällen kann man sich dann auf einfache JDBC-Datenbankaufrufe beschränken, als Zwischenschicht aber in jedem Fall ein objekt-relationales Hilfsmittel verwenden.

Ein Wind kommt auf

Ein etwas anderer Weg zu MVC-basierten Webanwendungen wird von Turbine beschritten. Turbine ist ein Open-Source-Projekt, das bereits seit 1999 in der Entwicklung ist und daher einen ausgereiften Eindruck macht. Das ist nicht immer positiv, beispielsweise ist viel Code noch zu wenig entkoppelt, was aber in der bald erscheinenden Version 2.2 behoben sein soll. Turbine stellt eine ganze Reihe von häufig benutzten Komponenten zur Entwicklung von Web Applikationen bereit (Tabelle 1

[Author:I]
), das Hauptaugenmerk liegt aber klar in einer Implementierung des MVC- Musters nach Apache-Art. Turbine unterstützt die Entwicklung in allen drei Teilen der MVC-Architektur: Für die Modellerzeugung wurde innerhalb von Turbine das objekt-relationale Tool Torque entwickelt, das aus einem in XML spezifizierten Datenbankschema die Entitäten der Geschäftslogik erstellt. Die View kann ebenfalls mit JSP-Seiten erzeugt werden, bevorzugt aber werden reine Templatelösungen [3] wie Webmacro, Freemarker oder Velocity, die ebenfalls Teil des Jakarta-Projektes sind. Wir werden im Folgenden, wie von den Entwicklern vorgeschlagen, ausschließlich Velocity benutzen. Ein Controller wird von Turbine ebenfalls bereitgestellt, so dass normalerweise gar keine eigenen doGet und doPost-Methoden implementiert werden müssen. Vielmehr werden Action-Klassen in eigenen Packages vom Turbine-Servlet als Controller aufgerufen. Diese nehmen dann die notwendigen Änderungen am Modell vor und setzen, falls nicht schon im Template geschehen, die neue View. Darüber hinaus kann man für jedes View-Template eine sogenannte Screen-Klasse schreiben, die die Daten für die Ansicht aus dem Modell aufbereitet. Die Erweiterung des MVC Model 2 von Sun um Actions wird daher von den Apache-Entwicklern selbst als MVC Model 2+1 bezeichnet – als kleine Anspielung auf die Marketing-Hypes der großen Konzerne.
In der aktuellen Version Turbine 2.1 wird obiges Modell als Standard favorisiert. Turbine 2.2 ist ein Updaterelease, in dem die Modularisierung konsequenter durchgesetzt ist und das OR-Mapping-Tool Torque und das Service-Framework Fulcrum vollends entkoppelt vom restlichen Turbine sind. In Turbine 3.0 hingegen soll ein wenig Abstand von Screen-basierten Darstellungen genommen und ein sogenanntes Pull-MVC-Modell durchgängiger umgesetzt werden. Die Views werden dann nicht mehr von Screens mit Informationen gefüttert, sondern holen sich die benötigten Daten aus sogenannten Pull-Tools, die entweder globalen, lokalen oder session-Scope besitzen können.
Turbine lässt sich aber nicht nur im Web einsetzen; man kann es auch im Standalone-Modus benutzen oder aber nur Einzelmodule verwenden wie Torque oder Fulcrum. Bei Instant-Solutions wird Turbine in zwei großen Projekten (B2B und CRM) erfolgreich eingesetzt. Weitere Anwendungen sind beispielsweise die Portal-Engine -Jetspeed und das Bug-Tracking-System Scarab (scarab.tigris.org).

Die Architektur von Turbine

Im folgenden soll die Architektur von Turbine skizziert werden, das Ganze wird später am Beispiel eines Web-Shops visualisiert. Dennoch ist es für das Verständnis von Turbine wichtig, zunächst den Ablauf eines typischen Request/Response-Zyklus zu untersuchen. An dieser Stelle sei auch auf den Übersichtsartikel über Turbine aus Java Magazin 2.2001 [2] und auf die relativ ausführliche Dokumentation zu Turbine verwiesen.
Wie bereits erwähnt, bedient sich Turbine einer Service-Architektur mit Namen Fulcrum, die durch Singletons realisiert, dem Anwendungsprogrammierer verschiedene Module bereitstellt. Tabelle 1 gibt eine Übersicht über die Services von Turbine 2.1. Auf alle Services kann hier nicht eingegangen werden, diese werden in der Dokumentation erklärt. Im Folgenden werden wir vor allem den Template- und den Velocity- Service sowie indirekt den DB- und den Assembler-Service verwenden.

Abb. 3: Physikalische Seitenstruktur, durch Layout aufgebaut

Vom Layout aus wird nun eventueller Code des Screens ausgeführt. Normalerweise wird in einer Screenklasse der Template-Context mit Daten aus dem Modell gefüllt. So kann zum Beispiel eine EJB des Geschäftsmodells aufgerufen und die von ihr zurückgelieferten Daten mit Cocoon transformiert und schließlich im Screen dargestellt werden. Das vom Screen erzeugte HTML wird in die Seite an der vom Layout vorgegebenen Position eingefügt.
Schließlich wird die Navigation aufgerufen, häufig teilen sich mehrere Seiten oder sogar die ganze Anwendung Navigationselemente, die in diesem Modul zusammengefasst und für mehrere Screens benutzt werden können. Ebenfalls kann hier Code einer Navigationsklasse ausgeführt werden, anschließend werden die Navigationslücken im Layout aufgefüllt. Die nun fertige HTML-Seite wird dem Benutzer zurückgegeben und ein neuer Zyklus beginnt. Man sieht also, dass das Page-Konzept eine objektorientierte Darstellung eines HTML-Dokumentes ist und die Actions zusammen mit den Seiten Controller und View des MVC-Konzeptes darstellen.
Schließlich sei erwähnt, dass all die zur Seitenerzeugung instantiierten Objekte durch einen synchronisierten Caching-Mechanismus für mehrere Seiten wiederverwendet werden, um Ressourcen zu sparen. Zudem sind die einzelnen Klassenloader in der Turbine-Konfigurationsdatei so geschickt ausgelagert, dass ein Upgrade des Kernsystems von Turbine keine Veränderung an den Modulklassen benötigt – man ändert einfach die Klassenloader.

Systemablauf

Im Systemablauf wird dargestellt, wie die einzelnen Request-Response-Zyklen zur Benutzerführung ineinander greifen. Nach einem Request prüft das Turbine-Servlet zunächst, ob der Benutzer bereits in einer Session ist. Wenn ja, so wird diese zwischengespeichert, andernfalls wird die definierbare Login-Seite als Screen gesetzt und eine neue Session erzeugt. Dann wird das RunData-Objekt, eine High-Level-Erweiterung eines HTTP-Requests, für diesen Request vollständig initialisiert und eventuelle Parameter geparst und in einem Parameter-Objekt bereitgestellt. Ist eine Action mit Namen LoginUser als auszuführende Action angegeben, so wird diese nun ausgeführt und anschließend wird ein SessionValidator aufgerufen, der prüft, ob der Benutzer tatsächlich eingeloggt ist. Die überschreibbare Standardimplementierung setzt im negativen Fall die Startseite; diese Funktionalität kann aber überschrieben werden, wenn ein nicht eingeloggter Benutzer mehrere Seiten sehen soll. Anschließend geht der Request-Zyklus mit dem Page-Aufruf weiter wie oben dargestellt.
Sollte in einer der Klassen ein Fehler auftreten und eine Exception geworfen werden, so fängt das Turbine- Servlet diese auf und stellt anstatt des Standard-Screens den konfigurierbaren Error-Screen aus, welcher, abhängig vom User, verschiedene Informationen über den Fehler ausgeben kann.

Sicherheit und Benutzerkonzept

Turbine stellt bereits von Haus aus ein ausgeklügeltes Benutzerkonzept bereit. Hierbei können einem Benutzer mehrere Rollen in verschiedenen Gruppen zugewiesen sein. Eine Rolle ist eine Vereinigung von verschiedenen Rechten, dem granularsten Teil des Konzeptes. Gruppen dienen einer weiteren Aufteilung nicht in vertikaler, sondern in horizontaler Richtung, können aber auf Wunsch auch ignoriert werden. Für jeden identifizierten, also eingeloggten Benutzer wird eine AccessControlList aufgebaut, in der man prüfen kann, ob der Benutzer das jeweilige Recht oder aber auch die gewünschte Rolle, eventuell in einer bestimmten Gruppe hat. In der Beispielanwendung werden wir zwei verschiedene Rollen wie Käufer und Administrator haben, Gruppen und Rechte jedoch nicht gesondert verwenden.
Dennoch wird jeder, der ein paar Web-Anwendungen mit eigener Benutzerverwaltung geschrieben hat, sich freuen, dass dieses Modul bereits gut ausgearbeitet vorliegt. Im Standardfall wird übrigens obige Aufteilung mittels Torque in die angegebene Datenbank persistiert (Abpictureung 6). Darüber hinaus stellt Turbine unter dem Namen Flux eine Reihe von einfachen Screens und Aktionen zur Verfügung, die die webbasierte Benutzerverwaltung ermöglichen.

Zusatzmodule

Ein weiteres von Turbine bereitgestelltes Modul ist das mittlerweile völlig entkoppelte objekt-relationale Datenbanktool Torque. Nach Angabe einer datenbankunabhängigen XML-Beschreibung des Datenschemas generiert Torque hierbei eine Reihe von Klassen, die die einzelnen Zeilen und Tabellen der Datenbank repräsentieren. Sie können und sollen als Entitäten des Geschäftsmodells verwendet werden. Datenbankabfragen können ebenfalls ohne explizites SQL mittels sogenannter Criteria-Objekte (weitestgehend) datenbankunabhängig beschrieben werden. Torque baut hierbei auf die Datenbank API Village auf und benutzt ein Peer-Modell, um Datenbanken durch Adaptoren so gut wie möglich abstrakt zu beschreiben und um so viel Datenbankanbieter wie möglich zu unterstützen (wer weitere Informationen über das Tool sucht, dem sei die Dokumentation von Torque empfohlen).
Ein weiteres häufig benutztes Modul ist der Velocity-Service, der die Template Engine Velocity des Apache-Projektes in Turbine integriert [2]. Velocity ermöglicht die einfache Erstellung von HTML-Views ohne Programmierkenntnis, weshalb die Views tatsächlich von Designern und nicht von Programmiern erstellt werden können.

Schlussbemerkung

Nach all der grauen, aber notwendigen Theorie in diesem ersten Teil des Turbine-Artikels werden wir uns in der nächsten Java Magazin-Ausgabe an ein konkretes Beispielprojekt machen. Anhand einer simplen Shop-Anwendung sollen einige einfache Features von Turbine im Rahmen einer kleinen Beispielanwendung dargestellt und die oben erläuterten Konzepte visualisiert werden. Im Netz ist das Beispiel schon jetzt zu studieren: www.datasign.de/projekteISJavaShop.html.

Geschrieben von
Fabian J. Theis
Kommentare

Schreibe einen Kommentar

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