s c h we r p u n k tk o m p l e x e w e b - a n w e n d u n g e n m i t „ s t r u t s ”

v o n c h r i s t i a n k a m m u n d c a r s t e n k l e i n

KOMPLEXE WEB-ANWENDUNGENMIT „STRUTS”

Das Struts-Framework erwartet vomNutzer, dass er die Aktionssteuerung konfi-guriert und die anwendungsspezifischenStruts-Aktionen (Action) und Struts-Formulare (ActionForm) implementiert.Struts ist ein schlankes Framework, das imWesentlichen aus sechs zentralen Klassenbesteht (siehe Abb. 1). Es etabliert eine guteTrennung von Außen- und Innensicht,sodass der Lernaufwand gering ist. Nachzwei Tagen hat man Struts verstanden.Dabei helfen die gut dokumentierten Struts-Quellen und die Beispielanwendungen.

Struts-KomponentenDie zentrale Klasse von Struts ist dasActionServlet. Es implementiert dieAktionssteuerung der Anwendung. DasActionServlet nimmt alle eingehendenHTTP-Anfragen der Anwendung entgegen,führt die zugehörigen fachlichen Aktionen(Action) aus, und leitet zu den JSPs weiter,die die HTTP-Antwort erzeugen.

Bei Eingabeformularen (HTML-Forms)werden vor dem Ausführen einer Aktiondie Benutzereingaben aus der HTTP-

Das Open-Source-Framework „Struts” eignet sich gut für einfache, zustandslose Web-Anwendungen. Für komplexe Anwendungen mit zustandsbehafteten Dialogen trägt dieserAnsatz nicht. Zum einen bietet Struts keine Unterstützung für eine Zustandshaltung imDialog, zum anderen führt der naive Einsatz von Struts zu einer starken Vermischung vonAnwendungslogik und Technik. In dem Artikel wird gezeigt, wie man Struts um eineDialogschicht erweitert und damit auch komplexe Web-Anwendungen beherrschbar macht.

m e h r z u m t h e m a :www.sdm.de/research

26 27

Christian Kamm(E-Mail: christian.kamm@sdm.de)ist Berater bei der sd&m AG. Sein tech-nisches Schwerpunktthema ist dieKonstruktion von grafischenBenutzungsschnittstellen.

Carsten Klein(E-Mail: carsten.klein@sdm.de) hatmehrjährige Erfahrungen in der Leitungvon Projekten und dem Design objekto-rientierter Systeme. Derzeit ist erWissens-Broker für Clientarchitekturenbei sd&m Research.

d i e a u t o re n

Framework Struts hilft beim Erstellenweb-basierter Anwendungen, indem es dieTrennung der Zuständigkeiten von Model,View und Controller in der Architekturetabliert (vgl. [Brow01], [Str02]). EinVergleich verschiedener Web-Frameworksfindet sich unter [Bar02].

Im Folgenden skizzieren wir denLeistungsumfang von Struts und stellendie Stärken und Schwächen diesesFrameworks dar. Anschließend zeigen wir,wie man durch das Einführen einer tech-nikneutralen Dialogschicht die Kopplungzwischen Anwendung und JSP/Servlet-APIreduziert und damit in der Architektur anFlexibilität gewinnt.

Was bietet Struts?Struts ist ein Open-Source-Framework fürWeb-Anwendungen, die auf JSP/Servlet-Technik basieren. Struts wird im Jakarta-Projekt der Apache-Gruppe entwickelt(vgl. [Str02]) und implementiert dieModel-2-Architektur (vgl. [Brow01]), eineVariante des MVC-Patterns.

Aufwand und NutzenDas Struts-Framework bietet dem Nutzereine konfigurierbare Aktionssteuerung,die eingehende HTTP-Anfragen aufanwendungsspezifische Aktionen abbildet.Diese Aktionssteuerung wird über eineXML-Datei konfiguriert.

Struts unterstützt bei der Entwicklungvon formularbasierten Oberflächen. Sowerden z. B. Benutzereingaben automa-tisch aus der HTTP-Anfrage ausgelesenund serverseitig in anwendungsspezifischeFormulare (ActionForms) übernommen.Optional wird dabei eine formularbasierteValidierung am Server durchgeführt.

Außerdem stellt Struts umfangreicheTag-Bibliotheken zur Verfügung, die dasErstellen der JSPs vereinfachen. Diese Tag-Bibliotheken bieten unter anderemUnterstützung für Iteratoren, das Erstellenund Manipulieren von JavaBeans und dieInternationalisierung von Meldungen.

