cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cocoon Wiki] Update of "Cocoon 3 Profiling" by StephanTeuschl
Date Tue, 28 Apr 2009 17:36:12 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cocoon Wiki" for change notification.

The following page has been changed by StephanTeuschl:
http://wiki.apache.org/cocoon/Cocoon_3_Profiling

------------------------------------------------------------------------------
  
  ==== Cocoon Sequence Diagram ====
  
+ attachment:seqdia_full_small.png
+ 
+ There are three big parts of the cocoon workflow: the servlet, the sitemap, and the pipeline.
In the following, these parts will be showed - and described - to you, splitting the big diagram
in logical parts where the interfaces are. In reality, those work together rather smoothly,
so it is just about abstraction and a simpler view of the big picture that they are splitted
in this view.
+ 
+ attachment:seqdia_part1.png
+ 
+ First, there is the servlet-part. It contains the HTTPRequest, the ServletContainer, the
DispatcherService and the XMLSitemapService. The structure is rather straightforward: The
HTTPRequest recieves a request (a mountpath like (/foo) and then forwards it to the ServletContainer.
The ServletContainer knows of only one service, the DispatcherService, so it forwards the
request to the DispatcherService. The DispatcherService then chooses the fitting Servlet for
this request based on the mountpath and forwards the service-request to the corresponding
XMLSiteMapSerivce, which is the beginning of our second block. 
+ 
+ attachment:seqdia_part2.png
+ 
+ Our XMLSiteMapService first initializes itself by parsing its own Sitemap (using a SAXParser)
and, based on that, builds its own structure in java. It then invokes the Invocation, which
basically belongs to the XMLSiteMapService 'block' but does a bunch of work, so its gotten
an extra part.
+ The Invocation recieved the structure of the SiteMap by the XMLSiteMapService, and so knows
what kind of pipeline to build (basically, it does nothing more and nothing less). As you
can see in the illustration, it first installs a pipeline, thus creating the process and then
creating the single components and adding it to the pipeline. When the installing is done,
the Invocation executes, thus starting the setup of the pipeline and bringing us to our third
block. After the whole third block has been processed, the XMLSiteMapService recieves the
OutputString as a result and writes it to the HTTPResponse, completing the request.
+ 
+ attachment:seqdia_part3.png
+ 
+ The third block is the heart and soul of cocoon. All the prerequisites have been fulfilled
and the pipeline has been set up. It can now start its work and does so by calling a setup
method of its components (which have been added by the Invocation). During the setup phase,
a component can do specific things that have to be set up before the pipeline is executed,
these are certain parameters, which can be set before, and the method setConsumer, which 'sticks'
the pipeline-components together. 
+ 
+ The pipeline consists of PipelineComponents, like the Generator and the Serializer. There
are many different Implementations of these, based on your needs. The PipelineComponents can
implement a Producer and/or Consumer, meaning that they either consume and/or produce data.
They can also be Starters or Finishers. Every pipeline needs a Starter and a Finisher in order
to work properly. The Starter is normally a Producer, the Finisher a Consumer, all the other
parts in the middle consist of Components that are Producers and Consumers. The example in
the illustration shows such a case, where the Transformer is a Consumer of the Generator,
but a Producer for the Serializer. It is important to understand that a pipeline can be of
virtually any length, so long as every Consumer is compatible to its preceding Producer.
+ 
+ The first part of the pipeline, the Starter, "mounts" the input of the next component to
its own output. The next part does the same, and so on. Every component knows what to do on
its own, so the Finisher (the last part of the pipeline, which produces the output) wouldn't
try to set another consumer. After this is done, the pipeline set the OutputStream on the
Finisher and then executes, starting the processing. 
+ 
+ The pipeline just has to start the Starter, which, after dealing with his work, will then
forward the data to its consumer, and so on. Afterwards, the pipeline gives every component
a chance to finish their processing. Because of the nature of java and the OutputStream (the
actual object just gets passed around until the end), at the end the Finisher will have filled
the object with the output and the XMLSiteMapService can now write the output to the HTTPResponse
object and fulfill the request (as seen in a strongly simplified way on the next illustration).
+ 
+ attachment:seqdia_part4.png
+ 
  ==== Cocoon Sample ====
  
  ----

Mime
View raw message