[wcsplus] Design of asynchronous request in DEWS WCS

NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.

Hi all,

As Adit said in an earlier post, we designed and built a WCS with
asynchronous capability in DEWS.  Thought it might be useful to
summarize on this list the key features of the design, which borrows
from the WPS spec.

The asynchronous behaviour is specified by two parameters, STORE and
STATUS, which both default to false (meaning that we are
backward-compatible with WCS1.0.0).

STORE=true means "Give me a URL to the data instead of the data itself"
STATUS=true means "Let me monitor the extraction process"

There are three possible behaviours (and one that makes no sense and
is disallowed):
(1) STORE=false and STATUS=false.  "Fully-synchronous."  The server
waits until the data have been extracted and then replies to the
client with the data as a direct response to the request.
(2) STORE=true and STATUS=false.  "Semi-synchronous."  The server
waits until the data have been extracted and responds to the client
with a URL to the data file.
(3) STORE=true and STATUS=true.  "Asynchronous."  The server replies
*immediately* with a document containing a unique job ID.  The client
can then poll the server using this job ID to discover information
about the progress of the extraction.  When the extraction is complete
the polling results in the URL to the data file being returned to the

STORE=false, STATUS=true makes no sense and is disallowed (server
responds with an error).

The server can respond with an error if it does not wish to satisfy a
fully- or semi-synchronous request (because the data extraction will
take too long, for example).  We chose this design instead of a
"serverDecide" option because it simplifies the client (the client
always knows what kind of response to expect).

As Adit says, the format of the status documents was inspired by the
WPS ExecuteResponse document.  I think we diverged from this for
reasons of expediency, but I think the ER format is logical: a large
data extraction is conceptually the same as a long-running processing

There will be many possible designs but at least we know this one
works (at least for us!) and it is close to an existing OGC spec
(WPS).  The DEWS WCS is a "reference implementation" for this design
and we're happy to share the code (Java web app).

Hope this helps,

Dr Jon Blower              Tel: +44 118 378 5213 (direct line)
Technical Director         Tel: +44 118 378 8741 (ESSC)
Reading e-Science Centre   Fax: +44 118 378 6413
ESSC                       Email: jdb@xxxxxxxxxxxxxxxxxxxx
University of Reading
3 Earley Gate
Reading RG6 6AL, UK

  • 2007 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the wcsplus archives: