VOStore as WS-Resource
mjg at cacr.caltech.edu
Tue Aug 9 10:07:03 PDT 2005
I really like the sound of this idea; however, to sell it we need to
hide the WS-RF aspect. It's hard enough to get our users to buy into
basic SOAP and I know that there are those who think that anything above
and beyond is just a complete waste of time.
Guy Rixon wrote:
>following up the discussion of ownership of data-items in VOStores, here's an
>alternative approach: make the store an ephemeral resource in the style
>established by WS-RF.
>Justification: most users will borrow storage supplied by resource providers
>and access it via VOStores. We need an interface for managing the loan of the
>storage (quotas, remaining length of lease etc.) WS-RF is an interface for
>managing leases of resources.
>Mechanism: "a VOStore" becomes a dynamic resource. An agent creates one on
>a VOStore server by calling some operation that follows the resource-factory
>pattern. (This method is outside the scope of the current VOStore interface.)
>Agents address such a dynamic store using the normal WS-RF mechanism: a SOAP
>header. All the data-items written to the store are owned by the creator of
>the store. The space used in the store can be cleared up using the WS-RF
>interface; if the storage is leased for a certain time, then it can be set to
>clear itself up. Users could create more than one dynamic store on the same
>VOStore server; they could create a dynamic store for each project or for
>Advantages: we get the management interface without having to invent and
>debate it in IVOA. We get to implement the management interface using WS-RF
>toolkits if we choose (this is transparent to the clients, so the use of
>toolkits can vary from store to store). Users of VOStore get to manage
>data-items in multiple, dynamic stores without going through VOSpace.
>We may be able to get WS-RF management tools from the grid community.
>Disadvantages: the implementor of the store has to implement WS-RF or to use a
>WS-RF toolkit. Clients of the store have to supply the WS-RF header.
>NB: the WS-RF thing doesn't change the operation signatures of VOStore. We
>could use a client for a fixed VOStore on a dynamic VOStore by adding a
>handler (e.g. the Axis or JAX-RPC kind) that adds the WS-RF SOAP header.
>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 vospace