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.
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).
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.
> What you say makes sense, Doug, but only if the person maintaining the
> resource metadata is different from the one maintaining the service
> metadata.
Note that the service metadata itself (stuff like MaxSR, MaxRecords, which optional capabilities the service instance implements, input parameters, etc.) is all or nearly all simple stuff which can be autogenerated by a good service implementation or framework from knowledge fundamental to the basic functioning of the service. It only needs to change when the service changes, and ideally will be automatically updated in the registry when a new version gets deployed.
On Tue, 8 May 2007, Tony Linde wrote:
> What you say makes sense, Doug, but only if the person maintaining the
> resource metadata is different from the one maintaining the service
> metadata. I'd always assumed that the service is the resource (ie, the
> resource entry points to the service) and vice versa (ie, the service is
> known about only through the resource entry), a one-to-one relationship so
> to speak.
>
> In what way are they not the same and how do you have it that different
> people maintain the sets of metadata?
>
> [BTW - I don't think this affects the registry discussion as we've accepted
> for a long time that you might have the metadata accessible from the
> service, even that you could have only a minimal entry in the registry with
> detailed metadata only available from the service.]
>
> Cheers,
> Tony.
>
>> -----Original Message-----
>> From: owner-dal-at-eso.org [mailto:owner-dal-at-eso.org] On Behalf Of Doug
>> Tody
>> Sent: 08 May 2007 19:51
>> To: Paul Harrison
>> Cc: grid-at-ivoa.net; dal-at-ivoa.net
>> Subject: Re: New version of VO Support Interfaces: v0.26
>>
>> Hi Paul -
>>
>> I agree with most of what you say. The service provider (not
>> necessarily implementer or operations team) is the ultimate source
>> of all information describing the service. The key issue is
>> that *resource* metadata, describing the service at a high level,
>> has nothing to do with the basic functioning of the service; the
>> service should describe only what it knows about, that is, itself
>> (the service metadata) and any data it manages. The key problem with
>> putting an entire VOResource at the level of the service, is that we
>> are then requiring the service to curate resource metadata. I think
>> the Resource Registry is much better suited to curating Resource
>> Metadata, describing the relationships between related resources,
>> ensuring resource metadata completeness and integrity, and so forth.
>>
>> - Doug
Received on 2007-05-08Z22:42:06