Die unterschiedlich schnellen Innovations-zyklen von Fachlichkeit und Technik stel-len ein Grundproblem in der Software-technik dar: Während sich die technischeBasis in ständigem Wandel befindet, blei-ben die Anwendungen in ihrem Kern oftüber Jahre hinweg stabil. Die Blueprintsder Produkthersteller (vgl. [Sad00],[Kas00]) sind dabei wenig hilfreich. Siefokussieren zu sehr die gerade aktuellenTechnologien oder den Einsatz ihrer Pro-dukte und beschränken sich meist auf dieAngabe von Anwendungstopologien.Antworten auf diese Kernfrage des Soft-waredesigns für betriebliche Informations-systeme bieten sie nicht.

Dabei hat Dave Parnas bereits 1972 diepassende Antwort formuliert: Software, diesich unterschiedlich schnell ändert, wird inunterschiedliche Module aufgeteilt (vgl.[Par72]). Die Firma sd&m hat diesesGrundprinzip von Parnas für betrieblicheInformationssysteme konkretisiert (vgl.[Sie00], [Brö99]). Die Software-Blut-gruppen stellen ein verlässliches Instrumentzum Erstellen und Bewerten von Soft-warearchitekturen dar (siehe Kasten 1).

Die Kernaussage der Blutgruppen-Theorie ist, dass man anwendungsspezifi-schen Code (A-Code) und technikspezifi-schen Code (T-Code) in der Architekturstrikt trennen sollte, um Erweiterbarkeitund Wartbarkeit zu garantieren. Geradebei Benutzungsschnittstellen ist diese AT-Trennung wichtig: Hier gibt es keinenanerkannten technischen Standard, wiez.B. SQL für Datenbanken. Stattdessengibt es eine Vielfalt von proprietären undoft unausgereiften APIs für Benutzungs-schnittstellen (UI-APIs), die sich in jährli-chem Rhythmus ändern.

Bei einer zu starken Kopplung von An-wendung und UI-API muss bei einemWechsel der API nicht selten die ganzeAnwendung neu gebaut werden.

Für Web-Anwendungen mit Java sindJava Server Pages (JSPs) und Servlets derStand der Technik. Das Open-Source-

w w w. o b j e k t s p e k t r u m . d e

Was bietet Struts nicht?DialogschichtStruts unterstützt zustandslose Anwen-dungen. Komplexe Anwendungen zeichnensich jedoch gerade durch eine komfortableBenutzerführung und ein Dialoggedächtnisaus. Im Dialoggedächtnis werden bereitsgetätigte Benutzerinteraktionen undDialogdaten verwaltet (vgl. [Kam01]).Somit kann die Anwendung zustandsab-hängig auf Benutzereingaben reagieren.Dazu braucht man in der Architektur desSystems eine ausgeprägte Dialogschicht,wie sie in [Den91] beschrieben ist.

Struts kennt keine Dialoge, sondern nurAktionen. Diese sind zu fein-granular, umdie Fachlichkeit eines Dialogs abzubilden.Sie sind also für die Modularisierung derDialogschicht nicht geeignet. Stattdessenmüssen dazu mehrere Aktionen gebündeltwerden, die miteinander kooperieren.Diese Kooperation verlangt eine gemein-same Datenhaltung. Die Daten in denAktionen zu halten (z. B. als Member-Variablen), ist deshalb nicht möglich, weilAktionen pro Anwendung nur einmalinstanziiert werden und keine exklusivenRessourcen einer Sitzung darstellen. Siemüssen thread-sicher programmiert wer-den (vgl. [Str02], [Dav99], [Pel99]).

Daher wird zum Datenaustausch zwischenAktionen meist die HttpSession benutzt, inderen Attributen sitzungsbezogene Datenabgelegt werden können. Damit führt manallerdings sitzungsglobale Variablen ein (dieProblematik globaler Variablen wurde bereitsin [Wul73] hinreichend erläutert). AlsKonsequenz droht schwer verständlicher undschwer wartbarer Code.

ModelltransformationZur Trennung von Präsentation undDialog stellen sich einer Architektur für

w w w. s i g s - d a t a c o m . d e3 / 2 0 0 2

s c h we r p u n k tk o m p l e x e w e b - a n w e n d u n g e n m i t „ s t r u t s ”

Anfrage in das zugehörige serverseitigeFormular (ActionForm) übertragen.Optional werden die Benutzereingabenvalidiert, sofern man die validate-Methodeder ActionForm entsprechend implementiert.

Die anwendungsspezifische Beschrei-bung der Aktionssteuerung erfolgt in derKonfigurationsdatei struts-config.xml. Hierwird in XML beschrieben, welche Aktionfür welche URI ausgeführt werden sollund gegebenenfalls welches Formular ser-verseitig für die Benutzereingaben verwen-det wird. Sowohl für Aktionen als auchfür Formulare stellt das Struts-FrameworkBasisklassen bereit.

