Overview

This is the implementation of the Servlet-Service framework. It doesn't have any dependencies on Cocoon core and can be used to introduce standardized communication between any servlets.

Introduction to architecture

Servlet Services Framework (SSF) is built around a few concepts:

• request dispatching
• standarized communication between servlets
• object-oriented techniques
• abstraction/composition
• inheritance
• polymporhism
• encapsulation

Servlet Management

The current implementation of the Servlet-Service-Framework uses Spring to manage servlets. All those servlets are ordinary Spring beans that implement the javax.servlet.Servlet interface. It's important to note that these servlets are not available from within a the servlet container (Jetty, Tomcat, etc.). The connection to the outside world is the DispatcherServlet that delegates requests to one of the mounted servlets (for details see the next section). This is the only servlet that is exposed in the web.xml and can directly be accessed using an HTTP call to the servlet container.

Request dispatching

The most basic functionality is request dispatching that is handled by the DispatcherServlet. Each servlet is registered by setting the property mount-path. 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 mount-path property of any servlet matches the request path. If such a servlet is found, the DispatcherServlet dispatches the request. For that request, the matching mount-path is truncated from the request URI.The following diagram illustrates the process.The fact that the mount-path is being omitted frees servlet implementator from bothering about it at development stage. It also enables the configuration of the mount-path at deployment time.

Connecting servlets

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 connection 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.

You should notice two things while looking at the diagram:

• The DispatcherServlet is not involved in communication between connected servlets (it is performed using ServletConnection object). It also means that mount-path property has no application here.
• The Request path is passed unchanged.

Inheritance and polymorphism

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.)

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:

Object Oriented Programming	Resource Oriented Architecture	Remarks
calling getFooBar() method	requesting /fooBar resource	for making request HTTP GET method is used
calling getFooBar(value1, value2) method	requesting /fooBar?param1=value1&param2=value2 resource	if one of parameters contains binary data, then POST (or PUT but we won't get into details too much here) request is being made
classB extends classA	servletB connects to servletA using the connection named super	Connection named "super" is reserved for inheritance implementation
classA implements interfaceB	N/A	Servlet Service Framework does no have any equivalent for strong typing known from programming languages so it cannot check if equivalent of interface is being implemented. The interface concept known from OOP maps best to just an abstract contract. It's a servletA's contract to handle various resources but check if it really does can be made at runtime only. It's similar situation to scripting languages like Javascript.
classB overrides method getFooBar() implemented in classA	servletB implements handling of /fooBar resource.

Example

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.

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.

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.

Now few remarks are needed:

• 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.
• 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 second request to servlet A and would finish with response got from Servlet B.
• Mulitple levels of inheritance are possible (servlet A could connect to another servlet with connection named "super").