cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From da...@cocoon.zones.apache.org
Subject [DAISY] Updated: Overview
Date Fri, 14 Mar 2008 16:37:16 GMT
A document has been updated:

http://cocoon.zones.apache.org/daisy/documentation/1412.html

Document ID: 1412
Branch: main
Language: default
Name: Overview (unchanged)
Document Type: Cocoon Document (unchanged)
Updated on: 3/14/08 4:37:01 PM
Updated by: Reinhard Pötz

A new version has been created, state: publish

Parts
=====

Content
-------
This part has been updated.
Mime type: text/xml (unchanged)
File name:  (unchanged)
Size: 7197 bytes (previous version: 6682 bytes)
Content diff:
(11 equal lines skipped)
    
    <h1>Introduction to architecture</h1>
    
--- <p>Servlet Services Framework (SSF) is built around few concepts:</p>
+++ <p>Servlet Services Framework (SSF) is built around a few concepts:</p>
    
    <ul>
    <li>request dispatching</li>
    <li>standarized communication between servlets</li>
--- <li>Object Oriented techniques:</li>
+++ <li>object-oriented techniques</li>
    <ul>
    <li>abstraction/composition</li>
    <li>inheritance</li>
(3 equal lines skipped)
    
    </ul>
    
--- <p>that we will discuss in-detail later.</p>
--- 
    <h2>Request dispatching</h2>
    
--- <p>The most basic functionality is request dispatching handled by
--- <a href="http://cocoon.apache.org/subprojects/servlet-service/1.0/servlet-service-impl/1.0/apidocs/org/apache/cocoon/servletservice/DispatcherServlet.html"><tt>DispatcherServlet</tt></a>
--- which is sort of a very lightweight servlet container. Each servlet is
--- registered to the DispatcherServlet with property <tt>mount-path</tt>. This
--- property defines request path which can be used to access particular servlet.
--- When request is being handled by the DispatcherServlet it scans list of
--- registered servlets, checking if mount-path property of any servlet matches
--- request's path. If such servlet is found DispatcherServlet dispatches request
--- with<strong> fragment matching mount-path omitted</strong>.</p>
+++ <p>The most basic functionality is request dispatching that is handled by the
+++ <a href="http://cocoon.apache.org/subprojects/servlet-service/1.0/servlet-service-impl/1.0/apidocs/org/apache/cocoon/servletservice/DispatcherServlet.html"><tt>DispatcherServlet</tt></a>.
+++ The dispatcher servlet is the entry point to all servlets that are managed by
+++ the servlet-service framework.</p>
    
--- <p>Following diagram illustrates the process.</p>
+++ <p>Each servlet is registered by setting the property <tt>mount-path</tt>.
This
+++ property defines the request path which can be used to access a particular
+++ servlet. When a request is being handled by the DispatcherServlet, it scans all
+++ the registered servlets and checks if  the <tt>mount-path</tt> property of
any
+++ servlet matches the request path. If such a servlet is found, the
+++ <tt>DispatcherServlet </tt>dispatches the request. For that request, the
+++ matching mount-path is truncated from the request URI.</p>
    
+++ <p>The following diagram illustrates the process.</p>
+++ 
    <p align="center"><img src="daisy:1427"/></p>
    
--- <p>The fact that mount-path is being omitted frees servlet implementator from
--- bothering about it at development stage and makes it easy to configure
--- mount-path property at deployment stage.</p>
+++ <p>The fact that the <tt>mount-path</tt> is being omitted frees servlet
+++ implementator from bothering about it at development stage. It also enables the
+++ configuration of the <tt>mount-path</tt> at deployment time.</p>
    
    <h2>Connecting servlets</h2>
    
--- <p>Servlet Service Framework establishes standarized way for communication
--- between servlets that exploits standards like Servlet API and HTTP. In order to
--- communicate with other servlet you just need to make a
--- <strong>connection</strong> to it and then just create a request that will
look
--- the same as it would come from browser. The requested servlet doesn't have to
--- bother if request comes from another servlet or browser because it's totally
--- transparent to it.</p>
+++ <p>The Servlet Service Framework establishes a standarized way for the
+++ communication between components (in this case servlets) that follow standards
+++ like Servlet API and HTTP. In order to communicate with other servlets you just
+++ need to make a <strong>connection</strong> to it and then create a request.
For
+++ the called servlet there is no difference if the request comes from another
+++ servlet or is an external request.</p>
    
    <p align="center"><img src="daisy:1428"/></p>
    
--- <p>You should notice two things while look at the diagram:</p>
+++ <p>You should notice two things while looking at the diagram:</p>
    
    <ul>
