On 30.04.2007, at 04:54, Doug Tody wrote:
> Hi Paul -
>
>
> All of this is true, and I have no problem with caching service
> metadata in the registry, automatically updating it as it changes,
> providing for detection of cache errors when they occur, monitoring
> service function with getAvailability, periodic service verification,
> etc. There are many grid use-cases which will rely upon this sort
> of thing to function efficiently.
>
> Nonetheless, it is desirable for services to be self-contained
> (able to function without an external client such as the registry),
> and self-describing. A similar issue pertains to any resource
> which is directly managed by a service, e.g., a collection of
> individual datasets. If the service manages the datasets, tracking
> changes, mediating metadata, etc., it should be the source of any
> information describing the datasets, regardless of whether this is
> cached externally. In the case of a data collection described as a
> single entity, the "service" responsible for the information is the
> registry itself, which manages information which is again cached by
> other clients, e.g, another registry.
This was essentially the thinking behind the getRegistration method
of the VO standard interfaces - the service itself is the the best
place to manage the metadata, but the registry is the best place to
distribute the metadata, and a client should get the same answer when
asking either source.
>
> If everything were static this might not be an issue, but the need
> to manage such information carefully becomes more clear when we
> consider
> use cases such as services which are dynamic, e.g., accessing virtual
> data (where the external description of the data can only be resolved
> by the service which generated it), or other forms of dynamic data,
> such as a TSAP service which accesses a theoretical model.
>
This can lead to a philosophical discussion on what is metadata, and what is data - and involves the the fine-grained-ness of the registry entries, but it is clear that at one end of the spectrum there is no point in registering metadata about every data item in a VOSpace as then the registry becomes VOSpace, so they no-longer separate concepts (and maybe at some time in the distant future the registry could be considered just a corner of VOSpace). However, near the other end of the spectrum there is no point depriving clients of basic information necessary to interact with a service - if a client is trying to discover whether there is a STAP service with tables that contain a column described by particular UCD, there is no point in forcing the client to query every registered STAP service when the information could be discovered in one call to the registry. What I guess I am saying is for the class of S*AP protocols, they are 'simple' enough that there should be no metadata that is not static.
Paul Harrison
ESO Garching
www.eso.org
Received on 2007-04-30Z10:14:52