Lade Inhalt...

Das Apache Cocoon Projekt

Ausarbeitung 2000 13 Seiten

Informatik - Technische Informatik

Leseprobe

Inhaltsverzeichnis

Einführung

Das Apache XML Projekt
Das Apache Cocoon Projekt
Ein bewährtes Konzept

Architektur
Verwendete Techniken
XML
XSLT
XSL:FO
XSP - eXtensible Server Pages
XSP - eXtensible Server Pages
Wichtige XSP Tags
Kombination XML & XSP
Das Cocoon Servlet
Warum Java?
Das Cache System

Abschließende Informationen
Stärken und Schwächen
Cocoon vs. JSP & ASP
Cocoon vs. PHP
Leitfaden zum Einsatz
Cocoon 2

Literaturverzeichnis

Einführung

Das Apache XML Projekt

Das XML Projekt der Apache Software Foundation verfolgt drei Ziele:

I. Das Projekt soll eine Austauschplattform für alle Arbeiten innerhalb der Foundation sein, die mit XML zu tun haben.
II. Das Projekt soll ein Feed Back aus Sicht der Implementierenden an standardisierende Organisationen wie z.B. dem W3C liefern.
III. Das Projekt soll hochwertige XML Lösungen erstellen, die kommerziellen Produkten in nichts nachstehen.

Das Apache XML Projekt selber besteht aus derzeit 6 Unterprojekten, nämlich

1. dem XML Parser Xerces-J,
2. dem XSLT Stylesheet Processor Xalan,
3. dem XSL Formatter FOP,
4. dem JavaScript/XML Projekt Xang,
5. dem Simple Object Access Protocol SOAP und schließlich
6. Cocoon.

Das Apache Cocoon Projekt

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 in dieser Leseprobe nicht enthalten
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 in dieser Leseprobe nicht enthalten
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 in dieser Leseprobe nicht enthalten
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.

Ein bewährtes Konzept

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 in dieser Leseprobe nicht enthalten
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.

Architektur

Verwendete Techniken

Im folgenden werden die Techniken, die Cocoon nutzt, kurz erklärt.

XML

Eine Syntax für hierarchische Dokumente und zum Strukturieren von Informationen bzw. Dokumenten (im Gegensatz zu HTML, welches für die Präsentation von Informationen konzipiert wurde).

XSLT

Eine Sprache - also eine XML Document Type Definition (DTD) - zum transformieren von XML in ein beliebiges Zielformat.

XSL:FO

XSL:Formating Objects ist ebenfalls eine Sprache, um 2D Layout von Text zu beschreiben. Dabei ist es egal, ob es sich um Printmedien wie z.B. einen Drucker oder Digitalmedien wie PDF's handelt.

XSP - eXtensible Server Pages

XSP ist eine DTD zur Trennung von Inhalt & Logik und hat somit eine ähnliche Aufgabe wie XSL, dass zur Trennung von Inhalt & Layout verwendet wird.Eine XSP Seite ist kompilierter Code und somit entsteht bei der Anfrage eines Clients kein zusätzlicher Aufwand in Form von parsen oder interpretieren.

XSP - eXtensible Server Pages

Eine XSP Seite ist ein XML Dokument mit dynamischem Inhalt. Diese Dynamik wird durch Direktiven erzielt, die in Tags gesetzt werden. Direktiven, also Anweisungen, werden entweder aus vor- oder aus anwenderdefinierten Bibliotheken entnommen.

Wichtige XSP Tags

· <xsp:page>

Das Root Element jeder XSP Seite. Hier wird die verwendete Programmiersprache angegeben, wobei der Standard ,,Java" ist. Dies ist momentan auch die einzige Programmiersprache die in XSP Seiten verwendet werden kann. Für die Zukunft ist allerdings geplant, alle Sprache anzubieten, die auch die Java Virtual Machine unterstützt.Zusätzlich wird im Root Element der eindeutige Namespace definiert und Tag Bibliotheken bzw. Java Pakete importiert.

<xsp:page

language="java"

xmlns="http://www.apache.org/1999/XSP/Core/"

>

· <xsp:logic>

In diesen Bereich wird die eigentliche Programmierlogik der XSP Seite eingefügt. Dieser Inhalt wird später in ausführbaren Code verwandelt.

