Re: UWS pattern makes scratch VOSpace redundant

From: Matthew Graham <mjg-at-cacr.caltech.edu>
Date: Sun, 14 Oct 2007 09:46:55 -0700


Hi,

Again the Cloudspace concept uses different schemes to address different functional aspects of the same resource, although Norman would rather see us using http URIs for everything!

    Cheers,

    Matthew

Guy Rixon wrote:
> The results URI for a UWS doesn't have to be in the same scheme as the
> controls for the URI: its doesn't have to be a HTTP URL. The service provider
> can put a vos:// URI for the results.
>
> Cheers,
> Guy
>
> On Fri, 12 Oct 2007, Paul Harrison wrote:
>
>
>> Hi,
>>
>> I have been thinking about one of the use cases that we been
>> advocating for VOSpace- that of using it for temporary storage of
>> results between steps in a workflow. This has been a principal use of
>> MySpace within Astrogrid for instance. The UWS pattern allows for
>> each service to be the temporary storage for the data that is to be
>> the input to the next step in the workflow i.e. the second
>> application can read data from the (jobs)/(jobid)/results uri of the
>> first step. This is both easier to implement and more efficient in
>> data transport terms than moving the data into a scratch VOSpace. UWS
>> provides all of the data management facilities needed for this simple
>> scenario.
>>
>> The above conclusion holds for a set of distributed UWS services an a
>> centralized VOSpace - if services are co-located then the conclusions
>> become more complex. Imagine that there is a UWS data processing
>> service and a co-located VOSpace service, where the two services
>> actually share the same backend storage - i.e. in VOSpace terms the
>> file: protocol could be used by the UWS to retrieve the data. In this
>> case there could be some benefit to having a co-located VOSpace
>> because the data could be retrieved and put to the VOSpace very
>> efficiently and it allows for long term storage, so that the combined
>> UWS/VOSpace service could gradually accumulate raw and processed data
>> products that perhaps with the addition of a colocated Querying
>> service could provide a valuable dataset.
>>
>> Cheers,
>> Paul.
>>
>> .
>> Dr. Paul Harrison
>> JBCA, Manchester University
>> http://www.manchester.ac.uk/jodrellbank
>>
>>
>>
>>
>
> Guy Rixon gtr-at-ast.cam.ac.uk
> Institute of Astronomy Tel: +44-1223-337542
> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523
>
>
Received on 2007-10-14Z18:47:29