Web/Grid Services WG Session 3
Notes from Ray Plante

Wil/Dave:  VOStore/VOSpace

VOStore intended for:
 o  simple access to files/tabular data
 o  unify mydb,srb,myspace
 o  driver for security model
 o  interface for interoperability

Not for:
 o  mirrors
 o  complex aggregations

US status
 o  partial implementations
     Wil:  on CASJOBS
     Arun (SDSC):  on SRB
 o  full implementation 
     Mathew: on webdav
 o  security is orthogonal
     X.509 signed SOAP messages

FileStore - Astrogrid
 o  functionally equivalent to VOStore
 o  not quite in sync with spec
 o  has import/export, not get/put
 o  not list

VOStore V0.18
 o  dave,guy,mathew,wil
 o  properties added
 o  merging  {Import,Export}Data with Get/Put (synonomous)
 o  ImportInit/ExportInit
    - needed?  for async exchanges
    - working to make this clearer, simpler
 o  Better Names?

Keith:  important to make it clear form what perspective names are
intended to be interpreted from:  store's vs. client's
==> propose to put perspective into name:  
        importDataIntoStore(), exportDataFromStore()

The Space/Store layers

VOStore can either appear at the high/smart layer or at the physical
location.  Which do you register?  

VOSpace:  smart layer that manages multiple physical stores.  
          need mechanisms for space to get updates about changes in
            physical stores, either push or pull

Guy:

Power User wants a *lot* of storage
  *  can't get enough permanent storage, so have to lease temporary
        space.  
  *  means that files must be purged

Requirements:
   for a data object or collection, need to 
     read the time left of on lease
     renew lease
     release the storage ahead of expiry of lease

   leases are arranged with store providers
     control interface is on the store
     need to synch state b/w store & VOSpace

   want to manage leases for collections rather than files!
   but... leases are given on storage!

Smells like WS-RF
Pattern:
  virtual resource (lease) hosted on concrete resource
  limited lifetime
  expired resources automaticlly cleaned up
  etc.

Suggestions:
  each lease applies to a collectionof zero/more objects on the same
    store
  VOStoreManagement interface (sibling to VOStore)
    *  lease(lifetime): resource         // create new
    *  getLeaseFor(objectid): resource   // recover old collection
    *  assign(ojbid)                     // add object to colletion
    *  plus ops of WS-ResLifetime
    *  plus ops of WS-ResProp
    *  plus ops of WS-BaseNotif (optional?)

  For stores that don't lease:  (Guy likes this better)
    *  one default collection
    *  lease() & getLeaseFor() return default singleton
    *  lifetime of default lease is infinite & immutable

  Can call assign() for a objid before creating the data obj.
  Store with no leasing: not required to impl. VOStoreManagement

  What is the prudent way to proceed given the youth of the WS-*
  standards. 

  Action item:  put together a demonstration of international sharing
    of data via VOStore for ADASS