Jede Aktion liefert als Ergebnis ihrerperform-Methode einen ActionForward andie Aktionssteuerung zurück. Über diesenActionForward führt die Aktionssteuerungden nächsten Verarbeitungsschritt aus. DieAktion beschafft sich den passendenActionForward über ein ActionMapping, daszu einem symbolischen Namen einen

zugehörigen ActionForward liefert. EinActionForward kapselt den Pfad zu einerbeliebigen Ressource, die wiederum eineAction sein kann. Verkettungen vonAktionen werden somit möglich.

BlutgruppenSoftware, die sich mit verschiedenen Dingen gleichzeitig befasst, ist in jeder Hinsichtschlecht. Ein Paradebeispiel dafür im Umfeld von Web-Architekturen ist der seiten-zentrierte Ansatz. Eine JSP umfasst bei diesem Ansatz nicht nur Layout-Informationenund die Dialogsteuerung, sondern auch noch Anwendungslogik, Datenbankzugriffeund Fehlerbehandlung.

Die Idee der Zuständigkeitstrennung (Seperation of Concerns) kann man formali-sieren: Jedes Softwaresystem befasst sich mit der fachlichen Anwendung, denn dafürwurde es gebaut, und es verwendet eine technische Basis (Betriebssystem, Datenbank,Verbindungssoftware), denn im luftleeren Raum kann es nicht laufen. Daher gehörtjede Komponente zu genau einer von vier Kategorien:

0-Software ist unabhängig von Anwendung und Technik. Beispiele sindKlassenbibliotheken, die sich mit Strings und Behältern befassen, etwa die zumC++-Standard gehörige „Standard Template Library” (STL). Sie ist idealwiederverwendbar, für sich alleine aber ohne Nutzen.A-Software ist bestimmt durch die Anwendung, aber unabhängig von derTechnik. Anwendungsbestimmter Code kennt Begriffe wie „Fluggast”,„Buchung” oder „Fluglinie”.T-Software ist unabhängig von der Anwendung, aber bestimmt durch dieTechnik: Ein solcher Baustein kennt mindestens eine technisches API wie JDBC,JSP oder Servlet.AT-Software ist bestimmt durch Anwendung und Technik: leider eine häufiganzutreffende Form. Sie ist schwer zu warten, widersetzt sich Änderungen,kann kaum wiederverwendet werden und ist daher zu vermeiden, es sei denn,es handelt sich um R-Software.R-Software transformiert fachliche Objekte in externe Repräsentationen undwieder zurück. Beispiele für externe Repräsentationen sind Zeilen einerDatenbank-Tabelle, ein Bildschirmformat oder XML. R-Software kann häufigaus Metainformationen generiert werden.

Diese fünf Kategorien formalisieren die Trennung der Zuständigkeiten nur auf derobersten Ebene. Selbstverständlich sollte sich jede T-Komponente nur mit einer tech-nischen API befassen und nicht gleichzeitig mit zwei oder drei; jede A-Komponentesollte nur ein Anwendungsthema bearbeiten.

Kasten 1: Software-Blutgruppen

0

A

T

AT

R

Abb. 1: Struts-Komponenten und Blutgruppen

s c h we r p u n k tk o m p l e x e w e b - a n w e n d u n g e n m i t „ s t r u t s ”

28 29 w w w. o b j e k t s p e k t r u m . d e

Dialogbeschreibung mittels InteraktionsdiagrammenInteraktionsdiagramme (IAD) sind eine Variante endlicher Automaten. Ein IAD isteine formale Spezifikation eines Dialogablaufs und kann zur Laufzeit von derDialogsteuerung interpretiert werden, d.h. es ist automatisch ausführbar.

Im Unterschied zu einem klassischen endlichen Automaten unterscheidet ein IADzwischen Aktionen und Zuständen. In einem Zustand wartet das System auf eineBenutzeraktion bzw. ein Ereignis. Aktionen sind dagegen vom System ausführbareFunktionen. Zwischen zwei Zuständen kann es beliebig viele Aktionen geben. Dergesamte Weg von einem Zustand zum Folgezustand wird als Dialogschritt bezeichnet.

In der Grafik wird beispielhaft ein trivialer Kundenanzeigedialog spezifiziert.Initialzustand des Dialoges ist die Kundensuche. Mit dem Benutzerereignis (virtuelleTaste) suche wird die Aktion suche Kunden ausgelöst. Abhängig von der AnzahlTreffer die zur Suchanfrage gefunden werden, verzweigt der Dialog zurück zurKundensuche (0 Treffer), zur Aktion lese Kunden (1 Treffer) oder zum ZustandKundenliste (1 Treffer). Im Zustand Kundenliste sind zwei Benutzerereignisse möglich:neue Suche oder auswählen eines Kunden. Der Zustand Kundendetails erlaubt ledig-lich eine neue Suche.

