Re: [wcsplus] more on asynchronous response

• To: <wcsplus@xxxxxxxxxxxxxxxx>
• Subject: Re: [wcsplus] more on asynchronous response
• From: "Adit Santokhee" <ads@xxxxxxxxxxxxxxxxxxxx>
• Date: Fri, 26 Oct 2007 15:27:48 +0100

Hi all,

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


The GetCoverage request URL is as follows:

http://dexter.nerc-essc.ac.uk:9080/MarineDataService/GadsWCS?SERVICE=WCS&VER
SION=1.0.0&REQUEST=GetCoverage&COVERAGE=MERSEA_NATL_ANAL/salinity&BBOX=-75,5
,13,50,5,5&TIME=22-09-2004%2000:00:00/24-09-2004%2000:00:00/P1D&FORMAT=CF-ne
tCDF&WIDTH=1&HEIGHT=1&DEPTH=1&CRS=NDG:LonLatPressureCRS&STATUS=FALSE


This returns the following document:

Data can be downloaded from
http://dexter.nerc-essc.ac.uk:9080/DataManager/GetData?id=5055

http://dexter.nerc-essc.ac.uk:9080/MarineDataService/GadsWCS?SERVICE=WCS&VER
SION=1.0.0&REQUEST=GetCoverage&COVERAGE=MERSEA_NATL_ANAL/salinity&BBOX=-75,5
,13,50,5,5&TIME=22-09-2004%2000:00:00/24-09-2004%2000:00:00/P1D&FORMAT=CF-ne
tCDF&WIDTH=1&HEIGHT=1&DEPTH=1&CRS=NDG:LonLatPressureCRS&STATUS=TRUE


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

   <Status>

<URL>http://dexter.nerc-essc.ac.uk:9080/MarineDataService/PollingManager?id=

 </GadsWcs>




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

- <  GadsWcs>

- <            Status>

           </Status>

 </GadsWcs>


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


http://dexter.nerc-essc.ac.uk:9080/DataManager/GetData?id=5054


Cheers,
Adit

-----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" />
</asynchResponse>

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

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

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... :-)

Cheers
Dominic

_______________________________________________
wcsplus mailing list
wcsplus@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:

• Follow-Ups:
  • Re: [wcsplus] more on asynchronous response
    • From: Dominic Lowe

• References:
  • Re: [wcsplus] more on asynchronous response
    • From: Dominic Lowe