--- <li>DispatcherServlet is <strong>not</strong> involved in communication
between
--- connected servlets (it is performed using
+++ <li>The <tt>DispatcherServlet </tt>is <strong>not</strong>
involved in
+++ communication between connected servlets (it is performed using
    <a href="http://cocoon.apache.org/subprojects/servlet-service/1.0/servlet-service-impl/1.0/apidocs/org/apache/cocoon/servletservice/ServletConnection.html">ServletConnection</a>
    object). It also means that <tt>mount-path</tt> property has no application
    here.</li>
--- <li>Request's path is passed untouched.</li>
+++ <li>The Request path is passed unchanged.</li>
    </ul>
    
    <h2>Inheritance and polymorphism</h2>
    
--- <p>Servlet can act as component thus it can extend other one and override it's
--- resource (request) handling. Nothing wrong is here, it's really about overriding
--- resource handling not methods of class implementing servlet interface. If it was
--- normal inheritance and polymorhism of classes then there would be no room for
--- innovation, Java has it all since 1.0 version.<br/>
--- Servlet Service Framework cares only about <strong>resources</strong>
--- (identified by URLs) particular servlet can handle and not about implementation
--- of servlet class. Basically, it means that all widely known concepts of Object
--- Oriented Programming are applied to resources. In order to help you understand
--- how various notions map from OOP to Resource Oriented Architecture (ROA) take a
+++ <p>A Servlet can act as a component thus it can extend another one and override
+++ its resource (request) handling. The idea is that one servlet can override the
+++ resource handling of another one. To make it clear, inheritance in the context
+++ of the Servlet-Service Framework does not mean overriding methods of the Java
+++ servlet class. (Of course that's still possible but a concept that is already
+++ covered by Java object-orientation.)<br/>
+++ Basically, it means that all widely known concepts of Object-Oriented
+++ Programming are applied to resources. In order to help you understand how
+++ various notions map from OOP to Resource Oriented Architecture (ROA), take a
    look at following table:</p>
    
    <table>
(33 equal lines skipped)
    </td>
    </tr>
    <tr>
--- <td><tt>classB</tt>
--- <p>extends <tt>classA</tt></p>
+++ <td>
+++ <p><tt>classB</tt> extends <tt>classA</tt></p>
    </td>
--- <td><tt>servletB</tt>
--- <p>connects to <tt>servletA</tt> using connection named <tt>super</tt></p>
+++ <td>
+++ <p><tt>servletB </tt>connects to <tt>servletA</tt> using
the connection named
+++ <tt>super</tt></p>
    </td>
    <td>
    <p>Connection named "super" is reserved for inheritance implementation</p>
    </td>
    </tr>
    <tr>
--- <td valign="top"><tt>classA</tt>
--- <p>implements <tt>interfaceB</tt></p>
+++ <td valign="top">
+++ <p><tt>classA </tt>implements <tt>interfaceB</tt></p>
    </td>
    <td valign="top">
    <p>N/A</p>
(9 equal lines skipped)
    </td>
    </tr>
    <tr>
--- <td valign="top"><tt>classB</tt>
--- <p>overrides method <tt>getFooBar()</tt> implemented in <tt>classA</tt></p>
+++ <td valign="top">
+++ <p><tt>classB </tt>overrides method <tt>getFooBar()</tt>
implemented in
+++ <tt>classA</tt></p>
    </td>
--- <td valign="top"><tt>servletB</tt>
--- <p>implements handling of <tt>/fooBar</tt> resource.</p>
+++ <td valign="top">
+++ <p><tt>servletB </tt>implements handling of <tt>/fooBar</tt>
resource.</p>
    </td>
    <td valign="top"/>
    </tr>
    </tbody>
    </table>
    
--- <p>Being aware of mapping between OOP and ROA let's see how SSF implementing
--- these ideas looks in action.</p>
+++ <h3>Example</h3>
    
+++ <p>Now let's have a look at a concrete example how (external) requests are
+++ handled by the Servlet-Service Framework: This diagram describes in the first
+++ part how the servlets are connected to each other. Servlet A is the super
+++ servlet of Servlet B.  This means that if Servlet B can't handle a request, it
+++ is forwarded to Servlet A.</p>
+++ 
+++ <p>The second part of this diagram explains this process in more detail. Servlet
+++ B doesn't provide the requested resource and returns a 404 (NOT_FOUND) HTTP
+++ status code.</p>
+++ 
+++ <p>The third sequence shows that because Servlet B doesn't contain the resource,
+++ the super servlet (Servlet A) is being asked for it. Servlet A can handle the
+++ request and returns a response with the resource and a 200 HTTP status code.</p>
+++ 
    <p align="center"><img src="daisy:1429"/></p>
    
    <p>Now few remarks are needed:</p>
    
    <ul>
--- <li>Diagram above shows the situation when original request comes from browser
--- (or other external program) and is handled by DispatcherServlet first. If
--- request is being made by servlet using connection it would look similar to this
--- one. It turns out that connection object is not a trivial object linking two
--- servlets because it's connection's job to make all this magic of dispatching
--- request to the super servlet if original one does not handle requested resource.
--- </li>
+++ <li>If the request is being made by a servlet using connection it would look
+++ similar to this one. It turns out that connection object is not a trivial object
+++ linking two servlets because it's the connection's task to make all this magic
+++ of dispatching request to the super servlet if original one does not handle
+++ requested resource.</li>
    <li>Servlet B returns 404 status code as response and this simply means that
    Servlet B does not override handling of /foo/bar resource from servlet A. If
    servlet B had returned 200 status code, then DispatcherServlet would not make a
(8 equal lines skipped)


Mime
View raw message