Kasten 2: Interaktionsdiagramme

Benutzungsschnittstellen drei Aufgaben:� Modelltransformation zwischen

Dialog-Modell (Dialogdaten) undView-Modell (Präsentationsdaten)

� Abbildung von Präsentations- aufDialogereignis (Ereignisabstraktion)

� Abbildung von Dialogzustand aufPräsentationssicht (View)

Diese Aufgaben werden in der Struts-Architektur nicht explizit abgebildet.Stattdessen muss sich jede Anwendungimplizit selbst um diese Aspekte bemühen,was häufig in einer Vermischung vonAufgaben resultiert und versteckteKomplexität produziert.

Unterstützung für Multi-ChannelingImmer häufiger sollen Anwendungen ver-schiedene Präsentationskanäle unterstüt-zen (z. B. Web-Oberfläche und nativeOberfläche). Um Multi-Channeling in derArchitektur zu unterstützen, sollte man dieEssenz der Benutzerinteraktionen abstraktmodellieren, ohne sich dabei auf diekonkrete UI-API (z.B. Servlet/JSP, Swing)einzulassen. Dafür bieten sich z. B. Inter-aktionsdiagramme (IADs) bzw. UML-Zustandsdiagramme an (siehe Kasten 2).

Im Design wird diese abstrakte Beschrei-bung der Benutzerinteraktionen durch einetechnikneutrale Dialogschicht abgebildet.Anwendungen, die naiv mit Struts gebautwerden, sind nicht multi-channel-fähig.

ZustandsbehafteteDialoge mit StrutsBisher wurden sowohl die Stärken alsauch die Schwächen von Struts aufgezeigt.Im Folgenden stellen wir mit QUI-Web(Quasar User Interface für Web-Anwen-dungen) eine Erweiterung von Struts vor,welche die Konstruktion zustandsbehafte-ter Dialoge mit Struts ermöglicht, ohnedabei das Geheimnisprinzip durch sit-zungsglobale Variablen zu verletzen.

QUI-Web ist Teil der sd&m-Standard-architektur QUASAR, vgl. [Sie00].

Was bietet QUI-Web?QUI-Web ist ein Toolkit für Web-Anwen-dungen, die auf JSP/Servlet-Technik basieren.Die Implementierung von QUI-Web verwen-det Struts. Bei der Entwicklung wurde großerWert darauf gelegt, ein schlankes und leichtwartbares Toolkit zu erstellen: Insgesamtbesteht QUI-Web aus circa 40 Klassen undInterfaces, die von Java-Entwicklern in zweiTagen leicht verstanden werden können. Alswesentlichen Mehrwert gegenüber Struts eta-bliert QUI-Web eine technikneutraleDialogschicht, die von der JSP/Servlet-APIund von Struts unabhängig ist.

Die Dialogschicht ermöglicht es,zustandsabhängig auf eintreffende Benut-zerereignisse (Dialogereignisse) zu reagie-ren. Im Dialog werden die Interaktionendes Benutzers mit der Anwendung abstraktmodelliert, ohne dabei auf die Spezifika derUI-API einzugehen. Als Modellvorstellungdafür dient das von Denert in [Den91] ein-geführte Interaktionsdiagramm, eineVariante eines endlichen Zustandsauto-maten (siehe Kasten 2).

Ein Dialog besteht dabei imWesentlichen aus Dialog-Aktionen undZuständen. Die Kernidee ist, dass Dialog-zustände von der Präsentationsschichtinterpretiert und visualisiert werden.

Diese Visualisierung ist channel-spezi-fisch. Hierfür bietet bietet QUI-WebSchnittstellen an. Die web-spezifischenImplementierungen dieser Schnittstellenbereiten die Präsentationsdaten in Form vonJavaBeans auf und legen sie als Attribute derAnfrage ab. Die JSPs greifen beim Erzeugender Ausgabe auf die Anfragen-Attribute zuund erhalten damit sowohl die benötigtenNutzdaten (z.B. für das Befüllen vonTabellen), als auch optional benötigteMetainformationen (z.B. Regeln für dieclientseitige Validierung mit JavaScript).

Aufwand und NutzenQUI-Web erwartet vom Nutzer zusätzlichzur Struts-Konfiguration, dass er die an-

