Introduction
In this section we will explain in details how the GeoServer Servlets work. Each GeoServer service is provided by a specific Servlet that intercepts the client requests and builds up the response in accordance to the GeoServer configuration.
Design
The attached image represents a detailed Class-Diagram of the WCS GeoServeer Service. We will use this diagram as an example to deeply explain the GeoServer Serlvet workflow and the role of the various objects involved in the process.
The main WCS Servlet class is represented by the object org.vfny.geoserver.wcs.servlets.WcsDispatcher. As you can see from the diagram it inherits from the base class org.vfny.geoserver.servlets.Dispatcher which extends the class javax.servlet.http.HttpServlet. Notice that the packages structure tends to separate the various GeoServer Services classes therefore you will find all the WCS Service classes under the package org.vfny.geoserver.wcs and all the WCS Servlet classes under the package org.vfny.geoserver.wcs.servlets.
In the main web-app configuration file web.xml you can find the WCS Servlet definition:
<servlet>
<servlet-name>WcsDispatcher</servlet-name>
<servlet-class>org.vfny.geoserver.wcs.servlets.WcsDispatcher</servlet-class>
</servlet>
The Dispatcher class is the base of each GeoServer Service dispatcher. A dispatcher handles the client requests and redirects the latter to another specific Servlet by instantiating an object called dispatched. Notice that the client can also directly call the right Servlet without passing through the dispatcher by specifing it in the URL path. In the diagram the dependancy +dispatched shows how the WCS Dispatcher invokes one of the WCS Response Servlets.
For the WCS Service we have three Response Servlets:
- org.vfny.geoserver.wcs.servlets.Coverage : this Servlet handles the GetCoverage Request and serves the right Response basing its decision on the requested format for the coverage to retrieve.
- org.vfny.geoserver.wcs.servlets.Capabilities : this Servlet handles the GetCapabilities Request.
- org.vfny.geoserver.wcs.servlets.Describe : this Servlet handles the DescribeCoverage Request.
Each Response Servlet inherits from the base class org.vfny.geoserver.wcs.servlets.WCService which extends the abstract class org.vfny.geoserver.servlets.AbstractService. Those Servlets catch an org.vfny.geoserver.wcs.requests.WCSRequest object extension of the abstract class org.vfny.geoserver.Request class. Each request object is then passed to an istance of a specific response object used by the Servlets to build up the response output. In the diagram the relation +request between responses and requests underlines this kind of dependency.
All the response objects are implementations of the interface org.vfny.geoserver.Response. Each response instance builds the response output using the GeoServer data configuration (see the GeoServer Configuration design for more details) and then sends the result to the OutputStream through the writeTo() method.
Lets take a look at the org.vfny.geoserver.wcs.responses.CoverageResponse object. This is a particular case of a response object. In such case the output depends on the requested output-format so the response can be built in different ways. To achieve this objective the CoverageResponse object creates an instance of a response delegate through the org.vfny.geoserver.wcs.responses.CoverageResponseDelegateFactory class. The goal of this class is to retrieve and instantiate the right object for the requested output-format. In the diagram the relation +delegate between CoverageResponse and CoverageResponseDelegate represents this kind of dependency.
Every class belonging to the org.vfny.geoserver.wcs.responses.coverage package implements the interface org.vfny.geoserver.wcs.responses.CoverageResponseDelegate so a developer can add a delegate for any output-format simply by creating a new implementation of the latter interface.
