[FrontPage] [TitleIndex] [WordIndex] 

OGCFrontController

Contents

  1. Requirements
    1. Multipart
  2. Wishlist
  3. Current status
  4. Roadmap
  5. Design decisions / implementation
    1. Frontcontroller/service interaction
    2. Architecture
    3. Dispatching algorithm
    4. Configuration
    5. HTTPRequestWrapper/HTTPResponseWrapper
    6. Handling of Credentials

Status: alpha (2008/09/15)

Design and implementation documentation for the deegree3 OGCFrontController for deegree3/OGCWebServices.

1. Requirements

Problem: How do we determine the responsible subcontroller?

1.1. Multipart

Some OGC specifications require MIME multipart requests and/or responses. To process these requests or generate these responses a subcontoller needs access to the HTTP headers. Since there are different subtypes of the Multipart MIME-type (mixed, Related, etc.) a general support for multiparts in the HttpServlet{Request,Response}Wrapper may not be feasible. A generic wrapper or utility class that can be extended would still be useful, though, since they all share the same boundary encoding (a randomized token to separate each part, content-length based encoding is not possible).

MIME (incl. Multipart) Multipart/Related (required for WCS 1.1)

2. Wishlist

3. Current status

This subsystem is in alpha status.

4. Roadmap

5. Design decisions / implementation

5.1. Frontcontroller/service interaction

In deegree 3, we will follow a separation of the service functionality and the processing of http requests.

Responsibilites of the frontcontroller (http layer) component:

Problem: How do we determine the responsible subcontroller?

Possible solutions:

1. For an incoming request, each subcontroller is queried if it is responsible for handling the request.

2. The frontcontroller determines the responsible subcontroller using a fixed strategy. KVP: service-attribute, XML (OGC): namespace of root element, XML (SOAP): namespace of child element of SOAP body.

The latter option is quite well defined for OGC services. However, it restricts the frontcontroller to a fixed strategy for determining the responsible service. In order to cope with special determination strategies for non OGC-services, we suggest that such services should implement their own servlet.

To emphasize that the generic frontcontroller will only work for OGC-style communications, the frontcontroller will be named OGCFrontController.

5.2. Architecture

It seems that the frontcontroller has to implement a specific strategy for determing the responsible service for each protocol supported by OGC-webservices:

In order to apply the corresponding strategy, the frontcontroller has to determine the protocol-type first. To avoid code duplication and to ease implementing of service subcontrollers, it seems appropriate to define protocol specific methods in the subcontroller interface: 

public interface Subcontroller {
    /**
     * Called by the {@link OGCFrontController} to allow this <code>Subcontroller</code> to handle a KVP request.
     *
     * @param request
     *            KVP request to the corresponding OGC service
     * @param response
     *            response that is sent to the client
     * @throws ServletException
     * @throws IOException
     */
    public void doKVP( HttpServletRequest request, HttpServletResponse response )
                            throws ServletException, IOException;
    /**
     * Called by the {@link OGCFrontController} to allow this <code>Subcontroller</code> to handle an XML request.
     *
     * @param request
     *            XML request to the corresponding OGC service
     * @param response
     *            response that is sent to the client
     * @throws ServletException
     * @throws IOException
     */
    public void doXML( HttpServletRequest request, HttpServletResponse response )
                            throws ServletException, IOException;
    /**
     * Called by the {@link OGCFrontController} to allow this <code>Subcontroller</code> to handle a SOAP request.
     *
     * @param request
     *            SOAP request to the corresponding OGC service
     * @param response
     *            response that is sent to the client
     * @throws ServletException
     * @throws IOException
     */
    public void doSOAP( HttpServletRequest request, HttpServletResponse response )
                            throws ServletException, IOException;
}

If the subcontroller needs to distinguish between POST and GET requests, it can do so by calling #getMethod() on the request parameter.

Basic architectural layout:

Following UML diagram shows the structural layout of the FrontController and it's sub controllers.

frontcontroller.jpg

5.3. Dispatching algorithm

The dispatching algorithm is shown in the following activity diagram.

dispatching_strategy.png

Basic structure of package org.deegree.services:

5.4. Configuration

The services as well as the FrontController (and it's subcontrollers) need to be configured. To realize this, we would like to propose, the separatation between the frontcontroller configuration and the service (not it's controller) configuration. The following schematic overview clarifies our design.

config.jpg

5.5. HTTPRequestWrapper/HTTPResponseWrapper

The servlet requests and response objects will be wrapped to allow some deegree extensions like buffering. See deegree3/HTTPRequestResponseWrapper for a discussion on the requirements and implementation.

5.6. Handling of Credentials

deegree is able to handle different kinds of user credentials (e.g. username/password) in order to facilitate authentication against secured services. Since requirements to credential management may change over time (e.g. by including Webservice Security mechanisms, Shibboleth, OpenID, et.al.), the deegree-internal mechanisms do not rely on the specifics of the security mechanisms. Credentials will be extracted from a request by the OGCFrontController and stored inside a org.deegree.services.controller.RequestContext object. RequestContext is a Java Bean providing getters and setters for username, password, tokenID, and requestedBaseURL. OGCFrontController initializes a RequestContext as an java.lang.InheritedThreadLocal instance, thus providing thread-based access to credentials.

Each instance interested in those information can obtain the RequestContext from the OGCFrontController by accessing the getContext() method.

The relevant classes and their interdependencies are illustrated in this figure.

RequestContext.png

Access and initialization of the RequestContext object is illustrated using the deegree3/ProcessingService as an example.

ThradLocalAccess.png

CategoryDeegree3

2018-04-20 12:05