wird der ViewManager damit beauf-tragt, die Präsentationsdaten(ViewModels) zu ermitteln. Dazu ist fürden sichtbaren Dialog einModelltransformator (DialogToView)registriert, den der ViewManagerbenutzt. DialogToView interpretiert denZustand des Dialogs, transformiertdas Dialog-Modell in die aktuell fürdie Präsentation benötigten View-Modelle (JavaBeans) und fügt dieseder HTTP-Anfrage hinzu.

5. Der RequestListener leitet die Anfrage aneine in der Konfiguration festgelegteLayout-JSP weiter: Diese stellt die Rah-menseite der Ausgabe dar; sie definiertdas Layout und inkludiert die geradebenötigten Views. Die konkret zu inklu-dierenden JSPs sind ebenfalls in einemView-Modell hinterlegt (vgl. [Gea00]).

Die Schnittstellen der wichtigsten Kompo-nenten sind in Listing 1 dargestellt.Mehrwert für den NutzerGezähmtes StrutsEin Mehrwert von QUI-Web liegt imNutzungskonzept der Struts-Aktionen.Statt die Dialoglogik und die An-wendungsfallaufrufe in den Struts-Aktionen zu implementieren (AT-Soft-ware), verwendet QUI-Web genau eineStruts-Aktion als serverseitigenRequestListener, einer zustandslosen tech-nischen Klasse (T-Software). Hier erfolgendie Loslösung von Struts und der Eintrittin die zustandsbehaftete, technikneutraleDialogschicht.

In der Methode perform desRequestListener erfolgt:

� die Loslösung von der Servlet-API,� das Restaurieren und Suspendieren des

Sitzungsgedächtnisses,� die Synchronisation paralleler Anfra-

gen eines Benutzers,� die Abstraktion vom Präsentations-

ereignis zum Dialogereignis,� der Eintritt in die technikneutrale

Dialogschicht,� das Erstellen der View-Modelle aus

den Dialog-Modellen und� das Erzeugen der Ausgabeseite durch

eine ActionForward.

Abschirmung vor der UI-APIDie Servlet/JSP-API ist die technische UI-API der serverseitigen Präsentations-schicht. Sie wird in bestimmten Teilen derPräsentationsschicht verwendet: die JSPsund alle struts-behafteten Teile in derArchitektur verwenden sie.

w w w. s i g s - d a t a c o m . d e3 / 2 0 0 2

s c h we r p u n k tk o m p l e x e w e b - a n w e n d u n g e n m i t „ s t r u t s ”

wendungsspezifischen Dialoge implemen-tiert bzw. über IADs deklariert. Dialogewerden in der Initialisierungsphase derAnwendung beim Toolkit registriert.Außerdem implementiert der Nutzer dieanwendungsspezifischen Modelltransfor-matoren (IDialogToView) und registriert siebeim Toolkit.

Zusammenfassend stellt der Nutzer proAnwendung die Klassen außerhalb der grauhinterlegten Komponenten in Abbildung 2zur Verfügung. Die Komponenten selbst(QPresentation, QDialog) bekommt er zurVerfügung gestellt. Diese enthalten vorge-dachte Interfaces und Implementierungen (0-und T-Code), die in jeder Web-Anwendungwiederverwendet werden können.

Komponenten von QUI-WebQUI-Web besteht aus den beidenKomponenten QPresentation und QDialog.QPresentation nutzt QDialog ausschließlichüber die Schnittstellen IDialogManager undIDialogRead. QDialog macht keineAnnahmen über QPresentation. Die Imple-mentierung von QPresentation verwendetStruts. Genau genommen verwenden aus-schließlich die Klassen QuiServlet,RequestListener und QuiForm Struts.

Die Kernidee der Struts-Nutzung spie-gelt sich in der Klasse RequestListenerwider: der RequestListener ist eine Struts-Aktion – die einzige Struts-Aktion, die inder Präsentation benötigt wird. Alle einge-henden HTTP-Anfragen werden vom zen-tralen QuiServlet (Subklasse vonActionServlet) entgegengenommen und andie Struts-Aktion RequestListener weiterge-leitet. Dieser benutzt ein von der URIabhängiges, anwendungsspezifisches, ser-verseitiges Formular für die Verarbeitungder Eingabedaten.

Die serverseitigen Formulare (QuiFormund anwendungsspezifische Subklassendavon) enthalten die Benutzereingabeneiner Anfrage. Da die Abstraktion vonPräsentationsereignis auf Dialogereignis imAllgemeinen datenabhängig ist, führen dieFormulare diese durch. Die Methode zurEreignisabstraktion ist genau der Mehrwertder QuiForm gegenüber der ActionForm.

Der RequestListener verarbeitet eineAnfrage in folgenden Schritten:1. Zunächst erfolgt die Synchronisation

