UWS pattern makes scratch VOSpace redundant

[Paul Harrison]

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