ServerDispatchOperations: Difference between revisions

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
No edit summary
Line 1: Line 1:
Now that Hyrax has been released it has become clear that we need to publish a paper that describes the correct behavior of an OPENDAP server. This should include the details of:


* '''Dispatch''' - How the various request URL's get assessed and which responses are sent.
* '''Errors''' - Which errors should be associated with which dispatch paths.


=URL Dispatch Operations=
OPeNDAP servers provide an interface through which clients can access data held on the server. The server can provide sub-setting and, in some cases, additional preprocessing operations on the requested data. The protocol through which the OPeNDAP server s provide these data services is called the Data Access Protocol (DAP). The current version of the DAP is version 2, so The DAP is usually specified as DAP2.
 
OPeNDAP servers provide an interface through which clients can access data held on there server. The server can provide sub-setting and, in some cases, additional preprocessing operations on the requested data. The protocol through which the OPeNDAP server s provide these data services is called the Data Access Protocol (DAP). The current version of the DAP is version 2, so The DAP is usually specified as DAP2.


In addition to DAP2 responses, most OPeNDAP servers provide a number of additional services such as:
In addition to DAP2 responses, most OPeNDAP servers provide a number of additional services such as:
Line 15: Line 10:
* THREDDS catalog views of the data system.
* THREDDS catalog views of the data system.


Dispatch is the process in which:
* An OPeNDAP server receives a request (that comes in the form of a URL).
* The server evaluates the URL to determine what type of response the URL indicates the server should provide.
* The server provides the requested response if possible, or returns the appropriate error (in the appropriate format) if the request cannot be fulfilled.


==Dispatch Operations In Hyrax==
Request dispatch is the process in through which an OPeNDAP Server determines what actual piece of code is going to responsed to a given incoming request. In a perfect world, the identified piece of software will generate the type of response the client intended to invoke on the server, or at worst a sensible error response such as a web page or a serialized DAP2 error object.
 
 
 
 
=[[Hyrax]] Dispatch=
 
The Hyrax front end (OLFS) handles each incoming request by offering the request to a series of DispatchHandlers. Each DispatchHandler is asked if it can handle the request. The first DispatchHandler to say that it can is then asked to handle the request. The OLFS creates an ordered list of DispatchHandlers by reading tits configuration file.
 
The order of the list is significant. There is no guarantee that two (or more) DispatchHandlers may claim a particular request. Since the first DispatchHandler in the list to claim a request gets to service it, changing the order of the DispatchHandlers can change the behaviour of the OLFS (and thus of Hyrax).


The usefulness of this dispatching scheme is that it creates extensibility. If a third party wishes to add new functionality to Hyrax one way is to write a DispatchHandler. To incorporate it into Hyrax they only need to add it to the list in the '''olfs.xml''' and add the java classes to the Tomcat lib directory.


==Order of Dispatch Operations In Hyrax==


The DispatchHandlers are called in the following order:


In the Hyrax server incoming requests are evaluated dispatch operations occur in the following order:
# Special Request Handler
# Version Response Handler
# Directory Response Handler
# DAP2 Response Handler
# File Response Handler
# THREDDS Response Handler


S
Each DispatchHandler evaluates the incoming request by analyzing the request URL to determine if in fact it can handle the request.


==Terms==
==Terms==

Revision as of 10:43, 7 February 2008


OPeNDAP servers provide an interface through which clients can access data held on the server. The server can provide sub-setting and, in some cases, additional preprocessing operations on the requested data. The protocol through which the OPeNDAP server s provide these data services is called the Data Access Protocol (DAP). The current version of the DAP is version 2, so The DAP is usually specified as DAP2.

In addition to DAP2 responses, most OPeNDAP servers provide a number of additional services such as:

  • A navigation interface for browsing the data storage hierarchy.
  • File access.
  • Version reporting.
  • Help pages and other documentation.
  • THREDDS catalog views of the data system.


Request dispatch is the process in through which an OPeNDAP Server determines what actual piece of code is going to responsed to a given incoming request. In a perfect world, the identified piece of software will generate the type of response the client intended to invoke on the server, or at worst a sensible error response such as a web page or a serialized DAP2 error object.



Hyrax Dispatch

The Hyrax front end (OLFS) handles each incoming request by offering the request to a series of DispatchHandlers. Each DispatchHandler is asked if it can handle the request. The first DispatchHandler to say that it can is then asked to handle the request. The OLFS creates an ordered list of DispatchHandlers by reading tits configuration file.

The order of the list is significant. There is no guarantee that two (or more) DispatchHandlers may claim a particular request. Since the first DispatchHandler in the list to claim a request gets to service it, changing the order of the DispatchHandlers can change the behaviour of the OLFS (and thus of Hyrax).

The usefulness of this dispatching scheme is that it creates extensibility. If a third party wishes to add new functionality to Hyrax one way is to write a DispatchHandler. To incorporate it into Hyrax they only need to add it to the list in the olfs.xml and add the java classes to the Tomcat lib directory.

Order of Dispatch Operations In Hyrax

The DispatchHandlers are called in the following order:

  1. Special Request Handler
  2. Version Response Handler
  3. Directory Response Handler
  4. DAP2 Response Handler
  5. File Response Handler
  6. THREDDS Response Handler

Each DispatchHandler evaluates the incoming request by analyzing the request URL to determine if in fact it can handle the request.

Terms

For the sake of clarity the following definitions will be used in this document:

Request URL
The complete URL as submitted by the requesting client.
Datasource URL
The complete URL as submitted by the requesting client.
Constraint Expression (CE)
Everything following the ? character in the URL
Selection
Projection
The part of the CE prior to the first & character. This is where individual variables from a dataset can be requested, or if no variables are specified then all of the varaibles will be requested.

Don't count on the consistent use of these terms elsewhere in the OPeNDAP literature:

Special Requests

Hyrax and other servers may support some special requests. These may be a secure server administration interface, help information, server status, or system properties. There is no clearly defined set of special responses, and their implementation is left up to the various server developers.

Hyrax currently supports:

DAP2 Service

DAP2 service requests are identified by analysis of the URL as follows:

If the URL


Directory Responses

OPeNDAP Directory (aka contents)

THREDDS Directory (aka catalog)

Version Response

File Access Responses

THREDDS Responses

Errors

SOAP Dispatch Operation

Retrieved from "https://docs.opendap.org/index.php?title=ServerDispatchOperations&oldid=2062"