[Cocoon Wiki] Update of "Cocoon 3 Profiling" by StephanTeuschl

[Apache Wiki <wi...@apache.org>]

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 ====
  
  ----