Re: [wcsplus] more on asynchronous response

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

Hi all,

We have implemented a WCS that handles asynchronous data delivery. This was
done in the context of a project called DEWS, Our solution
is as follows:

The GetCoverage request URL is as follows:

Semi-synchronous data delivery (STATUS=FALSE)

This returns the following document:

<?xml version="1.0" encoding="UTF-8" ?> < GadsWcs>

<url></url> </GadsWcs>

Data can be downloaded from

Asynchronous data delivery (STATUS=TRUE)

This returns an XML document with the following piece of information:

<?xml version="1.0" encoding="UTF-8" ?> <GadsWcs>
<ProcessStarted>Process has started execution !</ProcessStarted> <JobID>5054</JobID>
5054</URL> <EstimatedSize>2.292216</EstimatedSize> </Status>

The user can poll on the URL in the XML document above for progress:

<?xml version="1.0" encoding="UTF-8" ?>
- <  GadsWcs>

- <            Status>

< JobID>5054</JobID> < TimeCompleted>2007-07-06 14:59:36.0</TimeCompleted> < DataExtracted>2.297008</DataExtracted>


If the data isn't ready yet for download, TimeCompleted is null. Finally
data can be downloaded using the following:


-----Original Message-----
From: wcsplus-bounces@xxxxxxxxxxxxxxxx
[mailto:wcsplus-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Dominic Lowe
Sent: 26 October 2007 15:13
To: wcsplus@xxxxxxxxxxxxxxxx
Cc: Paolo Mazzetti
Subject: Re: [wcsplus] more on asynchronous response

Hi Ethan and all,

Comment below:

On Wednesday 24 October 2007 01:11, Ethan Davis wrote:
That sounds good. Though I think of the status monitor as an extension
of the body of the 202 response (which is the XML document mentioned
above that we need to define). Perhaps this is part of why I had not
thought of using redirects. I see this status monitor XML document as
removing the asynchronous response from the realm of the HTTP
specification (sort of) and instead moving it into the xlink:href world.
So, rather than the status monitor response code redirecting us to the
new resource, the body of the status monitor response would indicate the
new resource was available and provide a link to the new resource. So,
here's my take:

a) client GETs the Ures URI
b) if delayed, response 202 code with
b1) Location header providing status monitor URI (Ustatus)
b2) Body containing XML document with status, estimate of completion,
and link to status monitor URI (Ustatus)
c) client GETs the Ustatus URI:
c1) if still not available, response code 200 with XML document same as
response b2 (maybe without Ustatus link).
c2) if available, response code 200 with XML document (similar to
response b2?) that indicates the resource is ready and provides a link
to  the resulting resource.

Some very simple XML possibilities ...
For b)
<asynchResponse status="processing" completionEstimate="2007-10-24T02:34">
  <statusMonitor xlink:href="some URI" />

For c1)
<asynchResponse status="processing" completionEstimate="2007-10-24T02:34" />

For c2)
<asynchResponse status="done">
  <generatedResource xlink:href="some URI" />

This status monitor is conceptually very similar to the 'ExecuteResponse' document in the Web Processing Service Specification. So as a starting step (and to get us going) we could take this direct from the WPS spec for WCS 1.0+ and then depending on how we find it, enhance it from there and also feed our findings back to the WPS working group.
I would prefer to see us work with an existing specification rather than try

and define our own schema from scratch. My concern being that we might otherwise spend all our time designing new specifications and not implementing them... :-)

wcsplus mailing list
For list information or to unsubscribe, visit:

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