Architecture

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

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

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.