UWS pattern makes scratch VOSpace redundant

Matthew Graham mjg at cacr.caltech.edu
Sun Oct 14 09:46:55 PDT 2007


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
>
>   



More information about the grid mailing list