Komplexe XML-Anwendungen mit dem Open Source Projekt Apache Cocoon erstellen - Teil 2

Die Verpuppung

Matthew Langham und Carsten Ziegeler

In Teil 1 unseres Artikels [1] stellten wir die neue Version von Cocoon [2] vor und demonstrierten anhand von einigen Beispielen die vielfältigen Einsatzmöglichkeiten dieser Open Source-Lösung. In diesem Teil werden wir zusätzliche Konzepte und Komponenten vorstellen, die es erlauben, Cocoon auch für komplexere Anwendungen zu verwenden. Einen Ausblick auf weitere Einsatzgebiete für Cocoon soll diesen Teil abrunden.

Architektur

Wie wir im ersten Teil gesehen haben, ist die zentrale Schaltstelle von Cocoon die Sitemap. Diese in XML beschriebene Datei beinhaltet sowohl die Definition der vorhandenen Java-Komponenten als auch die einzelnen Pipelines. Eine Pipeline stellt in Cocoon eine funktionale Einheit dar. Eine Pipeline bekommt eine Anfrage, z.B. von einem Browser, und liefert als Ergebnis ein Dokument zurück. Durch die Integration verschiedener Komponenten in der Pipeline können Daten aus den unterschiedlichsten Quellen (z.B. aus einer Datenbank) mittels Stylesheets in Formate wie HTML, WML oder PDF formatiert und dann an den Browser zurückgeliefert werden. Für die Erstellung der einzelnen Pipelines stehen eine Vielzahl von Komponenten zur Verfügung. Zusätzliche Komponenten lassen sich leicht entwickeln und durch eine entsprechende Konfigurierung aufnehmen. Bei einem Aufruf durchsucht Cocoon die Sitemap und übergibt den Request an eine Pipeline, die dafür, mittels eines so genannten Matchers, registriert ist.
Um die Anzahl der notwendigen Pipelines zu verringern, bietet Cocoon die Möglichkeit, bei den Matcher-Komponenten mit Wildcards zu arbeiten. Eine andere Möglichkeit, die Ergebnisse mehrerer Pipelines zusammenzuführen, bietet das Konzept der Content Aggregation.


..Der Inhalt von news/slashdot.xml..

..Der Inhalt von news/moreover.xml..

Nach der Aggregation innerhalb der Pipeline folgt ein Stylesheet, das die beiden Teile entsprechend in dem fertigen Dokument layoutet. Abschließend wird der html serializer verwendet. Anstelle des cocoon:-Protokolls, das interne Anfragen gegen Cocoon stellt, hätte dort auch ein beliebiger anderer URI stehen können, die beispielsweise die Daten direkt über HTTP holt. Wichtig ist lediglich, dass die Quelle gültiges XML liefert.
Ein weiteres Einsatzgebiet von Content Aggregation ist das Aufbauen von Dokumenten, die aus verschiedenen Einzeldokumenten bestehen: Beispielsweise baut sich eine Website oft aus einem festen Kopfbereich, einer Navigationsleiste und dem eigentlichen Inhalt auf. Um die drei einzelnen Dokumente (Kopfbereich, Navigationsbereich und Inhalt) zusammenzuführen, kann man entweder Frames verwenden oder aber Content Aggregation.
Eine Cocoon-Anwendung besteht aus einer Menge an Funktionen, die dann in der Sitemap definiert werden. Da dies für komplexe Anwendungen zu sehr vielen Einträgen und somit zu einer komplexen und unüberschaubaren Sitemap führen kann, bietet Cocoon das Konzept der Sub-Sitemaps an.

Das Beispiel mountet eine Sub-Sitemap für alle Anfragen, die mit sub beginnen. Diese Anfragen werden an eine Sitemap weitergereicht, die über sub/sitemap.xmap erreichbar ist (Attribut src). Das Attribut uri-prefix bezeichnet den Teil des URI, der von dem Request abgeschnitten wird, wenn er an die Sub-Sitemap weitergeleitet wird. Das heißt, die Anfrage sub/mydocument würde als mydocument an die Sub-Sitemap weitergeleitet und dort bearbeitet. Ein entsprechender Match-Knoten in der Sub-Sitemap darf dann lediglich auf mydocument testen, nicht aber auf den Prefix. Durch dieses Abschneiden eines Prefixes können Sub-Sitemaps unabhängig von dem URI, unter dem sie aufgehangen werden, gestaltet werden. Die Mount-Anweisung in der Haupt-Sitemap bestimmt dann den Aufhängepunkt.
Über diese Möglichkeit lassen sich eigenständige Teile einer Applikation in eine Sub-Sitemap auslagern. Dies erhöht die Wartbarkeit und erlaubt es, die Haupt-Sitemap übersichtlicher zu gestalten.
In einer Sub-Sitemap lassen sich alle Cocoon-Komponenten verwenden. In den Pipelines können Generator, Transformer und Serializer eingesetzt werden. Es lassen sich aber auch noch weitere Komponenten verwenden, die wir jetzt vorstellen möchten.

