OGF20 OGSA Data WG session

Key points arising


Replication scenario

- Could have multiple instances of this scenario, e.g. showing how the same interfaces could map to vendor-specific mechanisms, alternative OGSA implementations, storage-level implementation, etc.

- UVa have a replication system using WS-Name resolvers instead of a replica catalogue.

- Need a monitoring system to notify the replica catalogue when replicas become unavailable.  Or the Data Service 3 could update the catalogue when it encounters a failure (but then when would it get back online?)

- Need to show how naming works across this scenario.  Ditto security?


Federation scenario

- Need to discuss naming.  Is there a common name space?


Policy

- V. interesting discussion.  Passing policy information as expliit arguments may not be sufficient because some entities are created in response to other actions - e.g. a BES container may create a file.  UVa are passing policy info in the SOAP header and services are passing this along.  

- Policy choice may depend on the user, on where in the RNS hierarchy the entity is created, on the physical location, on the type of resource, ...

- Reagan has implemented a policy management system  This has a namespace for the policy rules, a namespace for the services and namespace for policy outcomes (e.g. when was replica A last verified).


File sets

- Someone asked about managing sets of files.  From our point of view, if you can name a set of files, we can accommodate them.  Ditto with file versions.  Perhaps we need to add a service (in v2!) that manages large sets of files?  Andrew pointed out that RNS can do this but what if people want to organise these at the WS-Name level?  Perhaps this is just a variation on a registry?


Storage directory operaions

I'm still not convinced that these are separate from the RNS operations.