|
|
URL dieses Artikels:
zu Ausgabe:
03.2002
Die Verpuppung
XML-Anwendungen erstellen mit dem Cocoon 2, Teil 1
Von Matthew Langham und Carsten Ziegeler
Bereits bei der Vorstellung von Cocoon 1.8 Java Magazin war ein zweiter Entwicklungszweig innerhalb des Apache Open Source-Projekts Cocoon vorhanden. Der geistige Vater von Cocoon, Stefano Mazzocchi, begann die Version 2.0 von Cocoon im November 1999. Mit der Freigabe der Version 2.0 Ende letzten Jahres liegt nun eine stabile und leistungsfähige XML-Lösungsplattform vor. Das Cocoon-Projekt hat beschlossen nur noch diesen neuen Entwicklungszweig weiterzuführen, daher wird keine Versionsnummer im Namen geführt. Dieser 2-teilige Artikel stellt die neue Version von Cocoon vor und demonstriert anhand von einigen Beispielen die Einsatzmöglichkeiten. Der erste Teil stellt eine einführende Übersicht dar, der zweite wird sich tiefer mit den zugrundeliegenden Technologien beschäftigen.
Die grundlegenden Ziele und Prinzipien von Cocoon 1.x haben selbstverständlich auch in der neuesten Version Bestand. Die Hauptaufgabe von Cocoon besteht in der einfachen Entwicklung von Web-Anwendungen. Nach wie vor steht die Trennung der Zuständigkeiten bei der Entwicklung von Internet-Anwendungen im Vordergrund: die strikte Trennung von Daten, Logik und Layout. Ein Layouter soll sich nicht mit Datenakquisition beschäftigen müssen und ein Anwendungsprogrammierer nicht mit dem Layout. Gerade diese Trennung unterscheidet Cocoon von anderen Technologien wie beispielsweise ASP oder JSP. Gemein ist allen Ansätzen, dass die angefragten Dokumente - meist HTML-Seiten - dynamisch zur Laufzeit generiert werden. Die Notwendigkeit einer XML/XSL-basierten Plattform um flexible Middleware-Lösungen zu erstellen, lässt sich auf Grund der gewachsenen Anforderungen an Internet-Anwendungen begründen. So gibt es heute eine Vielzahl von internetfähigen Endgeräten. Da diese Geräte und auch die Anwendungen aber unterschiedliche Darstellungsformate erwarten, muss eine flexible Technologie wie XSL eingesetzt werden, um diese Formate dynamisch aus den gleichen Daten zu erzeugen. Es reicht nicht mehr aus, den Inhalt lediglich in HTML darzustellen, sondern es sind vielmehr weitere Formate wie PDF zum Drucken oder WML für mobile Geräte gefragt. Ferner müssen solche Lösungen in der Lage sein, die unterschiedlichsten Datenquellen wie Datenbanken und auch andere Systeme einzubinden. Hier hilft es, dass viele Systeme bereits XML-Schnittstellen und Formate anbieten. Nimmt man zusätzlich Anforderungen wie Personalisierung, Plattformunabhängigkeit und Flexibilität hinzu, kommt man schnell zu einer Lösung, die auf Basis vorhandener Java-Komponenten gebaut werden könnte. Insbesondere die Komponenten der Apache-Projekte, wie der XML-Parser Xerces und XSLT-Processor Xalan bieten bereits die Grundlage einer solchen Anwendung. Genau hier setzt Cocoon an, indem vorhandene Komponenten mittels einer durchdachten und leistungsfähigen Architektur zu einem leistungsfähigen XML Publishing Framework zusammengesetzt werden. Viele Anwendungsszenarien lassen sich durch Cocoon und ohne eine Zeile Java-Programmierung abdecken. Unsere Cocoon-Vorstellung beginnt mit einem Überblick über die Architektur. Architekturübersicht Cocoon ist ein Framework mit einer offenen, komponentenbasierten Architektur. Diese Architektur erlaubt die Verwendung von anderen Projekten als austauschbare Komponenten. Hierfür bedient sich Cocoon aus dem großen Fundus anderer Apache Projekte. Zum Beispiel wird Apache Xerces [5] als XML -Parser, Apache Xalan [4] als XSLT-Processor und Apache FOP zur PDF-Generierung eingesetzt; genauso könnten aber auch andere XML-Parser oder XSLT-Processoren verwendet werden. Grundlage für die objektorientierte Architektur ist das Apache-Projekt Avalon [3], ein Java-Ansatz zur komponentenorientierten Softwareentwicklung. Die Arbeitsweise von Cocoon basiert auf dem von Web Servern oder Servlet-Engines bekannten Request-Response-Zyklus. Wenn ein Request vom Client an Cocoon geschickt wird, wird dieser auf dem Server verarbeitet. Cocoon generiert ein Antwort-Dokument und schickt dieses zurück an den Client. Cocoon verwendet für die Beschreibung dieses Zyklus eine Abstraktion, die auf dem Servlet-API basiert. Durch diese Abstraktion ist es möglich, Cocoon in verschiedenen Umgebungen zu verwenden. Die häufigste Verwendungsform ist sicherlich als Servlet. Mittels einer vorhandenen Implementierung kann Cocoon damit in Servlet-Engines oder Application Server eingebunden werden. Allerdings bietet Cocoon auch ein Command-Line-Interface und erlaubt somit z.B. die Ansteuerung aus einem Skript. Abb. 1: Die Architektur von Cocoon 2 Für die Betrachtung der Funktionsweise von Cocoon ist es unerheblich, in welcher Umgebung Cocoon verwendet wird. Im Folgenden betrachten wir daher die häufigste Form: Cocoon als Servlet. Wir gehen im Weiteren davon aus, dass Cocoon in einer Servlet-Engine läuft und unter http://localhost:8080/cocoon/ der Servlet-Context von Cocoon erreichbar ist. Entsprechende Installationsanweisungen für die gängigen Servlet-Engines, insbesondere für Jakarta Tomcat [6] finden sich in der Distribution [2]. Jede Anfrage an Cocoon liefert eine Antwort bzw. ein Dokument. Ein Dokument erhält immer einen eindeutigen Namen, den man in seinem Browser als URI angeben kann. Alle Informationen in der URI, die cocoon/ folgen, bezeichnen das Dokument. Beispielsweise erreicht man über http://localhost:8080/cocoon/helloworld ein Dokument namens helloworld. Das zentrale Bindeglied zwischen Dokumentnamen und generierter Antwort ist die Sitemap. Sitemap und Pipelines Die Sitemap ist ein XML-Dokument, in dem festgelegt wird, welche Arbeitsschritte für eine URI ausgeführt werden. Um ein Dokument zu erzeugen, wird eine sogenannte XML-Pipeline aufgebaut. Eine XML-Pipeline ist eine funktionale Einheit, die aus einer Kombination von verschiedenen Komponenten zusammengesetzt wird. Jede Pipeline beginnt mit genau einem Generator. Ein Generator liefert einen XML-Datenstrom, der von anderen Komponenten in der Pipeline verarbeitet wird. Cocoon enthält beispielsweise Generatoren, um direkt XML- Dokumente von der Festplatte zu lesen oder über eine HTTP-Verbindung zu laden. Die Quelle für einen Generator muss aber nicht unbedingt direkt XML sein; ein Generator kann auch andere Formate nach XML umwandeln, beispielsweise ist ein Generator denkbar, der Daten aus einer relationalen Datenbank holt und diese in XML umwandelt. Nach einem Generator können in der Pipeline sogenannte Transformer folgen. Diese optionalen Komponenten erhalten den XML-Datenstrom aus der vorgelagerten Komponente. Ein Transformer kann den Datenstrom verändern. Es können somit neue XML-Elemente eingefügt, bestehende herausgenommen oder direkt verändert werden. Ein Beispiel hierfür ist ein Stylesheet-Transformer, der ein XSLT Stylesheet verwendet, um den Datenstrom entsprechend umzuformen. Die letzte Komponente in der Pipeline ist ein sogenannter Serializer. Diese erforderliche Komponente wandelt den XML-Datenstrom in das entsprechende Ausgabeformat, setzt den Mime-Type für den Client und erzeugt damit das eigentliche Dokument. Der HTML Serializer erzeugt beispielsweise einen HTML-Textstrom, ein PDF Serializer erzeugt einen PDF-Strom. Ein typisches mit Cocoon generiertes Dokument besteht aus der Aufbereitung von Daten, d.h. ein XML- Dokument mit den Daten wird mit Hilfe eines Stylesheets nach HTML transformiert. Genau das werden wir einmal anhand des obligatorischen HelloWorld-Beispiels durchführen. Hello World Das Hello World-Beispiel soll ein XML-Dokument mit dem entsprechenden Text lesen und per Stylesheet nach HTML transformieren. Für die XML-Pipeline benötigen wir also einen Generator, der ein XML-Dokument liest, einen Transformer, der ein Stylesheet auf das XML-Dokument anwendet und dieses nach XHTML konvertiert und einen Serializer, der aus XHTML, das für den Browser verständlichere HTML erstellt. Darüber hinaus muss noch die Verbindung zwischen dem Dokumentnamen und der Pipeline hergestellt werden. Dieses wird über eine weitere Komponente, einem Matcher erreicht. Für jeden Komponententyp bietet Cocoon eine Reihe an verschiedenen Komponenten für unterschiedliche Einsatzgebiete. Der wildcard Matcher vergleicht beispielsweise den vom Client geschickten Dokumentnamen mit einem vorgegebenen Muster. Ist der Vergleich erfolgreich, so werden alle Anweisungen ausgeführt, die in dem entsprechenden XML Element-eingeschachtelt sind. In unserem Beispiel wird auf helloworld als Dokumentname geprüft. Abb. 2: Cocoon XML Pipeline Als Generator können wir den file generator verwenden, der ein XML-Dokument von der Festplatte oder aber über HTTP lesen kann. Der xslt transformer liest ein Stylesheet und wendet dieses auf die Daten an. Schlusslicht ist der html serializer, der die Antwort mit dem entsprechenden Mime-Type versieht. <map:pipeline>Die Sitemap befindet sich direkt in dem Kontextverzeichnis von Cocoon und heißt sitemap.xmap. Suchen Sie innerhalb des Dokumentes das Element map:pipelines und fügen Sie das Listing für unser Beispiel direkt darunter ein. Kopieren Sie sowohl das XML als auch das XSLT-Dokument in das gleiche Verzeichnis wie die Sitemap. Nachdem Sie Cocoon gestartet haben, können Sie das Beispiel über http://localhost:8080/cocoon/helloworld aufrufen. Wie man hieraus bereits erkennen kann, hängt bei Cocoon das Format des Endergebnisses nicht vom Dokumentennamen ab. Anhand dieses kleinen Beispiels wird auch ein großer Unterschied zwischen Version 1.x von Cocoon und der jetzigen Version deutlich: In Version 1.x hatte man keine saubere Trennung zwischen Daten und Layout, da man schon in den XML Dokumenten - also den Daten - per Processing Instructions die Verarbeitung dieses Dokumentes angeben musste, also in der Regel das Stylesheet. Mit der neuesten Version von Cocoon entfällt dieses. Alles lässt sich unabhängig voneinander über die Sitemap definieren. Durch das Zusammensetzen der Pipelines ist eine flexiblere Wartung der Dokumentengenerierung möglich und es erfolgt eine wirklich saubere Trennung zwischen Daten und Layout. Diese Flexibilität wird deutlich, wenn man andere Formate als nur HTML generieren möchte. Beispielsweise soll das Hello World-Beispiel auch über ein mobiles Gerät erreichbar sein. Dafür benötigen wir ein Stylesheet, das aus den Daten WML erstellt. Somit können wir die XML-Pipeline entsprechend abändern: der Transformer liest dieses neue Stylesheet, das WML generiert und ein spezieller Serializer, der wap serializer, erzeugt dann das Antwortdokument. <map:pipeline>Fügen Sie den Ausschnitt aus der Sitemap direkt unter das erste Beispiel, kopieren Sie das neue Stylesheet in das Verzeichnis und starten Sie Cocoon neu. Danach können Sie das Beispiel über http://localhost:8080/cocoon/mobile_helloworld aufrufen. Wir haben nun zwei verschiedene Pipelines gebaut, die beide Male die gleichen Daten in unterschiedlichen Formaten dargestellt haben, d.h. die HTML-Version für normale Browser erreicht man unter helloworld und die WML-Version unter mobile_helloworld. Cocoon kann aber auch anhand des Requests erkennen, um welches Gerät es sich bei dem Client handelt, d.h. ob es ein Browser oder ein mobiles Gerät ist. Dadurch ist es möglich, dass man sowohl im Browser als auch auf dem Handy lediglich helloworld anfordert und Cocoon dann automatisch das richtige Format generiert. Möglich wird dieses durch einen weiteren Komponententyp, den man in der Sitemap nutzen kann: einem Selector. Ein Selector kann man mit einem if-elseif-else oder mit xsl:choose vergleichen. Er bietet die Möglichkeit einen Parameter auf verschiedene Werte zu testen. Cocoon beinhaltet unter anderem einen Selector, den browser selector, der testet, um welchen Client es sich handelt. Mit Hilfe des browser selectors können wir also aus unseren zwei Pipelines eine einzige machen, die je nach Client ein anderes Stylesheet bzw. Serializer verwendet. Das folgende Beispiel verwendet den browser selector und testet mit Hilfe der map:when -Anweisung, ob es sich um ein WAP-Gerät handelt. Wenn dieses der Fall ist, wird das entsprechende WML Stylesheet mit dem wap serializer verwendet. In allen anderen Fällen (map:otherwise) wird das HTML Stylesheet und der html serializer in die Pipeline mit aufgenommen. <map:pipeline>Entfernen Sie die beiden ersten Beispiele aus der Sitemap und fügen Sie an deren Stelle diesen neuen Ausschnitt ein. Starten Sie Cocoon neu und rufen Sie nun wahlweise das helloworld-Dokument von einem Browser bzw. von einem WML-Gerät auf. Anhand dieses Beispieles ist der Vorteil einer komponentenbasierten Lösung erkennbar. Das bedeutet, dass neue Funktionalität sehr leicht durch Ändern bzw. Hinzufügen einer neuen Komponente möglich ist. Sollen beispielsweise die Daten nicht mehr aus einer statischen Datei gelesen werden, sondern aus einer SQL- Datenbank geholt werden, so muss man lediglich den Generator austauschen. Möchte man ein anderes Layout, tauscht man den Transformer bzw. das Stylesheet aus. Möchte man personalisiertes Layout, so kann man entsprechende Selectoren verwenden, die den Inhalt abhängig von der Uhrzeit oder dem Alter des Benutzers aufbereiten. Für viele dieser Anwendungen bietet Cocoon schon entsprechende Komponenten. In der Tabelle sind ein paar der wichtigsten Komponenten aufgeführt. Benötigt man noch weitergehende Funktionalität, so kann man sehr leicht einen eigenen Generator, Transformer etc. implementieren und dem System hinzufügen. Spätestens hier fällt ein weiterer Unterschied zu Cocoon 1.x auf: die XML Pipelines verwenden das SAX-Modell zur Bearbeitung der XML-Daten. Somit fällt der Speicherbedarf einer Cocoon-Anwendung bedeutend geringer aus als bei der DOM-basierten 1.x Version. Darüber hinaus ist die Abarbeitungsgeschwindigkeit erhöht worden und Cocoon bietet einen intelligenten Caching-Algorithmus, der erneutes dynamisches Generieren von Dokumenten vermeidet. Sitemap-Flow Betrachten wir nun die Sitemap etwas genauer. Sie besteht aus mehreren Bereichen, von denen wir in diesem Teil des Artikels zwei genauer beleuchten möchten: die Komponenten und die Pipelines. Innerhalb der Sitemap wird der Namespace http://apache.org/cocoon/sitemap/1.0 mit dem Prefix map verwendet. Alle Elemente tragen diesen Namespace. Unterhalb des Elements map:components finden sich die verschiedenen Komponenttypen und Komponenten. Cocoon kennt die Typen: Generators, Transformers, Serializers, Selectors, Matchers, Readers und Actions. Für jeden einzelnen dieser Typen gibt es einen entsprechenden XML-Block, beispielsweise map:generators oder map:selectors. Innerhalb eines jeden Blocks werden die entsprechenden Komponenten deklariert und konfiguriert. Jede Komponente bekommt einen eindeutigen Namen über das Attribut name und eine zugehörige Java-Klasse über das Attribut src. Diese Klasse bezeichnet die Implementierung der Komponente und der Name dient als Referenz, die man in den XML Pipelines verwenden kann. Um in den Pipelines eine Komponente zu verwenden, benutzt man ein XML-Element, dessen Namen aus dem zum Komponententyp zugehörigem Verb geformt wird. Beispielsweise map:generate um einen Generator zu verwenden, map:select für einen Selector etc. Um zu definieren, welche Komponente man verwenden möchte, spezifiziert man über das Attribut type den eindeutigen Namen der Komponente. Beispielsweise Die bisher gezeigten Beispiele verwendeten alle die gleichen Komponenten: den file generator und den xslt transformer. Natürlich bietet Cocoon noch viel mehr Komponenten, die verwendet werden können. Beispielsweise den html generator. Dieser Generator kann eine HTML-Seite lesen und diese nach XHTML umwandeln. Dadurch ist es sehr leicht möglich, bestehende HTML-Auftritte in neue mit Cocoon erstellte Anwendungen zu integrieren. Durch die Bereitstellung der Daten als XML-Strom können beispielsweise neue Stylesheets verwendet werden, um die bestehenden HTML-Auftritte ohne großen Aufwand mit einem neuen Layout zu versehen und in die neue Anwendung einzubetten. Das vierte Beispiel lädt über den html generator die Startseite der Cocoon-Website, extrahiert Textinformationen über den xpath-Parameter aus dieser Seite und versieht die gesamte Seite per Stylesheet mit einem neuen Hintergrund. <map:pipeline>Fügen Sie den obigen Abschnitt in die Sitemap ein und kopieren Sie das Stylesheet newlayout.xsl in das gleiche Verzeichnis wie die Sitemap. Nach einem Neustart der Servlet-Engine können Sie über http://localhost:8080/cocoon/html das Beispiel aufrufen. Grosse Web Anwendungen bestehen aus vielen Dokumenten. Müsste man für jedes dieser Dokumente eine einzelne XML Pipeline bestehend aus Generator, Transformer und Serializer mit zugehörigem Matcher bauen, so wäre das nicht nur sehr viel Aufwand, sondern die daraus resultierende Sitemap wäre schlichtweg nicht mehr wartbar. Zur Lösung dieses Problems gibt es ein weiteres Konzept innerhalb der Sitemap: die automatische Wertersetzung. Dabei können während der Erstellung der Sitemap Platzhalter verwendet werden, die dann zur Laufzeit durch aktuelle Werte ersetzt werden. In Kombination mit dem wildcard Matcher lässt sich damit eine Pipeline erstellen, die für eine große Anzahl an Dokumenten gültig ist. <map:pipeline>In dem obigen Beispiel wird als Muster für den Matcher das Malzeichen verwendet. Dieses Muster bedeutet, dass jede Anfrage, die keinen Verzeichnistrenner enthält, zutrifft, beispielsweise helloworld oder mein_dokument. Anfragen mit Verzeichnistrenner, wie beispielsweise dokumente/helloworld, treffen nicht zu. Die nachfolgenden Komponenten müssen einen Zugriff auf den tatsächlichen Wert erhalten. Dieses geschieht über die Wertersetzung von Cocoon. Ein Match kann den eingeschachtelten Komponenten Name-Wert-Paare zur Verfügung stellen. Die eingeschachtelten Komponenten können dann anhand des Namens auf den entsprechenden Wert zugreifen. Dieses geschieht dadurch, dass der Name in geschweifte Klammern gesetzt wird. Damit dieser Mechanismus funktioniert, muss die Komponente wissen, welche Namen der Matcher bereitstellt. Im Falle des wildcard Matchers ist der Name die Ziffer eins, somit wird bei der Abarbeitung der Sitemap {1}durch den tatsächlichen Wert des Musters ersetzt. Der file generator ließt beispielsweise die Quelle {1}.xml, d.h. wird das Dokument helloworld angefragt, wird helloworld.xml gelesen usw. Das Muster des wildcard Matchers kann beliebig kompliziert werden. Verwendet man zwei Malzeichen direkt hintereinander, so treffen alle Anfragen zu, d.h. es dürfen auch Verzeichnistrenner vorkommen. Man kann die verschiedenen Muster auch noch mit Konstanten mischen, beispielsweise <map:pipeline>Bei einer Anfrage von benutzer/matthew/dokumente/rezepte/pizza würde das Dokument dokumente/rezepte/pizza.xml vom Generator gelesen und darauf würde das Stylesheet stylesheets/matthew.xsl und dann das stylesheet/doc2html.xsl angewendet. Die Wertersetzung in Zusammenhang mit dem wildcard Matcher erlaubt somit die Erstellung von komplexen Pipelines, die für mehrere Dokumentanfragen zutrifft und diese Dokumente flexibel generiert. Ausblick Gerade diese Flexibilität bei der Zusammensetzung der Pipelines und die einfache Konfiguration über die Sitemap ist ein großer Fortschritt der neuesten Version von Cocoon. Im zweiten Teil unseres Artikels werden wir weitere Möglichkeiten zur Erstellung von Web Anwendungen vorstellen. Beispielsweise werden wir neue Komponenttypen, Actions und Reader, erklären. Mit Hilfe von Actions kann man beliebige Aktionen auf dem Server durchführen; ein Reader erlaubt das Lesen von binären Inhalten wie Bilder oder Filme. Das Repertoire an Standardkomponenten wird ebenfalls erweitert, insbesondere die aus Cocoon 1.x bekannte Möglichkeit, XSP zu verwenden. Abschließend werden weitere Konzepte der Sitemap, Aggregation von Inhalten und das Aufteilen in mehrere Sitemaps, eingeführt. Abgerundet wird der zweite Teil mit Tipps und Tricks zur Konfiguration und neuen Beispielen. Matthew Langham ist seit 10 Jahren bei der Firma s&n in Paderborn, wo er das Open Source Competence Center leitet. Carsten Ziegeler ist Chef-Architekt und Consultant des Open Source Competence Centers der S&N AG. Er beeinflusste maßgeblich das Design von Cocoon 2 und ist darüber hinaus verantwortlicher Release Manager. Zusammen arbeiten sie zur Zeit an eiemn Buch über Cocoon und XML-Applikationen mit Erscheinungstermin Sommer 2002. Links und Literatur
|
||
|
