Abbildung 1: Cocoon als Publishing Framework Servlet
Das XML Projekt der Apache Software Foundation verfolgt drei Ziele:
Das Apache Cocoon Projekt kann wie folgt definiert werden:
„Cocoon ist ein Publishing Framework Servlet, dass mittels seines modularen Reaktorkonzepts ein XML-Quelldokument
je nach anfragendem Client in ein beliebiges Zielformat transformiert.“
Abbildung 1: Cocoon als Publishing Framework Servlet
Abbildung 1 zeigt das Publishing Framework – also einen Publizierungs-Rahmen - den Cocoon zur Verfügung stellt. Die Aufgabe eines solchen Publishing Frameworks ist erst einmal die Kostenreduzierung. Kosten die beispielsweise bei der Veränderung des Layouts eines Internetservices entstehen. Des weiteren soll ein Publishing Framework leicht zu erweitern sein (daher Framework) und den Verwalter von Informationen bei der Veröffentlichung unterstützen.
Die Funktionsweise des Cocoon Servlets kann auch in Abbildung 1 erkannt werden. Ein Mozilla kompatibler Browser stellt über das Internet ein Anfrage an Cocoon für ein XML Dokument auf dem Server. Cocoon erkennt den Browsertyp (anhand des übermittelten user-agent Strings) und weiß, dass dieser Browser HTML bzw. XHTML als Datenformat erwartet. Das Cocoon Servlet – für das in diesem Kontext die Betrachtungsweise als Blackbox ausreicht – nimmt sich daraufhin das verlangte XML Dokument und transformiert dies mit XSL Stylesheets in XHTML.
Diese Funktionalität kann allerdings nur erreicht werden, wenn ein neuer Weg zur Erstellung und Veröffentlichung von Informationen genutzt wird. Bisher (Abbildung 2) waren bei „traditionellen“ HTML Dokumenten die Schichten Inhalt, Layout und Programmierlogik fest miteinander verschmolzen.
Abbildung 2: "Traditionelle" HTML Dokumente
Das heißt, dass im besten Fall ein Layouter ein HTML Template, also eine Vorlage erstellt hat, in die er beispielsweise eine Menüstruktur und Grafiken eingesetzt hat. Danach hat ein Programmierer noch ein paar Javascript Funktionen eingefügt und schließlich setzt ein Redakteur den eigentlichen (Text-) Inhalt in das Dokument ein. Das Management (Projektmanagement oder auch Unternehmensführung) kann letztendlich nur eine Datei betrachten und diese beurteilen.
Cocoon geht einen anderen Weg zur Veröffentlichung der Informationen (Abbildung 3). Die drei Schichten Inhalt, Layout und Programmierlogik werden strikt voneinander getrennt und in verschiedenen Dateien bearbeitet.
Abbildung 3: Trennung der drei Schichten mit Cocoon
Bei diesem Ansatz ist also ein Layouter für ein Stylesheet zuständig, ein Programmierer für dynamischen Inhalt in einer eXtensible Server Page (XSP) und ein Redakteur für den Inhalt einer XML Datei. Im Management kommt es ebenfalls zu einer Dreiteilung: Jedes der Teams Inhalt, Layout und Logik hat nun einen gezielten Ansprechpartner im Management.
Die Vorteile liegen hierbei auf der Hand: sowohl Stylesheets als auch Programmierlogik können einfach und effektiv weiterverwendet werden. Der Overhead für das Management wird verringert und die Time-To-Market des Internetservices wird sehr kurz gehalten – und das ist im besonders schnelllebigen Internetmarkt von unschätzbarem Wert, damit das Unternehmen agieren kann und nicht reagieren muss.
Und wenn es doch mal reagieren muss, dann kann es wenigstens schnell reagieren.
Die Idee der Trennung der drei Schichten Inhalt, Layout und Logik, wie sie Cocoon verfolgt, ist nicht neu – allerdings bewährt. Redaktionssysteme von Tageszeitungen nutzen ein ähnliches Konzept wie Cocoon.
Abbildung 4: Funktionsweise des ProMan Redaktionssystems
Abbildung 4 zeigt die Funktionsweise eines solchen Redaktionssystems. Das Softwareprodukt ProMan trennt die Bereiche Layout (blau) in Form von Blattplanung bzw. Teilseitenmontage von dem Bereich Inhalt (grün), in dem die Zeitungsartikel von den Redakteuren erstellt werden.
Die Blackbox „ProMan“ setzt wie Cocoon diese einzelnen Schichten zusammen.