<xsp:logic>

String formatDate(Date d, String muster) {

return (new SimpleDateFormat(muster)).format(d);

}

</xsp:logic>

In diesem Beispiel wird eine Funktion formatDate definiert, die als Parameter ein Datumsobjekt d und einen String muster erwartet und dann mittels der java.text Funktion SimpleDateFormat das aktuelle Datum nach dem gewünschten Muster transformiert.An dieser Stelle können beliebige Java Konstrukte eingesetzt werden, so sind hier u.A. natürlich auch SQL-Abfragen möglich.

· <xsp:expr>

Mit xsp:expr(ession) werden Ausdrücke in den XML Baum eingesetzt und schließlich in Text umgesetzt. Als Beispiel dient hier eben besprochene Funktion formatDate.

Aktuelle Zeit und Datum:
<xsp:expr>

formatDate(new Date(), "HH:mm dd.MM.yyyy")

</xsp:expr>

Die Funktion formatDate liefert einen String der Form 11:00 01.12.2000 zurück und dieser String wird ein neues Blatt im XML Baum.

Kombination XML & XSP

Es gibt zwei Möglichkeiten, XSP Seiten zu erstellen. Die erste ist, den XSP Code in ein normales XML Dokument einzufügen (in Abbildung 5 das index.xml Dokument).

Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5: XML Seite ist XSP Seite

