Cocoon Documentation
The Cocoon Project will evidence its new course with a new logo that was designed by Cocoon's creator Stefano Mazzocchi. Here it is:
The Cocoon Project has gone a long way since its creation on January 1999. It started as a simple servlet for static XSL styling and became more and more powerful as new features were added. Unfortunately, design decisions made early in the project influenced its evolution. Today, some of those constraints that shaped the project were modified as XML standards have evolved and solidified. For this reason, those design decisions need to be reconsidered under this new light.
While Cocoon started as a small step in the direction of a new web publishing idea based on better design patterns and reviewed estimations of management issues, the technology used was not mature enough for tools to emerge. Today, most web engineers consider XML as the key for an improved web model and web site managers see XML as a way to reduce costs and ease production.
In an era where services rather than software will be key for economic success, a better and less expensive model for web publishing will be a winner, especially if based on open standards.
Web serving environments must be fast and scalable to be useful. Cocoon1 was born as a "proof of concept" rather than production software and had significant design restrictions, based mainly on the availability of freely redistributable tools. Other issues were lack of detailed knowledge on the APIs available as well as underestimation of the project success, being created as a way to learn XSL rather than a full publishing system capable of taking care of all XML web publishing needs.
For the above reasons, Cocoon 1 was based on the DOM level 1 API which is a passive API and was intended mainly for client side operation. This is mainly due to the fact that most DOM implementations require the document to reside in memory. While this is practical for small documents and thus good for the "proof of concept" stage, it is now considered a main design constraint for Cocoon scalability.
Since the goal of Cocoon 2 is the ability to process simultaneously multiple 100Mb documents in JVM with a few Mbs of heap size, careful memory use and tuning of internal components is a key issue. To reach this goal, an improved API model was needed. This is now identified in the SAX API which is, unlike DOM, event based (so active, in the sense that its design is based on the inversion of control principle).
The event model allows document generators to trigger events that get handled by the various processing stages and finally get serialized onto the response stream. This has a significant impact on both performance (effective and user perceived) and memory needs:
The above points alone would be enough for the Cocoon 2 paradigm shift, even if this event based model impacts not only the general architecture of the publishing system but also its internal processing components such as XSLT processing and PDF formatting. These components will require substantial work and maybe design reconsideration to be able to follow a pure event-based model. The Cocoon Project will work closely with the other component projects to be able to influence their operation in this direction.
Another design choice that should be revised is the reactor pattern that was introduced to allow components to be connected in more flexible way. In fact, by contrast to the fixed pipe model used up to Cocoon 1.3.1, the reactor approach allows components to be dynamically connected, depending on reaction instructions introduced inside the documents.
While this at first seemed a very advanced and highly appealing model, it turned out to be a very dangerous approach. The first concern is mainly technical: porting the reactor pattern under an event-based model requires limitations and tradeoffs since the generated events must be cached until a reaction instruction is encountered.
But even if the technical difficulties could be solved, a key limitation remains: there is no single point of management.
The web was created to reduce information management costs by distributing them back on information owners. While this model is great for user communities (scientists, students, employees, or people in general) each of them managing small amount of personal information, it becomes impractical for highly centralized information systems where distributed management is simply not practical.
While in the HTML web model the page format and URL names where the only necessary contracts between individuals to create a world wide web, in more structured information systems the number of contracts increases by a significant factor due to the need of coherence between the hosted information: common style, common design issues, common languages, server side logic integration, data validation, etc...
It is only under this light that XML and its web model reveal their power: the HTML web model had too little in the way of contracts to be able to develop a structured and more coherent distributed information system, a reason that is mainly imposed by the lack of good and algorithmically certain information indexing and knowledge seeking systems. Lacks that tend to degrade the quality of the truly distributed web in favor of more structured web sites (that based their improved site structure on internal contracts).
The simplification and engineering of web site management is considered one of the most important Cocoon 2 goals. This is done mainly by technologically imposing a reduced number of contracts and placing them in a hierarchical shape, suitable for replacing current high-structure web site management models.
The model that Cocoon 2 adopts is the "pyramid model of web contracts" which is outlined in the picture below
and is composed by four different working contexts (the rectangles)
and five contracts (the lines)
Note that there is no logic - style contract. Cocoon 2 aims to provide both software and guidelines to allow you to remove such a contract.
The above model can be applied only if the different contexts never overlap, otherwise there is no chance of having a single management point. For example, if the W3C-recommended method to link stylesheets to XML documents is used, the content and style contexts overlap and it's impossible to change the styling behavior of the document without changing it. The same is true for the processing instructions used by the Cocoon 1 reactor to drive the page processing: each stage specifies the next stage to determine the result, thus increasing management and debugging complexity. Another overlapping in context contracts is the need for URL-encoded parameters to drive the page output. These overlaps break the pyramid model and increase the management costs.
In Cocoon 2, the reactor pattern will be abandoned in favor of a pipeline mapping technique. This is based on the fact that the number of different contracts is limited even for big sites and grows with a rate that is normally much less than its size.
Also, for performance reasons, Cocoon 2 will try to compile everything that is possibly compilable (pages/XSP into generators, stylesheets into transformers, etc...) so, in this new model, the processing chain that generates the page contains (in a direct executable form) all the information/logic that handles the requested resource to generate its response.
This means that instead of using event-driven request-time DTD interpretation (done in all Cocoon 1 processors), these will be either compiled into transformers directly (XSLT stylesheet compilation) or compiled into generators using logicsheets and XSP which will remove totally the need for request-time interpretation solutions like DCP that will be removed.
Some of these features are already present in latest Cocoon 1.x releases but the Cocoon 2 architecture will make them central to its new core.
In Cocoon 2 terminology, a sitemap is the collection of pipeline matching informations that allow the Cocoon engine to associate the requested URI to the proper response-producing pipeline.
The sitemap physically represents the central repository for web site administration, where the URI space and its handling is maintained.
Please, refer to the Cocoon 2 CVS module for more information on this.
The cache system in Cocoon 1 will be ported with very little design changes since it's very flexible and was not polluted by early design constraints since it appeared in later versions. The issue regarding static file caching that, no matter what, will always be slower than direct web server caching, means that Cocoon 2 will be as proxy friendly as possible.
To be able to put most of the static part of the job back on the web server (where it belongs), Cocoon 2 will greatly improve its command line operation, allowing the creation of site makefiles that will automatically scan the web site and the source documents and will provide a way to regenerate the static part of a web site (images and tables included!) based on the same XML model used in the dynamic operation version.
Cocoon 2 will, in fact, be the integration between Cocoon 1 and Stylebook.
It will be up to the web server administrator to use static regeneration capabilities on a time basis, manually or triggered by some particular event (e.g. database update signal) since Cocoon 2 will only provide servlet and command line capabilities. The nice integration is based on the fact that there will be no behavioral difference if the files are dynamically generated in Cocoon 2 via the servlet operation and cached internally or pre-generated and served directly by the web server, as long as URI contracts are kept the same by the system administrator (via URL-rewriting or aliasing)
Also, it will be possible to avoid on-the-fly page and stylesheet compilation (which makes debugging harder) with command line pre-compilation hooks that will work like normal compilers from a developer's point of view.
Cocoon 2 development has already started, but should be considered "alpha quality" - i.e. certainly not ready for use on public websites! If you dare, you might take a look at it on the xml-cocoon2 CVS branch in the Cocoon CVS module. If you are not a CVS expert, this means typing:
cvs -d :pserver:anoncvs@xml.apache.org:/home/cvspublic login Password: anoncvs cvs -d :pserver:anoncvs@xml.apache.org:/home/cvspublic checkout -r xml-cocoon2 xml-cocoon
For more information on CVS access, refer to the CVS docs on this web site.
Copyright © 1999-2001 The Apache Software Foundation.
All rights reserved.