Abbildung 8: Wann ist die Verwendung von Cocoon sinnvoll?
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.
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.
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.
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 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:
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.