Re: your mail

From: Doug Tody <dtody-at-nrao.edu>
Date: Sun, 29 Apr 2007 20:54:09 -0600 (MDT)


Hi Paul -

On Fri, 27 Apr 2007, Paul Harrison wrote: 

>>> OBS #8: Client capability negotiation is a new thing in the VO; we
>>> currently have have no (little?) software/experience making use of it.
>> 
>> Not true; this has been done for some time. A good example of this is the 
>> TSAP (theory-SSAP) "prototype" from ESAC (Pedro et. al., please correct me 
>> if I get any of this wrong). In this case, the client application 
>> dynamically queries the service for its service metadata (using 
>> FORMAT=metadata in this older SIAP-based implementation), and dynamically 
>> adjust the GUI presented to the user, so that they can input the parameters 
>> of a specific theoretical spectral model. There are potentially many cases 
>> like this, and it is a good example of why clients need access to this sort 
>> of information, post-discovery of the service.

>
> Well if you have accepted the principle of a getCapabilities()
> operation that returns VOResource style metadata, and iff it returns
> *all* the metadata about a service then there is a simple optimization
> that can make the whole VO work more efficiently - the client can
> simply query the registry to find out everything it needs to know
> about the service. Registries can ensure that they are up to date by
> regularly 'crawling' the registered services, and a client will get a
> much faster response than having to separately query each different
> service to get service metadata. CEA clients have been routinely
> adusting the user interface from service metadata that they get from
> the registry for years now.
>
> You could even go further, and with a little more standard metadata
> in a VOService definition (to take advantage of the other VOSI
> functionality) e.g. lastPingTime, serviceAliveFlag a client could
> discover which services are currently alive and make an appropriate
> selection directly from the registry, without having to contact each
> one separately. So the registry could would effectively include
> a service like this http://thor.roe.ac.uk/vomon/status.xml, which
> takes the approach of providing an independent service to do this
> important function.

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.

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.

Received on 2007-04-30Z04:56:55