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)