auf die HttpSession; damit werden kon-kurrierende Anfragen eines Benutzerssequenzialisiert. Anfragen unterschied-licher Benutzer sind strukturell überdie verschiedenen Instanzen vonHttpSession entkoppelt und beeinflus-sen sich gegenseitig nicht.

2. Aus dem eingehenden Präsentations-ereignis (HTTP-Request) wird das zuge-hörige Dialogereignis ermittelt; dazuwird das in der Konfiguration deklarier-te, spezifisch fachliche Formular benutzt.

3. Das Dialogereignis wird dem Dialog-Manager (DialogManager) zurVerarbeitung übergeben; hier erfolgtdie Loslösung von der Technik und derEintritt in die technikneutrale Dialog-schicht. Der Dialog-Manager leitet dasDialogereignis an den dafür zuständi-gen Dialog weiter. Ein Dialog besitztjeweils eine eigene Datenhaltung(DialogModel) und reagiert imAllgemeinen zustandsabhängig auf daseintreffende Dialogereignis mit derAusführung einer Dialog-Aktion(DialogAction), in welcher der Aufrufder Anwendungsfälle des Anwen-dungskerns erfolgt.

4. Ist die Dialogschicht fertig mit derVerarbeitung des Dialogereignisses,

Abb. 2: Komponenten von QUI-Web und Blutgruppen.

s c h we r p u n k tk o m p l e x e w e b - a n w e n d u n g e n m i t „ s t r u t s ”

30 31 w w w. o b j e k t s p e k t r u m . d e

Alle übrigen Komponenten werden vonder UI-API nicht infiziert. Vorraussetzungdafür ist die Abstraktion von derHttpSession und dem HttpServletRequest,die wir durch die beiden InterfacesISessionMemory und IRequest erreichen.Beide Interfaces sind mit Implemen-tierungen hinterlegt (T-Software).

Technikneutrale DialogschichtQPresentation nutzt QDialog über die beidenschmal gehaltenen SchnittstellenIDialogRead und IDialogManager. DieKopplung zwischen Präsentation und

Dialog ist damit minimiert. Die An-wendung ist von der UI-API abgeschirmt.

Da die gesamte Dialogschicht technik-neutral ist, kann sie für verschiedene GUI-Channels verwendet werden (Multi-Channeling). Über diese Schicht könnensowohl zustandslose als auch zustandsbe-haftete Dialoge realisiert werden. Fürzustandsbehaftete Dialoge bietet QUI-Web verschiedene Mechanismen zumtransparenten Management von Sitzungs-daten, die weiter unten beschrieben wer-den.

Dialog und IAD-InterpreterFür die Implementierung eines Dialogs ste-hen dem Nutzer von QUI-Web verschiede-ne Wege offen: Entweder implementiert erdie Dialogschnittstellen (IDialog,IDialogRead) eigenständig oder er verwen-det eine vorgefertigte IAD-Dialogimple-mentierung (0-Software). Im letzteren Fallwird der Dialogablauf über eine IAD-Beschreibung in XML deklariert und übereinen IAD-Interpreter zur Laufzeit ausge-führt.

Die Nutzung der IAD-Dialogimple-mentierung erfordert keine Implementie-rungsvererbung. QUI-Web verfolgt stringentden Toolkit-Ansatz und benutzt keineVererbungsbeziehungen zwischen Toolkitund Toolkit-Nutzer (vgl. [Broy02]).

Der Mehrwert des IAD-Verfahrensbesteht darin, für jeden Dialog einegeschlossene Darstellung des Dialogab-laufs zu besitzen. Dies erleichtert dasVerständnis und die Wartbarkeit derAnwendung wesentlich. Zusammen mitder Beschreibung der Struts-Aktions-steuerung hat man damit die gesamteDialogdynamik deklarativ beschrieben. DasIAD-Verfahren eignet sich für 80% derDialoge. Für Sonderfälle bleibt dem Benutzerüber die manuelle Dialogimplementierungder User-Exit erhalten. Die Koordination derverschiedenen Dialoge der Anwendungübernimmt der DialogManager. Diese 0-Komponente koordiniert Dialogwechsel undführt Buch über den sichtbaren Dialog imKontext einer Anfrage.

Modelltransformation undEreignisabstraktionTechnische Präsentationsereignisse(HttpServletRequests) werden in derQuiForm auf technikneutrale Dialogereig-nisse abgebildet (Ereignisabstraktion). DieRegeln dazu werden von der Anwendungdefiniert und beim Toolkit registriert. DieDialogschicht verarbeitet ausschließlichDialogereignisse; damit bleibt sie technik-neutral.

