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)
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.