Komponenten

Bisher haben wir die am häufigsten verwendeten Cocoon-Komponenten vorgestellt: Eine Pipeline startet grundsätzlich mit einem Generator. Nachfolgende Transformer verarbeiten das XML Dokument und leiten das Resultat an einen Serializer weiter, der das endgültige Ausgabeformat erzeugt.
Diese Kette aus verschiedenen Komponenten ist speziell für die Verarbeitung von XML konzipiert und eignet sich nicht für die Bereitstellung von binären Daten wie z.B. Bildern. Daher bietet Cocoon hierfür eine weitere Komponente an.

Reader

Ein Reader kann direkt Daten erzeugen und diese ohne weitere Verarbeitungsschritte zum Client liefern. Beispielsweise kann ein Reader verwendet werden, um bestehende Bilder oder Filme in den Web-Auftritt zu integrieren. Von der Arbeitsweise ist ein Reader mit einer Generator-Serializer-Kombination vergleichbar. Der Unterschied besteht darin, dass ein Reader nicht erst Daten nach XML wandelt und diese dann wieder in das gewünschte Ausgabeformat zurückwandelt, wie das bei der Verwendung eines Generators und eines Serializers der Fall wäre.
Cocoon bietet den resource reader, der Daten aus einer Datei oder über einen URI lesen kann. Beispielsweise kann er zusammen mit dem aus dem ersten Teil bekannten wildcard matcher dazu verwendet werden, alle Bilder zu liefern:

Jede Anfrage an Cocoon, die mit images/ startet wird von dem Reader verarbeitet: Er versucht, eine Datei gleichen Namens von der Festplatte zu lesen. Sobald ein Reader seine Arbeit beendet hat, ist die Abarbeitung der Sitemap beendet.
Somit kann Cocoon nicht nur Dokumente auf XML-Basis, sondern beliebige Formate verarbeiten. In einer normalen Webanwendung ist dieses sehr wichtig, da in der Regel selbst normale Webseiten Bilder enthalten. Ohne die Möglichkeiten des Readers müsste man die Bilder außerhalb von Cocoon verwalten.
Eine weitere Komponente, die gerade bei der Erstellung von komplexeren Anwendungen wie z.B. Shops oder Portalen verwendet wird, ist die Action.

Action

Die Komponenten, die wir bisher betrachtet haben, haben gemeinsam, dass sie den Request oder besser das Dokument beeinflussen. Wenn man allerdings Webanwendungen entwickelt, muss man Arbeiten auf dem Server ausführen, die nicht direkt das Dokument beeinflussen. Will man beispielsweise einen Shop bauen, so muss man neue Benutzer in eine Datenbank einfügen, Artikel in den Warenkorb aufnehmen usw. Und genau hierfür sind Actions geeignet.
Die Definition einer Action ist denkbar einfach: Eine Action führt eine bestimmte Arbeit aus. Sie erzeugt keine Ausgabe und nimmt nicht an der XML-Verarbeitung teil. Allerdings kann eine Action auch den Fluss durch die Sitemap beeinflussen und Informationen an andere Komponenten wie beispielsweise einen Generator weitergeben.
Das folgende Beispiel verwendet die request action von Cocoon. Diese Action führt keine Arbeit aus, sondern reicht die Werte von Request-Parametern an andere Komponenten weiter. Jede Komponente, die in das map:act-Element, das die Action aufruft, eingeschachtelt ist, hat Zugriff auf diese Werte. Diese Werte werden von der Action als Schlüssel/Wert-Paare abgelegt, wobei der Schlüssel der Name des Request-Parameters ist und der Wert der zugehörige Wert. Die Komponenten greifen dann über {Schlüsselname} auf den Wert zu.

In dem Beispiel stellt die request action die Request-Parameter bereit und ein eingeschachtelter file generator verwendet den Wert des Parameters name, um daraus die zu lesende XML-Datei zu bestimmen. Wird diese Pipeline beispielsweise mit http://localhost:8080/cocoon/actiontest?name=sunshine aufgerufen, so liest der Generator die XML-Datei product_sunshine.xml.
Darüber hinaus bietet Cocoon weitere Actions, die beispielsweise verschiedene Datenbankzugriffe bieten, die testen, ob Dateien auf dem Server vorhanden sind, oder die Request-Parameter-Werte, die aus einem Formular geschickt wurden, auf Gültigkeit prüfen.
Alle Komponenten, die wir bisher betrachtet haben, können ohne Programmierkenntnisse innerhalb einer Cocoon-Applikation verwendet werden. Anders sieht es dagegen mit einer Möglichkeit aus, die es bereits seit der ersten Cocoon-Version gibt: XSP.

