XSLT und EJB

(Auszug aus "Java und XSLT" von Eric M. Burke)

Nun, da die Optionen für die Entwicklung der Webschicht besprochen wurden, lassen Sie uns einen Blick darauf werfen, wie die Webschicht mit anderen Schichten in großen unternehmensweiten Systemen interagiert. Eine typische EJB (Enterprise JavaBeams)-Architektur schließt einen Thin-Browser-Client, eine Servlet-getriebene Webschicht und EJB in der Anwendungsserverschicht ein. Die folgende Abbildung erweitert das bereits gezeigte konzeptionelle XSLT-Model.

Abbildung: XSLT und EJB-Architektur

Abbildung: XSLT und EJB-Architektur

Dieses Diagramm ist wesentlich näher am echten physikalischen Modell einer mehrschichtigen Webanwendung, die XSLT einsetzt. Die Pfeile geben den allgemeinen Fluß einer einzelnen Anfrage an, angefangen beim Client. Dieser Client ist typischerweise ein Webbrowser, es könnte aber genauso gut ein Handy oder ein anderes Gerät sein. Die Client-Anfrage geht an ein einzelnes Servlet und wird weitergereicht an einen sogenannten RequestHandler. Im hier skizzierten Muster erzeugen Sie zahlreiche Unterklassen von RequestHandler. Jede Unterklasse ist verantwortlich für Validierung und Darstellungslogik für einen kleinen Satz von verwandten Funktionen. Eine überschaubare Strategie besteht darin, eine Unterklasse von RequestHandler für jede Webseite der Anwendung zu entwickeln. Ein anderer Ansatz besteht darin, feinstrukturierte Request-Handler zu erzeugen, die eine spezielle Aufgabe bearbeiten, was von Vorteil sein kann, wenn dieselbe Funktionalität von vielen verschiedenen Masken in der Anwendung aufgerufen wird.

Der Request-Handler arbeitet mit dem Anwendungsserver über EJB-Komponenten zusammen. Die gebräuchliche Vorgehensweise ist die Ausführung von Kommandos auf Session-Beans, die wiederum ihre Daten von Entity-Beans bekommen. Das interne Verhalten der EJB-Schicht ist für die Webschicht irrelevant. Ist der EJB-Methodenaufruf beendet, werden an die Webschicht ein oder mehrere »Datenobjekte« zurückgeliefert. Von dort aus muß das Datenobjekt in XML konvertiert werden.

Die Umwandlung in XML kann auf verschiedene Arten gehandhabt werden. Eine gebräuchliche Vorgehensweise ist, Methoden, die wissen, wie man ein XML-Fragment oder gar das ganze Dokument erzeugt, in die Datenobjekte selbst zu schreiben. Eine andere Möglichkeit besteht darin, für jedes Datenobjekt eine XML-Adapterklasse zu schreiben. Anstatt den Code zur XML-Generierung in das Datenobjekt einzubetten, generiert die Adapterklasse das XML. Diese Methode hat den Vorteil, daß Datenobjekte leicht und sauber gehalten werden können, dafür müssen aber zusätzliche Klassen geschrieben werden. Bei jeder Möglichkeit ist es sinnvoll, XML als DOM oder JDOM-Baum zurückzuliefern und nicht als rohen XML-Text. Wenn das XML als Rohtext zurückgeliefert wird, muß es vom XSLT-Prozessor nochmal in den Speicher zurückgeparst werden. Werden die XML-Daten als Datenstruktur zurückgeliefert, kann der Baum direkt an den XSLT-Prozessor übergeben werden, ohne den zusätzlichen Parsing-Schritt.

Als eine weitere Methode kann XML auch direkt von den EJB-Komponenten zurückgeliefert werden, was die dazwischenstehenden Datenobjekte überflüssig macht. Entwicklungsumgebungen, Testen und Performance wird darauf detailliert eingehen, primär aus Performance-Gesichtspunkten. Der Hauptnachteil, den es zu berücksichtigen gilt, ist die Tendenz von XML, sehr umfangreich zu sein. Es ist weniger effizient, große XML-Textdateien vom Anwendungsserver zum Webserver zu senden, als serialisierte Java-Objekte. Sie könnten die Daten zwar komprimieren, aber das würde nur zusätzlichen Verarbeitungsaufwand durch Komprimierung und Dekomprimierung bedeuten.

Egal wie das XML erzeugt wird, der letzte Schritt, zu sehen in der Abbildung XSLT und EJB-Architektur, ist die Weitergabe der XML-Daten und des Stylesheets an den XSLT-Prozessor zwecks Transformation. Der Ergebnisbaum wird unmittelbar an den Client übertragen, und die Anfrage ist vollständig abgearbeitet. Wenn der Client ein Browser ist, wird das XSLT-Stylesheet das XML vermutlich in HTML oder XHTML umwandeln. Für einen Nicht-Browserclient ist es vorstellbar, die Daten unmittelbar, also ohne XSLT-Transformation, auszuliefern.

Kompromisse

Die Skalierbarkeit ist eine wichtige Motivation für eine mehrschichtige EJB-Architektur. In einer solchen Architektur kann jede Schicht auf einer anderen Maschine laufen. Zusätzliche Performance-Steigerungen sind möglich, wenn mehrere Server für eine Schicht zusammengefaßt werden. Ein anderer Motivationsfaktor ist die Zuverlässigkeit. Fällt eine Maschine aus, kann eine redundante Maschine die Verarbeitung fortsetzen. Werden Updates durchgeführt, können neue Software-Versionen, um längere Ausfälle zu vermeiden, nacheinander auf den einzelnen Maschinen eingespielt werden. Durch strikte Regulierung des Zugriffs auf die Datenschicht über EJB wird die Sicherheit verbessert.

Noch eine Motivation für ein verteiltes System ist die Einfachheit, obwohl eine einfache EJB-Anwendung wesentlich komplexer ist als eine einfache Zweischicht-Anwendung. Ja, verteilte Systeme sind komplex, aber in komplexen Anwendungen vereinfacht diese Methode Ihre Arbeit, indem unabhängige Aufgaben zwischen den Schichten aufgeteilt werden. So kann eine Gruppe von Programmierern an den EJB-Komponenten arbeiten, während eine andere an den Request-Handler-Klassen der Webschicht arbeitet. Eine Gruppe von Designern kann an XML und XSLT arbeiten, während die Datenbankexperten sich auch nur auf die Datenbank konzentrieren.

Für simple Anwendungen ist ein EJB-Ansatz utopisch und wird wahrscheinlich die Performance beeinträchtigen. Wenn Ihre Website also nur ein paar hundert Besucher pro Tag bedient, führt die Eliminierung von EJB zu Geschwindigkeitssteigerungen, denn es gibt keine zusätzliche Anwendungsschicht, die durchquert werden muß. (Bedenken Sie, daß die anderen Vorteile von EJB, wie Sicherheit, dann auch wegfallen.)

   

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema Java & XSLT bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

Copyright © 2002 O'Reilly Verlag GmbH & Co. KG
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "Java und XSLT" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

O’Reilly Verlag GmbH & Co. KG, Balthasarstraße 81, 50670 Köln, kommentar(at)oreilly.de