In der QuiForm findet die Modelltrans-formation für die Dateneingabe statt:Präsentationsdaten werden auf Dialogdatenabgebildet. Die Modelltransformation fürdie Datenausgabe geschieht in den anwen-dungsspezifischen Implementierungen vonIDialogToView. Hier werden abhängig vomaktuellen Dialogzustand die Daten desDialogmodells extrahiert und inPräsentationsdaten konvertiert (JavaBeans).Zusätzlich zu den Nutzdaten wird imPräsentationsmodell auch Metainformationfür den Aufbau der View-Hierarchie (vgl.

Interfaces für die Dialogschicht

public interface IDialogEvent {public Symbol getEventId();public Map getEventParams();public Symbol getSourceDialogId();public Symbol getTargetDialogId();public int getDialogVersion();

}public interface IDialogManager {

public void processDialogEvent(IDialogEvent event);public Symbol getVisibleDialog();public IDialogRead getDialogRead(Symbol id);public void releaseDialogData();

}public interface IDialogManagerIntern {

public void doDialogSwitch(Symbol sourceDialogId,Symbol targetDialogId, Map params);

}public interface IDialog {

public void processDialogEvent(IDialogEvent event);public RC leave(Map params);public void enter(Map params);public void releaseDialogData();public IDialogRead getDialogRead();

}public interface IDialogAction {

public Symbol execute(IDialog dialog, IDialogData data, Map params);}

Interfaces für die Präsentationsschicht

public interface IQuiForm {public IDialogEvent getDialogEvent();

}public interface IViewManager {

public void putViewModels(IDialogManager dialogMgr, IRequest request);}public interface IDialogToView {

public void putViewModels(IDialogManager dialogMgr, IRequest request);}

Interfaces für das Sitzungsmanagement

public interface IRequest {public ISessionMemory getSessionMemory();public Object getViewModel(Symbol key);public void setViewModel(Symbol key, Object view);

}public interface ISessionMemoryManager {

public void initSessionMemoryManager(IQuiFactory quiFactory, Map params);

public ISessionMemory getSessionMemory(Object session);public void suspendSessionMemory(Object session);

}public interface ISessionMemory {

public IDialogManager getDialogManager();}

Listing 1: Interfaces von QUI-Web

w w w. s i g s - d a t a c o m . d e3 / 2 0 0 2

s c h we r p u n k tk o m p l e x e w e b - a n w e n d u n g e n m i t „ s t r u t s ”

[Gea00]) und für clientseitige Validierungabgelegt.

Sitzungsmanagement und -gedächtnisZwei zentrale Aspekte des Sitzungsmana-gements sind:

� das Aufrechterhalten der logischenVerbindung über mehrere C/S-Inter-aktionen hinweg und

� das Verwalten von sitzungsbezogenenAnwendungsdaten.

Der erste Punkt wird vom Servlet-Container auf Basis von Cookies/URL-Rewriting geleistet (vgl. [Dav99]).

Über das Interface HttpSession bietet dieServlet-API auch die Möglichkeit zurAblage von Sitzungsdaten. Nutzt man die-sen Mechanismus naiv, so werden dieSitzungsdaten für die gesamte Sitzungs-dauer im Hauptspeicher des Servlet-Containers gehalten.

Serverlast und die Menge der anfallen-den Sitzungsdaten in der Anwendung for-dern hier einen Designabwägung zwischenRessourcenverbrauch (Hauptspeicher)und Performanz (Zugriffszeit). Um zu ver-hindern, dass diese Designabwägung dieArchitektur dominiert, versteckt man dieEntscheidung hinter einem geeignetenInterface und entscheidet an zentralerStelle über die Implementierungsvariante.Die Idee ist einfach: Jeder HttpSession wirdein Sitzungsgedächtnis (ISessionMemory)zugeordnet. Diese Zuordnung wird vomSessionMemoryManager hergestellt und ver-waltet.

Die Methode suspendSessionMemoryerlaubt unter anderem folgende Imple-mentierungsvarianten:� Die Methode besitzt einen leeren

Rumpf, d. h. das Sitzungsgedächtnisbleibt die gesamte Sitzungsdauer überim Hauptspeicher.

� Das Sitzungsgedächtnis wird in eineDatei serialisiert oder in die Daten-bank geschrieben.

� Das Sitzungsgedächtnis wird in einenString serialisiert und als verstecktesFormularfeld zum Client ausgelagert.

Der Aufruf von suspendMemory fügt sichan zentraler Stelle in die QUI-Architekturein. Die Anwendung muss sich um diesen

technischen Aspekt nicht kümmern, dennsie bekommt davon nichts mit.

