New version of VO Support Interfaces: v0.26

[Paul Harrison]

On 08.05.2007, at 22:41, Doug Tody wrote:

> Hi Tony, All -
>
> As only one example, a while back here at NRAO our Web intrastructure
> changed, having something to do with HTTP vs HTTPS.  Clients trying
> to access our services would fail as a result.  It was necessary to
> go into the registry and edit the resource metadata to change the
> accessURL for all these services.  Later, when the problem was fixed,
> we changed it back.  The services themselves were never touched.
>
> Another simple example might be the contact information for a
> resource/service.  This is an operations matter, not a service
> function matter.  If we want to change this for all our services,
> it would be simplest to do this by editing the resource metadata for
> all affected services, probably in some registry portal, ideally with
> some sort of global edit.
>
There is nothing in VOSI to say that you cannot do this.
> If on the other hand, we have to do this at the level of the deployed
> service, the service may be deployed on a protected, configuration
> controlled, operational server (our production services here are as I
> am sure they are at many other sites).  We can't just go edit those
> XML files.  It can be fixed in a test version (which is probably
> not registered) but we may have to wait a week or so for any change
> to propagate to the production version.  If on the other hand the
> resource metadata is curated by a registry, we can login and change
> it immediately.
>
> If the entire VOResource record comes from the service, what
> happens to our ability to enter/review/edit resource metadata in the
> registry, using the nice GUIs, possibly SQL-based tools, verifiers,
> etc. available?  What *will* happen is that the user will review
> and edit this information in a registry portal, then the next time
> the VOResource is updated from the service, the entire record will
> be blown away.  In effect there is no longer any point to having
> an administrative interface to the registry; to do anything with
> the resource metadata we have to edit the low level XML directly
> at the service level (most VO users should never even see things at
> this level).
These sorts of problems are avoided by having timestamps on the  
changes and not automatically overwriting if the record is newer, and  
I believe that the VOSI and the VOResouce have these timestamping  
facilities already defined. It is a good argument however for  
allowing a multi call discovery of service metadata which I was  
previously against, as it seemed like an unnecessary complication,  
but being able to separately timestamp would be useful. I concede  
that there is a certain amount of the "dublin core" style metadata  
from the VOResource that is more often an operational concern, and  
more easily centrally managed - but the essential characterization of  
this type of metadata is that it is not essential for a machine  
interaction with the service, but merely "useful" for a human to know.

I will resist the temptation to suggest that the VOSI should include  
the capability to push a VOResouce description back to the service to  
allow the editing at either end, which would be another way to ensure  
synchonization of metadata at registry and service
>
> My suggestion is that the Resource Registry should manage and curate
> high level resource metadata; it also should cache and search service
> metadata, and might also cache/search "fine-grained" metadata.
> The getCapabilities operation for a service can return the service
> metadata, i.e., the "capability" element of a VOResource record
> for a service, as defined by the service developers.  When updated,
> this would blow away the previous capability element, but the update
> operation would leave all other elements of the VOResource intact.
> If an independent tool, for example a foot print service, should
> update the Coverage portion of the resource metadata, this would in
> turn leave the service metadata unaffected.  Likewise, updating cached
> column metadata for a table should not affect the resource metadata
> for the parent data collection.

I think that having a getResource and a getCapabilities call would  
allow people to implement and manage services and registries whether  
their world view is "fine-grained" or not. There are a few details to  
be cleared up such as perhaps adding a flag to the "registry  
capability" itself to say whether it is a "fine-grained" registry or  
not - i.e. does it automatically harvest getCapabilities from services.


Cheers,
	Paul.


Paul Harrison
ESO Garching
www.eso.org