Cocoon ist ein eingestelltes, freies Webframework für XML-Publishing der Apache Software Foundation. Es wurde geschaffen, um Daten in XML-Form zu speichern und mittels XSL formatiert auszugeben. Als Ausgabeprodukte von XML-Daten können XHTML, PDF, RTF und viele weitere (siehe unten) stehen.
Der Quellcode von Cocoon fällt unter die Apache-Lizenz und ist somit freie Software.
Cocoon wurde im Januar 2025 von der Apache Foundation eingestellt und im März 2025 archiviert.
Entstehung Cocoon wurde 1998 von dem italienischen Studenten Stefano Mazzocchi geschrieben (angefangen), während er den Science-Fiction-Film Cocoon sah, wonach das System benannt wurde.
Einführung Das Konzept von Cocoon baut im Vergleich zu anderen webbasierten Frameworks auf einem neuen Ansatz auf. Bei HTML-Dokumenten werden in der Regel die Schichten Inhalt, Layout und Programmierlogik fest miteinander verbunden, oftmals sogar in einer Datei codiert. Cocoon geht einen anderen Weg zur Veröffentlichung der Informationen. Die drei erwähnten Schichten werden strikt voneinander getrennt und müssen in separaten Dateien bearbeitet werden. Dies bedeutet für den Entwickler anfangs einen größeren Aufwand beim Erstellen der Webseiten, da er drei Dateien erstellen und pflegen muss. Dieser Mehraufwand kann bei großen Projekten im Verlauf der Entwicklung mehrfach ausgeglichen werden, da einzelne Logik- oder Layoutteile problemlos durch Wechseln der entsprechenden Datei ausgetauscht, in andere Projekte integriert und somit wieder verwertet werden können.
Um das Konzept der Trennung der einzelnen Schichten in Cocoon umzusetzen, wurde XML gewählt, da XML diese Anforderungen konsequent erfüllt. Über den drei Schichten steht das Management, das jeden Teil der Entwicklung steuert.
Bei einem Cocoon-Projekt könnte beispielsweise ein Designer für ein Stylesheet (Layout) zuständig sein, ein Programmierer für die Logik und ein Redakteur für den Inhalt einer XML-Datei. Weiterhin ist Cocoon mit Java entwickelt worden, weshalb es plattformunabhängig ist. Cocoon unterstützt außerdem die Steuerung des Seitenflusses (Cocoon Control Flow), EAI-Anforderungen sowie die Errichtung von Webportalen. Darüber hinaus integriert es sich nahtlos in die J2EE-Welt.
Funktionsweise Technisch basiert Cocoon auf der Servlet-Technologie. Ein Servlet ist eine Java-Klasse, die Client-Anfragen an Webserver entgegennimmt und verarbeitet. Innerhalb dieser Verarbeitung wird eine Antwort erzeugt, die dann wiederum an den Webserver übergeben wird. Tomcat der Apache Software Foundation ist die Referenzimplementierung dieser Technologie, die die Programmiersprache Java der Firma Sun Microsystems benutzt.
Mittels Cocoon lassen sich nicht nur dynamische Webanwendungen erstellen, auch die lokale Benutzung ist möglich. Apache Lenya ist ein Content-Management-System, welches auf Cocoon aufbaut.
Darüber hinaus bringt Cocoon auch eine Portal Engine mit, mit der sich Portale erstellen lassen.
Aufbau Cocoon hat ein vollständig objektorientiertes Funktionsmodell. Dadurch wird es sehr leicht möglich, neue Komponenten zu integrieren oder bestehende zu ersetzen. Alle Komponenten basieren auf dem Modell von Apache Excalibur, das den genauen Aufbau jeder Komponente vorgibt. Es besteht die Möglichkeit, eigene Komponenten zu entwickeln, die sich durch Vererbung in das bestehende Modell integrieren lassen.
Cocoon 2 Mit Cocoon 2.x haben sich die Entwickler entschlossen, Cocoon neu zu implementieren, um aus den Fehlern der Version 1.x zu lernen. Verändert wurde die interne Architektur sowie das Konzept von Cocoon. Hinzugekommen ist die flexible Sitemap, mit der sich Processing Instructions in beliebiger Reihenfolge durchführen lassen. Weiter wurde die Performance signifikant verbessert – einerseits durch eine schnellere Caching-Technik und weiter durch eine optimierte Abarbeitung der XML-Dokumente: Statt mit dem DOM-Parser komplexe Baumstrukturen aufzubauen, wird nun der ereignisgesteuerte SAX-Parser eingesetzt.
Durch diese Reimplementierung besitzt Cocoon heute zwei Standbeine: Während die älteren Konzepte nach wie vor existieren, sind durch die Reimplementierung viele neue, notwendige und hilfreiche Techniken hinzugekommen. Aufgrund der Abwärtskompatibilität ist es möglich, sowohl ältere als auch neuere Techniken zu verwenden oder sie sogar zu kombinieren.
Cocoon 2.2 Seit Mai 2008 ist die grundlegend überarbeitete Version 2.2.0 von Apache Cocoon als „stabil“ gekennzeichnet. Während den Vorgänger-Versionen das inzwischen eingestellte Apache-Avalon-Framework zugrunde lag, basiert die neue Version auf Spring. Weiterhin wurde das Build-Tool Ant durch Apache Maven ersetzt.
Cocoon 2.2 ist, wie auch seine Vorgänger, stark komponentenorientiert ausgelegt. Die Entwicklung findet nun in eigenständigen Modulen, sogenannten Blocks, statt. Diese neue Architektur bietet erhebliche Vorteile, beispielsweise durch den Rapid Class Reloader, der das Kompilieren von JAVA-Quellcode automatisiert, oder die Möglichkeit zur Integration von Funktionalität des Spring-Frameworks. Auch die Handhabung (Anlegen von Blocks, Kommunikation von Blocks untereinander, Eclipse-Integration etc.) wurde im Vergleich zu den Vorgängern wesentlich verbessert.
Bestandteile Cocoon ist auf der Basis des Java-Frameworks Spring implementiert und kann beliebig um eigene Java-Komponenten erweitert werden. Die eigentliche Arbeit von Cocoon wird in Pipelines ausgeführt. Die Pipeline besteht aus bis zu sieben Komponententypen, welche jeweils der Logik oder zur Bearbeitung dienen.
Sitemap Die Sitemap ist der Mittelpunkt jeder Cocoon-Anwendung. Die Sitemap ist eine XML-Datei mit Namen sitemap.xmap. Diese befindet sich immer im Wurzelverzeichnis des aktuellen Projektes. Unterverzeichnisse des Projektes können eine Subsitemap enthalten. Sie definiert die unterschiedlichen Cocoon-Komponenten und die Client-/Server-Interaktionen in den sogenannten Pipelines. Die Aufgabe einer Sitemap ist es zu entscheiden, was passiert, wenn ein bestimmter Request vom Benutzer oder dem System angefordert wird, z. B. das Aufrufen einer bestimmten Webseite.
Um zu erkennen, welche Aktionen nach einem bestimmten Request durchgeführt werden, besitzt die Sitemap so genannte Matcher.
Matcher Benutzer-Anfragen (Requests wie beispielsweise URLs oder Cookies) werden in der Sitemap gegen die Matcher getestet bis eine Übereinstimmung gegeben ist. Die Antwort (Response) ergibt sich dann aus der Ausführung der zum Matcher gehörenden Aufgaben. Die Matcher selbst enthalten Folgen von Zeichen, die Wildcards oder Regulären Ausdrücken entsprechen.
Selektor Der Selektor wertet bestimmte Informationen des Requests aus. Dabei wird meist ein HTTP-Header übertragen, wenn eine Webseite angefordert wird. Ein Selektor stellt eine Art Switch-Anweisung dar.
Es stehen ca. 8 Selektoren zur Verfügung, hier nur die wichtigsten: BrowserSelector (Prüfung des verwendeten Browsers) HostSelector (Prüfung des Hostparameters des HTTP-Requests) ParameterSelector (Prüfung eines definierten Parameters innerhalb Cocoons) HeaderSelector (Prüfung des Inhaltes des HTTP-Request-Headers)
Pipeline Der Matcher und seine dazugehörenden Aufgaben werden als XML Pipeline bezeichnet. Eine typische Pipeline besteht aus einem Generator, eventuell gefolgt von einem oder mehreren Transformern und schließlich einem Serializer.
Die Aufgaben innerhalb der Pipeline werden seriell abgearbeitet. Matcher sind das Bindeglied zwischen einer Anfrage (durch einen Client an Cocoon) und den auszuführenden nachfolgenden Operationen der Pipeline.
Die folgende Abbildung verdeutlicht das Konzept der Pipeline, in welchem zuerst ein Request an die Sitemap geschickt wird, danach der passende Matcher aufgerufen und die Aufgaben der Reihe nach durchgeführt werden. Die bereits mehrfach erwähnten Aufgaben werden von so genannten Komponenten erledigt, die in Cocoon eingebunden werden. Die Komponenten, die innerhalb der Pipeline zum Einsatz kommen, sind ein Generator, ein Transformer und ein Serializer.
ohne|gerahmt|Aus der Anfrage wird nacheinander durch File Generator, XSLT Transformer und HTML Serializer eine Antwort erzeugt. Die Übergabe zwischen den Komponenten erfolgt mittels SAX.
Generatoren Der Generator ist der Startpunkt der Bearbeitungskomponente der Pipeline. Generatoren haben die Aufgabe, strukturierte Daten, z. B. XML-Daten oder Inhalte einer Datenbank, in einen SAX-Stream umzuwandeln. Dieser wird dann an den Transformator weitergegeben. Es kann pro Pipeline nur einen Generator geben.
Transformer / Transformatoren Transformatoren wandeln die vom Generator erzeugten XML-Elemente um. Es kann pro Pipeline mehrere optionale Transformatoren geben. Jeder Transformator kümmert sich oftmals nur um bestimmte Elemente des SAX-Streams. Es können mehrere Transformatoren hintereinander ausgeführt werden, um ein Dokument mit Inhalt und Layout zu erzeugen. Auch eine Pipeline ohne Transformatoren ist möglich. Der Transformator kommt besonders bei Webseiten mit mehrsprachigem Inhalt zur Anwendung (Internationalisierung). Häufig wird ein Transformationsschritt mit Hilfe eines XSLT-Stylesheet durchgeführt.
Serializer Der Serializer wandelt die Ausgabe des Transformators, den SAX-Stream, in ein Zieldokument um, in dem der Inhalt dann repräsentiert werden kann. Die Ausgabe erfolgt als Stream (binär oder Zeichen) und wird als Response gesendet. Normalerweise endet eine Pipeline mit dem Serializer.
Reader Der Reader eignet sich für sehr einfache Pipelines, da hier Dateien ohne weitere Verarbeitung an den Client zurückgeliefert werden können. Er ist hauptsächlich für Nicht-XML-Dateien in einer Cocoon-Site geeignet.
Zwei Reader sind bereits mit Cocoon mitgeliefert:
ResourceReader (zum Lesen von Binärdaten) JSPReader (zum Lesen von Ausgaben von JSP-Seiten)
Action Eine Action dient zur Steuerung von Abläufen auf einer Site. Dabei werden dynamische Laufzeiten manipuliert oder Operationen auf dem Server durchgeführt. Eine Action erzeugt also keine dargestellten Daten, sondern steuert den Ablauf innerhalb der Pipeline.
Mögliche Ausgabeformate XML HTML XHTML WML PDF RTF Excel Flash PHP etc.
XSP