Diese index.xml beinhaltet nun zwei Processing Instructions (pi): Instruktion Nr.1 ist die geforderte Verarbeitung als XSP Seite (,,XSP" Kasten). Der von der XSP Seite gelieferte Output soll dann - gefordert durch die 2. Instruktion - von einem Stylesheet bearbeitet werden, nämlich von index.html.xsl. Das Resultat ist dann ein Dokument index.html, welches an den Client geschickt wird.

Dem aufmerksamen Leser fällt auf, dass in dieser Verarbeitungskette nicht die Vorteile genutzt werden, die XSP mit sich bringt: es wird nicht der Inhalt von der Programmierlogik getrennt. Beides ist in dem index.xml Dokument hinterlegt.

Um sinnvoll mit XSP zu arbeiten, sollte man die zweite Möglichkeit der Implementierung nutzen. Bei dem Ansatz, der in Abbildung 6 zu erkennen ist, wird der Inhalt strikt von Logik und Layout getrennt.

Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6: XSP Seite wird aus XML Seite erstellt

In der index.xml ist nun neben dem (redaktionellen) Inhalt nur noch eine pi vorhanden, nämlich die Instruktion, dieses XML Dokument mit einem XSL Stylesheet zu bearbeiten. In diesem Stylesheet - hier xspIncluded.xsp.xsl - ist nur XSP Code vorhanden, der in den Dokumentenkopf von index.xml (bzw. dessen DOM's) eingesetzt wird. Des weiteren hat dieses Stylesheet zwei pi's: die erste pi zur Erstellung einer XSP Seite und die zweite pi zum Anwenden eines zweiten XSL Stylesheets.

Die Kombination aus index.xml und xspIncluded.xsp.xsl ergibt also eine XSP Seite, die wie ein XML Dokument behandelt wird und auf welches dann ein zweites Stylesheet - index.html.xsl - angewendet wird, um den Output als XHTML zu formatieren.

In dieser Verarbeitungskette kann XSP seine Stärke demonstrieren, nämlich die Trennung von Inhalt und Logik.

Das Cocoon Servlet

Cocoon ist ein Servlet aus mehreren Komponenten, bzw. ,,Unter-Servlets". Diese Architektur wird von den Autoren als Reactor Pattern, einem Reaktor Konzept betitelt.

Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7: Architektur des Cocoon Servlets

Das Framework, dass Cocoon zur Verfügung stellt, wird in Abbildung 7 beschrieben. Alle orange/gelben Bereiche sind eben dieses Framework und die Blackboxen sind Komponenten, die in Cocoon standardmäßig implementiert sind und vom Anwender mit minimalem Aufwand durch eigene Komponenten ersetzt werden können.

Um die Architektur besser zu verstehen, wird nun der Weg eines Dokumentes (oder besser: dessen DOM Abbild) durch das Cocoon Servlet von der Anfrage bis zur Antwort an den Client im Detail beschrieben.

1. Request

Die Anfrage des Clients nach einem bestimmten XML Dokument auf dem Server beinhaltet wichtige Informationen für die Processing Engine. Neben der URL ist natürlich auch die Art des Clients (anhand des user-agent Strings) wichtig für spätere Verarbeitungsschritte.

2. Producer

Der Producer ist verantwortlich für die Übergabe von strukturierten Informationen in Form eines DOM's an den Reaktorkern. Hinter dem Producer versteckt sich also in den meisten Fällen nichts weiteres als ein XML Parser.

3. Reaktorkern

Der Reaktorkern (,,U" um Processor) selber macht nichts weiteres als zu determinieren, welcher...

4. Processor

mit dem Dokument arbeiten soll (eine XSL Transformation, eine XSP Seite etc.). Der Processor erweitert dadurch das DOM. Danach verlässt das DOM auch schon den Reaktorkern und befindet sich beim...

5. Formatter

Bei diesem Schritt in der Verarbeitungskette wird das DOM als Stream für den Client vorbereitet.

6. Reply

Hierhinter verbirgt sich ein fertig formatiertes Dokument inklusive aller nötigen Angaben wie MIME-Type, Länge etc., dass dann an den Client geschickt wird.

Tritt nun allerdings der Fall ein, dass ein Dokument entweder weitere Processing Instructions hat (etwa um erst den Dokumentkopf und dann denn Dokumentenfuß mit XSLT zu formatieren) oder dass es sich um eine XSP Seite handelt, dann wird der Schritt 6 (Reply) erst einmal übergangen und Schritt 7 (Loader) wird aktuell.

7. Loader

In beiden eben genannten Fällen tritt der Loader in Kraft. Dieser lädt Dokumente mit zusätzlichen Processing Instructions, übergibt diese wieder an den Producer und das DOM kann bei einem weiteren Durchlauf durch Cocoon erneut transformiert werden.
Handelt es sich um eine XSP Seite, so werden diese vom Loader kompiliert und in Producer verwandelt. Die XSP Seite steht nun also in der Architektur von Cocoon auf gleicher Ebene wie ein XML Parser, und übergibt genauso wie ein Parser strukturierte Informationen an den Reaktorkern.

Warum Java?

Nach diesem Einblick in die Architektur des Cocoon Servlets stellt sich die Frage, warum sich der Hauptautor Stefano Mazzocchi für Java als Programmiersprache entschieden hat.

Wichtig war für ihn der Portabilitätsaspekt, den Java mit sich bringt und die mächtigen objektorientierten Eigenschaften dieser Sprache. Sicherlich spielte auch der Fakt, dass alle Tools die Cocoon nutzt, ebenfalls in Java geschrieben sind (z.B. der XML Parser Xerces-J).

Neben der Frage ,,Warum Java" soll auch geklärt werden, warum Cocoon als ein Servlet und nicht beispielsweise einfach als mod_cocoon für den Apache httpd direkt vorliegt.

Auch hier war natürlich die Portabilität von Servlets wichtig. Cocoon läuft derzeit (Dezember 2000) auf ca. 60 verschiedenen Umgebungen aus Betriebssystem, Webserver und Servletengine und natürlich ist ein Servlet die naheliegende Lösung, wenn Java als Programmiersprache verwendet wird.

Das Cache System

Wie man sich leicht vorstellen kann, ist der Weg des DOM's durch das Servlet (siehe ,,Das Cocoon Servlet: Abbildung 7") resourcenintensiv und daher wird ein effektiver Cache benötigt.

Wenn ein Request von einem Client Cocoon erreicht, wird geprüft, ob der Output des verlangten XML Dokumentes im Cache liegt. Ist dies der Fall, und die Quelldateien (XML Dokumente, XSL Stylesheets) sind unverändert, so wird die gecachte Datei an den Client geschickt.

Wurde allerdings an einer Quelldatei ein Änderung vorgenommen, wird weiter vorgegangen, als wenn der Output nicht im Cache liegen würde, d.h.: das XML Dokument wird normal verarbeitet, dann an den Client geschickt und schließlich wird es im Cache gespeichert.

Abschließende Informationen

Stärken und Schwächen

Bei den Stärken ist sicherlich die volle Unterstützung von XML und Java als erstes zu nennen. XML und Java werden in Zukunft (nach Meinung des Autors dieses Dokumentes) sicherlich ein zweites Gleis neben HTML im Webserverbereich darstellen.

Auch sollte hier die flexible Architektur von Cocoon genannt werden, die durch ihre Modularität und natürlich auch durch das von der Apache Software Foundation verfolgte Open Source Konzept leicht an eigene Bedürfnisse anzupassen ist.

Wenn man über Schwächen von Cocoon spricht, dann ist dort ein eben besprochener Vorteil auch zugleich ein Nachteil. Denn ein Open Source Produkt hat keine Garantien gegenüber dem Anwender. Das Open Source allerdings keine Gefahr für den professionellen Nutzer sein muß, hat die Foundation u.A. mit dem Apache Webserver gezeigt.

Auch XML ist ein Nachteil, denn es ist in diesem Umfeld eine neue Syntax und es müssen erst einmal vernünftige Tools geschrieben werden, mit denen XML Dokumente erstellt und bearbeitet werden können.

Der wohl größte Nachteil von Cocoon wird die Verwendung von XSL sein. XSL - eine sehr komplexe Sprache die schwer zu verstehen ist. Gerade da XSL von Layoutern genutzt werden soll, wird die Masse der zeitgenössischen ,,Photoshop & Frontpage - Screen Designern" hoffnungslos mit XSL überfordert sein. Denn diese bringen nicht die nötige (Programmier-) Erfahrung mit, die man für das erfolgreiche Verwenden von XSL benötigt.

Cocoon vs. JSP & ASP

Vergleicht man Cocoon mit dynamischen Server Technologien wie Java oder Active Server Pages, die sich am Markt etabliert haben, so fällt auf, dass Cocoon die einzige Software ist, die eine Trennung von Inhalt und Logik vollziehen kann. Dazu soll nur kurz die JSP Funktion out.println() genannt werden, die die einzige Möglichkeit zur Ausgabe von Text darstellt. Mit anderen Worten: sowohl bei JSP als auch bei ASP sind Verarbeitungsketten wie bei Cocoon nicht möglich.

Im Hinblick auf die Architektur kann gesagt werden, dass die von Cocoon durch das modulare Reaktorkonzept flexibler ist, als die von JSP / ASP.

Und soll bei JSP oder ASP mit XML Dokumenten gearbeitet werden, so muss der XML Parser explizit aufgerufen werden.

Cocoon vs. PHP

Eine in diversen Newsgroups und Foren geführte Diskussion um die Vor- und Nachteile von Cocoon und PHP ist ungefähr genauso sinnvoll wie ein Vergleich von C mit Windows: nämlich absolut überflüssig. Denn: PHP ist eine Sprache mit der Daten veröffentlicht werden und Cocoon ist ein Framework, dass einen dabei unterstützt.

Nun könnte man aber die Frage stellen, warum eigentlich Cocoon entwickelt wird. PHP kann auch die Schichten Inhalt, Layout und Logik trennen; hat es doch ein Template-System in den Standard-Bibliotheken, ist objektorientiert etc. Dies ist natürlich auch mit PHP möglich, allerdings existiert eine Software, die eine analoge Funktionsweise wie Cocoon bietet, nicht. Möchte man also Cocoon mit PHP realisieren, so muss man sich an den 200.000 Zeilen Source Code orientieren, die Cocoon mittlerweile bietet.

Leitfaden zum Einsatz

Haben die Stärken von Cocoon überzeugt, muss man sich bewusst sein, dass ein XML / Cocoon Webserver sehr aufwendig in der Erstellung ist.

Beginnt man etwa ein neues Projekt, müssen XSL-fähige Layouter zur Verfügung stehen. Und das dies durchaus zu einem Problem werden kann, wurde in ,,Stärken und Schwächen" beschrieben.

Soll ein bestehendes Projekt in XML / Cocoon realisiert werden, kommt noch dazu, dass der Wandel (das Zerpflücken) von HTML in XML / XSL ebenfalls nicht einfach ist.

Doch für welchen Service Provider im Internet ist es eigentlich sinnvoll, Cocoon zu verwenden? Abbildung 8 soll diesen Entscheidungsprozeß erleichtern:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Wann ist die Verwendung von Cocoon sinnvoll?

Auf der X-Achse ist der Informationsgehalt, also der Umfang der Informationen die der Service für die Clients zur Verfügung stellt, abgetragen. Die Y-Achse beschreibt die Vielfalt der Clients, die auf diese Informationen zugreifen. Im Koordinatenursprung ist die Vielfalt sehr groß - es nutzen also alle erdenklichen Browser Typen von IE über Netscape über WAP (...) bis zu Lynx den Service.

In dem Diagramm wird der Einsatz von Cocoon als sinnvoll beschrieben, wenn die Clients recht unterschiedlich in ihren Darstellungsmöglichkeiten sind (also nicht nur Netscape, Internet Explorer und Opera) und gleichzeitig der Informationsgehalt des Services gehobenen Maßes ist.

Generell kann also gesagt werden, dass je mehr Informationen ein Service bietet und je unterschiedlicher die Clients sind, die darauf zugreifen, desto vorteilhafter ist der Einsatz von Cocoon als Webserver.

Dieser Sachverhalt soll nun an drei Beispielen erklärt werden:

1. Peters Aquarium im Internet

Peter hat seine fünf Zierfische fotografiert und diese mit zugehörigen Namen im Internet verfügbar gemacht.Der Informationsgehalt ist in diesem Fall extrem gering und es ist zu bezweifeln, dass jemals eine Person diese Informationen über ein WAP Handy abrufen wird; die Client -Vielfalt ist also dementsprechend gering ist.

2. FH Wedel

Mit Sicherheit ist die Menge der Informationen, die auf den FH Seiten abrufbar sind, eine Rechtfertigung für den Einsatz von Cocoon. Allerdings ist die Client -Vielfalt doch stark beschränkt, nämlich auf einen großen Anteil von Netscape, ein wenig IE und ganz wenig Lynx. Der Einsatz von Cocoon ist somit optional, und nicht empfehlend.

3. Newsbroker

Ganz heiße Anwärter für den Einsatz von Cocoon sind natürlich News Anbieter wie z.B. www.n24.de und www.ntv.de. Die Menge der angebotenen Informationen ist sehr groß und es greifen die unterschiedlichsten Clients auf die Seiten zu.

Cocoon 2

Cocoon 2 wird gegenüber der aktuellen Version 1.8.1 einige Vorteile haben, die aus der Entfernung von ,,Kinderkrankheiten" resultieren. Diese ,,Kinderkrankheiten" wurden dadurch begünstigt, dass Cocoon sehr viel schneller zu sehr viel mehr gewachsen ist, als es eigentlich vom Autor geplant war.

Deswegen schlichen sich einige Fehler und Restriktionen ein, die nun beim großen Versionssprung von 1.x zu 2.0 eliminiert werden sollen.

Die verbesserte Struktur wird sich im Detail durch weniger Speicherverbrauch, einer erhöhten Geschwindigkeit sowie einer erhöhten Modularität auszeichnen.

Literaturverzeichnis

Apache Software Foundation http://www.apache.org/ Informationen über den Aufbau der Foundation

Apache XML Project http://xml.apache.org/ Das XML Projekt von Apache

Apache Cocoon Project http://xml.apache.org/cocoon/ Informationen über Cocoon: Techniken, Architektur

Java Apache Project http://java.apache.org/faq/fom-serve/cache/236.html Kurzzusammenfassung von Cocoon und dessen Techniken

PHPBuilder.com http://www.phpbuilder.com/columns/bealers20000616.php3?page=2 PHP mit Cocoon verwenden

Alle Links wurden am 11.12.2000 auf ihre Gültigkeit überprüft.

Details

Seiten
13
Jahr
2000
Dateigröße
431 KB
Sprache
Deutsch
Katalognummer
v98941
Institution / Hochschule
Fachhochschule Wedel
Note
Schlagworte
Apache Cocoon Projekt Seminar Fachbereich Wirtschaftsinformatik

Teilen

Zurück

Titel: Das Apache Cocoon Projekt