Erkennen technischer NavigationJede zustandsbehaftete Web-Anwendungmuss auf technische Browser-Navigation(Back-Button, History Bookmarks, paral-lel geöffnete Browser-Fenster) semantischkorrekt reagieren. QUI-Web stellt alsBasisfunktionalität einen einfachenMechanismus zum Erkennen technischerNavigation auf Dialogebene bereit. DieAnwendung entscheidet, wie fachlich kor-rekt darauf zu reagieren ist.

Dazu wird das Dialog-Modell einesDialoges versioniert. Bei jedem Schreib-zugriff wird die Versionsnummer erhöht.Die Dialogversion wird als verstecktesFeld in die JSP eingebaut und zum Clientgeschickt. Über diesen Versionszählerkönnen Konflikte erkannt werden.

Die Versionierung pro Dialog erlaubt esdem Benutzer, mehrere Dialoge parallel zubearbeiten – in jeweils eigenen Browser-Fenstern.

ZusammenfassungQUI-Web ist eine Erweiterung des Struts-Frameworks für komplexe Web-Anwendungen. Bestehender Struts-Codewird dabei nicht verändert. QUI-Web bie-tet gegenüber Struts als Mehrwert:

� ein Dialogkonzept, das auch zustands-behaftete Dialoge ohne die Verletzungdes Geheimnisprinzips ermöglicht,

� die Trennung zwischen Technik(JSP/Servlet) und Anwendungslogik(Dialog) sowie

� ein transparentes Sitzungsmanagementmit flexiblen Implementierungs-varianten.

Neben den bereits vorgestellten Features –wie dem Erkennen von technischerNavigation und der effizienten Dialogge-staltung mit Hilfe von Interaktions-diagrammen – bietet QUI-Web nochzusätzlich eine eigene Validierungskompo-nente für die Prüfung von Benutzerein-gaben und ein durchgängiges Konzept zurFehlerbehandlung.

Bei einer großen Anzahl von Dialogen(mehr als 40) bietet sich ein Generator-ansatz an, um die notwendige Produkti-

vität im Entwicklungsprozess zu erzielen.View, View-Modell und Modelltrans-formation lassen sich deklarativ beschrei-ben. Aus dieser Beschreibung werden dieJSPs und Java-Klassen generiert.

Dieser Generatoransatz hat sich inProjekten bei der Firma sd&m bewährt.Für QUI-Web existiert derzeit keinGenerator. Dies stellt den nächsten Schrittin der Weiterentwicklung des Toolkits dar.

�

Literatur & Links[Bar02] Baracuda – Surveying theLandscape (siehe http://barracuda.enhydra.org/cvs_source/Barracuda/docs/landscape.html)[Brö99] P. Brössler, J. Siedersleben,Software Technik, Hanser, 1999[Brow01] S. Brown, R. Burdick, Profes-sional JSP, 2nd Ed., Wrox Press, 2001[Broy02] M. Broy, J. Siedersleben, Objekt-orientierte Programmierung und Software-entwicklung: Eine kritische Einschätzung,in: Informatik Spektrum, 25, S. 3-11, 2002[Dav99] J. Davidson, D. Coward, JavaServlet Specification, v2.2, Sun Micro-systems Press, 1999[Den91] E. Denert, J. Siedersleben, Soft-ware Engineering, Springer, 1991[Gea00] D. Geary, JSP Templates (siehehttp://www.javaworld.com/javaworld/jw-09-2000/jw-0915-jspweb_p.html)[Kam01] C. Kamm, F. Reine, H. Wörde-hoff, Basisarchitektur E-Business, in: Ta-gungsband GI/OCG Jahrestagung 2001 (2),S. 683-690[Kas00] N. Kassem et al, Designing Enter-prise Applications with the Java 2 Platform,Enterprise Edition, Addison-Wesley, 2000[Par72] D. Parnas, On the Criteria to beUsed in Decomposing Systems into Modu-les, in: Com. of the ACM, 15(12), S. 1053-1058, 1972[Pel99] E. Pelegri-Llopart, L. Cable, JavaServer Pages Specification, Version 1.1, SunMicrosystems Press, 1999[Sad00] C. Sadtler, F. Hilgenberg et al,Patterns for e-business: User-to-BusinessPatterns for Topology 1 and 2 usingWebSphere Advanced Edition, IBM, 2000[Sie00] J. Siedersleben, E. Denert, Wie bautman Informationssysteme. Überlegungenzur Standardarchitektur, in: InformatikSpektrum 23(4), S. 247-257 (2000)[Str02] Struts Online Manual (siehehttp:// jakarta.apache.org/struts/)[Wul73] W. Wulf, M. Shaw, GlobalVariables Considered Harmful, in: SIG-PLAN Notices, 8(2), S. 28-34, 1973