Das Projekt Cocoon hat sich zur Aufgabe gemacht, die Erstellung von XML-Publishing-Applikationen zu erleichtern. Hierfür bedient es sich aus dem großen Fundus anderer Apache-Projekte wie "Xalan", "Xerces" oder "FOP". Das Apache-Projekt "Avalon", ein Java-Ansatz zur komponentenorientierten Softwareentwicklung, liefert die Basisarchitektur für Cocoon. Cocoon erlaubt auch ohne eigene Java-Programmierung, XML-Applikationen wie Websites oder Publishing Frontends für Datenbanken zu erstellen.
Eine auf Cocoon beruhende Anwendung besteht aus einer Menge von einzelnen Funktionen, die jeweils eine Anfrage (etwa einen Browser-Request) verarbeiten und als Ergebnis ein Dokument (meist eine HTML-Datei) zurückliefern. Durch die Verwendung von XSLT-Stylesheets lässt sich indes eine Vielzahl von Formaten erzeugen, neben HTML beispielsweise auch WML oder PDF. Da der Server die Dokumente zur Laufzeit dynamisch generiert, entfällt die Notwendigkeit, in der Anfrage einen spezifischen Dateinamen anzugeben (etwa http://myserver/index.html). Deshalb können auch Funktionen abhängig vom Typ des Clients (HTML-Browser oder WAP-Handy) das richtige Zielformat erzeugen.
Cocoon ist in Java programmiert und erlaubt die Ausführung als Servlet oder die Ansteuerung mittels eines Command-Line-Interface (CLI). Läuft Cocoon innerhalb einer Servlet-Engine wie "Apache Tomcat", dann werden ankommende Requests von dort an Cocoon weitergeleitet. Eine zentrale Instanz innerhalb von Cocoon durchsucht eine Konfigurationsdatei nach einer passenden Funktion und übergibt dieser dann die Anfrage zur weiteren Verarbeitung.
Dreh- und Angelpunkt der Cocoon-Architektur ist die Sitemap, eine in XML definierte Konfigurationsdatei. Im Wesentlichen besteht sie aus den verschiedenen Funktionen, die Requests entgegennehmen und Dokumente generieren. Die Datei legt aber auch die verschiedenen Komponenten fest, die innerhalb einer Funktion verwendet werden können. Es lassen sich Funktionen erstellen, die nur Daten in ein bestimmtes Layout formatieren, aber auch beispielsweise solche, die Eingaben von einem Benutzer empfangen, sie in eine Datenbank schreiben und anschließend eine E-Mail generieren.
Im Gegensatz zur vorherigen Cocoon-Version wird der Ablauf einer einzelnen Funktion durch die Definition innerhalb der Sitemap bestimmt und nicht mehr über Processing Instructions (PIs) innerhalb der XML-Datendatei. Eine Funktion in Cocoon (meistens als "Pipeline" bezeichnet) besteht aus einer Kette von verschiedenen Komponenten, die entweder aus dem Basisumfang von Cocoon oder aus Eigenentwicklungen stammen können. Eigene Komponenten können durch eine entsprechende Konfigurierung in die Sitemap aufgenommen werden.
Cocoon unterscheidet verschiedene Kategorien von Komponenten, wobei jeder von ihnen eine bestimmte Aufgabe innerhalb einer Pipeline zukommt (die Namen der Komponententypen haben sich gegenüber der Vorgängerversion geändert). Grundsätzlich beginnt jede Pipeline mit genau einem Generator. Dieser erzeugt die XML-Daten, die anschließend durch die Pipeline fließen. Dabei darf es sich entweder um Nutzdaten oder auch um Befehle für nachgelagerte Komponenten handeln. Sie können entweder aus einer Datei gelesen oder etwa auch von einem anderen Server mittels HTTP übertragen werden. Der Generator akzeptiert auch Nicht-XML-Formate, kann daraus XML erzeugen und dieses dann durch die Pipeline schicken.
Im Unterschied zu Cocoon 1, das noch das Document Object Model (DOM) verwendete, sendet der Generator jetzt die einzelnen XML-Tags als SAX-Events (SAX = Simple API for XML) durch die Pipeline. Diese Änderung führt zu einer deutlichen Performance-Steigerung und geringerem Speicherbedarf.
Meist XSLT-TransferIn einer Pipeline folgt auf den Generator ein Transformer als nächste Komponentenkategorie. Ein Transformer wird durch SAX-Ereignisse ausgelöst, die der Generator in die Pipeline schickt. Der Transformer ist dann in der Lage, auf diese Events zu reagieren und mit den übergebenen XML-Daten zu arbeiten. Ein Transformer kann XML-Tags in den Datenstrom einfügen beziehungsweise entfernen oder den Inhalt auf eine andere Art und Weise manipulieren. Als Beispiel sei an dieser Stelle der SQL-Transformer genannt, der seine Befehle (Queries) mittels Tags vom Generator erhält, dann die Abfrage an die Datenbank absetzt, um anschließend die SQL-Daten wieder als Tags in die Pipeline zu senden.
Der am meisten verwendete Transformer ist zweifellos jener für XSLT. Dieser integriert Xalan in Cocoon und erlaubt die Transformation der XML-Daten mittels eines XSLT-Stylesheets. Als eine typische Anwendung dafür sei hier die Umwandlung von XML-Daten nach XHTML erwähnt - XHTML deshalb, weil in der Pipeline nur XML-konforme Formate erlaubt sind.
Eine Pipeline kann mehrere Transformer nutzen. Auf diese Weise lassen sich diese Komponenten miteinander verketten. Ein Transformer ist damit auch in der Lage, Tags für nachgelagerte Transformer zu generieren. Ein Beispiel hierfür wäre die Verwendung des SQL-Transformers, der aus einer Datenbank Befehle für einen nachgelagerten LDAP-Transformer liest.
Endpunkt einer Pipeline ist der Serializer. Er sorgt dafür, dass die XML-Daten in ein Format umgewandelt werden, die das Endgerät oder Programm versteht. Zusätzlich kann ein Serializer dafür sorgen, dass der korrekte Mime-Type (beispielsweise für einen Internet-Browser) gesetzt wird. Bei XML-Formaten, die nah am Ausgangsformat liegen (etwa XHTML zu HTML), muss der Serializer relativ wenig leisten. Cocoon beinhaltet aber auch Komponenten, die es erlauben, aus dem XML-Format XSL-FO (Formatting Objects) Formate wie PDF oder Postscript zu erzeugen.
Eine Pipeline kann mehrere Verzweigungen haben. Dabei können Steuerungskomponenten, so genannte Selectors, den Fluss innerhalb einer Pipeline beeinflussen. Durch die Verwendung eines Selectors, der auf bestimmte Parameter reagieren kann, lässt sich auch eine gewisse Ablauflogik innerhalb der Pipelines festlegen. Als Beispiel dient der Browser-Selector, der abhängig vom benutzten Web-Frontend unterschiedliche Stylesheets auswählen kann.
Neben den bisher beschriebenen Komponentenkategorien existieren auch Komponententypen, die je nach Aufgabe eine Rolle in der Erstellung der Applikation übernehmen können. So erlauben Reader, beispielsweise Bilder etwa als JPEG direkt durch Cocoon zu schleusen, ohne dass eine entsprechende Kopplung von Generator, Transformer und Serializer notwendig wäre.
Cocoon unterstützt auch die Script-basierte Programmierung und stellt hierfür die in XML formulierte Programmiersprache XSP - Extensible Server Pages - zur Verfügung. Mittels des speziellen Server-Pages-Generators können in XSP entwickelte Scripte als Ausgangspunkt für eine Pipeline verwendet werden.
Mit Cocoon 2.0 steht eine leistungsfähige, erweiterbare XML-Plattform für die Erstellung von Websites oder Publishing-Lösungen zur Verfügung. Die Verwendung als vollwertige XML-Middleware-Lösung erfordert noch die Entwicklung von eigenen Komponenten oder den Einsatz ergänzender Produkte. Damit lässt sich Cocoon zu einem Toolkit auch für die Erstellung von Portalen oder XML-Workflow-Systemen aufwerten. (ws)
*Matthew Langham leitet das Open Source Competence Center bei der S&N AG, Paderborn.
Carsten Ziegeler ist Chefarchitekt bei S&N. Er beeinflusste maßgeblich das Design von Cocoon 2.
KomponentenCocoon umfasst mehrere fertige Komponenten, die innerhalb eigener Pipelines verwendet werden können:
File-Generator - erlaubt das Laden von XML-Daten aus Dateien, über HTTP oder FTP;
HTML-Generator - erlaubt das Laden von HTML-Daten und konvertiert diese nach XHTML;
SQL-Transformer - ermöglicht den Zugriff auf SQL-Datenbanken und konvertiert Ergebnisse nach XML;
XSLT-Transformer - ermöglicht Stylesheet-Transformationen innerhalb einer Pipeline;
HTML-Serializer - erzeugt ein für Browser geeignetes HTML-Format aus XHTML;
PDF-Serializer - erzeugt PDF aus XSL:FO-Daten
Browser-Selector - erlaubt eine Beeinflussung des Pipeline-Verlaufs abhängig vom Browser.
Abb: Aufbau einer Pipeline
Das Konzept von Cocoon sieht vor, dass Inhalte abhängig von den jeweiligen Endgeräten unterschiedlich aufbereitet werden. Quelle: Langham/Ziegeler