I hope the first part of the Architecture Guide made things clear for you (at least a bit). This part will describe you a single request to your web application. Every elementary building block of WebDeco will be mentioned here. Part 3 will describe them more in detail.
For clarity I provide this action state diagram. Description follows.
The use forces its web browser to do a request to the url of one of ours use case controllers (e.g. http://www.example.com/blog/post/123). The request enters the Servlet Container (e.g. Tomcat) at its border and gets directed into the Servlet Filter chain.
WebDeco, which is build on top of such a ServletFilter, is waken up by the incoming request. It wraps the incoming Servlet Request and Response (a common practice to capture the response of a request inside a Servlet Filter) and sends the wrapping instances down the Servlet Filter chain.
At the end of the Servlet Filter chain stands the use case controller (The thing responsible for requests to http://www.example.com/blog/post). It handles the request bravely and writes it output to the wrapped Servlet Response.
Since what has gone down will come back up (at least in a Servlet Filter chain) the request passes all Servlet Filters in the opposite direction it came in until it meets the WebDeco Servlet Filter again. Here the real work (for WebDeco) begins.
WebDeco has a list of Matchers which task is to determine which Decoration is to be used for a particular request. The list is iterated over in the order of configuration (First configured, first vote) until a Decoration is returned.
The Decoration contains a list of SubContentTasks. Every task gets executed by passing a copy of the current state of the Servlet Request and Response to it. Their response is aggregated. After the last task has returned both the use case response and the sub content is passed to the Template assocated to the decoration. During the rendering of the final page the Template can use all the delivered content.
The final rendered content is passed back up the Servlet Filter chain until it meets the border of the Servlet container and goes back to the user's web browser.
All this is a bit simplified for better understanding. There are also ContentExtractors registered for particular mime types. Their job is to extract the usable content from the result. This makes it possible to let the use case return valid XHTML will all resources included not just snippets. The ContentExtractor registed for XHTML will extract the important content part and collect some meta data like resources from the XHTML page.