Extensible Server Pages (XSP)

Um den Umstieg von Cocoon 1.x auf die neue Cocoon-Version zu erleichtern, gibt es weiterhin die Möglichkeit eXtensible Server Pages (XSP) innerhalb von Cocoon zu verwenden. XSP ist eine Skriptsprache ähnlich wie JSP. Ein XSP-Skript ist ein XML-Dokument, das entsprechende Anweisungen enthält, die von der XSP-Komponente ausgewertet werden. Diese Anweisungen können direkt Java Code enthalten. Darüber hinaus ist es möglich, so genannte Taglibs zu entwickeln, die vorgefertigte Anweisungsblöcke für bestimmte Aufgaben enthalten. So gibt es beispielsweise Taglibs für Datenbankabfragen und für die Sessionverwaltung. Eine genauere Einführung findet man auf der Cocoon-Website [3].
Mittels eines speziellen Generators, dem serverpages generator, kann eine XML-Pipeline aufgebaut werden, um ein Dokument zu generieren. Somit pictureet eine XSP-Seite den Startpunkt für eine Pipeline. Auf den Generator können weitere Komponenten wie beispielsweise der xslt transformer folgen.
In der derzeitigen Cocoon-Version wird XSP zwar unterstützt, generell herrscht aber die Meinung, dass die Verwendung von XSP nicht immer eine optimale Lösung darstellt. Der wohl größte Nachteil ist, dass man Programmierkenntnisse benötigt, um XSP-Seiten zu schreiben. Darüber hinaus können XSP-Seiten die von Cocoon angestrebte Trennung zwischen Content, Logik und Layout wieder vermischen. Dennoch kann es Einsatzszenarien geben, wo sich der Einsatz einer Skriptsprache anbietet.

Cocoon als out of the box Publishing Plattform

Wer jetzt Appetit auf Cocoon bekommen hat, kann sich die Software von der Website [2] herunterladen und installieren. Als Laufzeitumgebung eignet sich z.B. der Apache Webserver und Apache Tomcat Servlet Engine. Genaue Installationsanweisungen findet man dann in der Distribution. Nach der Installation steht ein umfangreiches XML/XSL Publishing System zur Verfügung, mit Beispielen, die die hier beschriebenen Konzepte anschaulich darstellen.
Diese Artikelserie konnte die vielfältigen Möglichkeiten von Cocoon nur anreißen. Eine grundlegende Einführung in XML-Applikationen und eine ausführliche Beschreibung der Cocoon-Software mit weiteren Beispielen kann man demnächst in [5] nachlesen. Da die Cocoon-Gemeinde bereits ziemlich groß ist, lassen sich in der Zwischenzeit weitere Tipps und Tricks zu Cocoon über die Mailing Listen [2] abfragen oder durch gezielte Suche in den Archiven [4] finden.

Ausblick

Cocoon wird derzeit primär als XML Publishing Framework eingesetzt. Dennoch eignet sich die Lösung auch für den Einsatz als Basis für komplexere XML-Anwendungen. Durch die Integration von eigenen Komponenten lassen sich Lösungen schaffen, die in ihrer Ausrichtung vom Portal bis hin zu einem XML-Workflow-System reichen. Da viele Standards ebenfalls auf XML beruhen, eignet sich Cocoon auch für den Einsatz als, beispielsweise, Plattform für Web Services.
Durch die Rückgabe von Komponenten an das Projekt wird die verfügbare Softwarebasis stets erweitert. So sind in den letzten Monaten Komponenten für die Erstellung von Portalen und Authentisierung in das Projekt zurückgeflossen und stehen nun für alle Cocoon-Projekte zur Verfügung.

Matthew Langham ist seit 10 Jahren bei der Firma S&N, Paderborn. Seit einem Jahr leitet er das Open Source Competence Center. Gemeinsam mit Carsten Ziegeler schreibt er gerade ein Buch über die Erstellung von XML Applikationen mit Cocoon, das im Sommer erscheinen wird. Carsten Ziegeler ist Chef-Architekt und Consultant des Open Source Competence Centers der S&N AG. Neben seiner Teilnahme in einigen Open Source und Freeware Projekten, ist er ein aktiver Entwickler des Apache Cocoon und des Apache Avalon Projektes.

Geschrieben von
Matthew Langham und Carsten Ziegeler
Kommentare

Schreibe einen Kommentar

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