IVOA Grid & Web Services: VOSpace

Contents

---

Overview

Users want to be able to easily publish and share their own data as well as have data reside close to computation nodes when large-scale processing or dynamic caches for intermediate data products in workflows are involved. Three modes of data transfer need to be supported: client-server (the client pushes data to, or pulls data from, the server), server-client (the server pushes data to, or pulls data from, the client) and server-server (one server pushes data to, or pulls data from, another server in response to a client request) also known as third-party transfer.

There are many solutions already to these problems so instead of inventing our own we specify a lightweight interface, VOSpace, that sits on top of existing storage solutions, providing a common interface to an underlying heterogeneity of implementations from local file systems to bulk data grids. VOSpace can distinguish between unstructured data, which is just a collection of bytes, and structured data where there is knowledge about how the bytes are arranged and so additional operations are possible. Individual VOSpace instances can also be federated into a peer network so that the user just interacts with a single data space.

VOSpace 1.x specifications relate to a SOAP-based web service.

VOSpace 1.0

VOSpace 1.0 defines an unconnected flat file space and is now an IVOA Recommendation:

Specification

• Service specification
• WSDL for 1.0 service
• Schema for 1.0 service
• VOSpace usage note v0.1

VOSpace 1.1

VOSpace 1.1 extends the existing 1.0 specification to support containers, links between individual VOSpace instances, third party APIs and a "find" mechanism.

Specification

• Service specification

• VOSpace 1.1-rc1 wsdl
• VOSpace 1.1-rc1 schema

• VOSpace 1.1-rc3 wsdl
• VOSpace 1.1-rc3 schema

Standard URIs

The VOSpace specification refers to a number of standard URIs for properties, views and protocols.

The following URIs will be used to represent the standard protocols:

• ivo://ivoa.net/vospace/core#httpget Will be used as the protocol URI for a HTTP GET transfer.
• ivo://ivoa.net/vospace/core#httpput Will be used as the protocol URI for a HTTP PUT transfer.

The following URIs will be used to represent the standard views:

• ivo://ivoa.net/vospace/core#anyview Will be used as the view URI to indicate that a service will accept any view for an import operation.
• ivo://ivoa.net/vospace/core#binaryview Will be used as the view URI to import or export data as a binary file.
• ivo://ivoa.net/vospace/core#defaultview Will be used by a client to indicate that the service should choose the most appropriate view for a data export.

In order to register VOSpace services in an IVOA registry, the service capabilities need to identified using a standard URI.

The following URIs will be used to represent the service capabilities:

• ivo://ivoa.net/vospace/core#vospace-1.0 Will be used as the capability URI for a VOSpace 1.0 service.
• ivo://ivoa.net/vospace/core#vospace-1.1 Will be used as the capability URI for a VOSpace 1.1 service.
• ivo://ivoa.net/vospace/core#vospace-2.0 Will be used as the capability URI for a VOSpace 2.0 service.

If a service implementation supports more than one version of the VOSpace API, then these capability URIs can also be used within a VOSpace service to identify different VOSpace capabilities for a node.

One use case for this would be a VOSpace-1.1 client talking to a service that implements both VOSpace-1.0 and VOSpace-1.1, where the client is acting on behalf of a third party agent that only understands VOSpace-1.0. In which case, the client can use the information in the VOSpace-1.0 capability to direct the third party agent to the VOSpace-1.0 endpoint.

Discussion

• Discussion page for 1.1 specification
• Discussion page for property registration
• Discussion page for data formats

History

• Old discussion page for VOSpace 1.1 features

VOSpace 2.0

VOSpace 2.0 defines a RESTful interface.

Specification

The first version of the Working Draft is available here.

Discussion

• Discussion page for specification

Implementations

group	version	endpoint	VOSpace root	Notes
Caltech	v1.1	testnvo.cacr.caltech.edu	vos://nvo.caltech!vospace/	HTTP transports, supports structured nodes and archive formats (tar, tar.gz)
ESO	v1.0	vops1.hq.eso.org	vos://org.eso!vospacetest/	HTTP transports
Astrogrid

Mailing list

The mailing list for discussion of the VOSpace specifications and related issues is: vospace@ivoa.net which is archived at: http://ivoa.net/forum/vospace/index.htm

VOSpace 1.0 history

Discussion

• Discussion page for property registration
• Resource schema (old version)
• Example document (old version)

The discussion pages that lead up to the V1.0 working draft are available here :

• Discussion page for the WSDL and XML schema (closed)
• Discussion page for specification (closed)
• Mailing list archive