Alternative proposal

[Doug Tody]

On Thu, 10 May 2007, Tony Linde wrote:

> Hi Doug,
>
> > the registry Web interface.  If so, it might want to continue to be a
> > "push" (call to a registry doRegistration method of some sort), using
> > pull as is now planned to have the registry update cached metadata,
> > once it already has the service registered.
>
> Exactly.

This may solve the problem then.  The main motivation we originally had
for getRegistration, which would upload an entire VOResource record, was
to make it easy for a service developer to control service registration
without having to go use a Registry Web interface.

If we separate the problem into initial high level registration vs
automated updates and collection of auxiliary information (service and
data-related metadata) for an already registered service, then the issues
are all avoided.  Initial registration can be performed either manually,
using a Web interface to a registry portal, with associated user-friendly
tools, or via a programmatic interface, by an experienced developer or
service framework (Tomcat has a dual interface like this for example).

The experienced developer or clever service framework could use the remote
administrative interface to upload entire resource records, or even
download them and edit them manually or with custom tools, if desired.
Ordinary mortals would use the Web interface and associated tools.
Once a service is registered and operational, updates to service metadata
could be managed on a "pull" basis by the registry, triggered by modify
data provided by the service (as Guy and Keith have suggested, and we
have also proposed in connection with getAvailability).  This would call
getCapabilities to update only the service metadata, or other operations
to update any other form of data which is cached, e.g., finer grained
metadata describing table data.  It would still be possible for an expert
to simply update entire resource records, but updates to portions of the
information by either humans or tools would also be possible.

In summary what I would propose is

    o	Provide both a Web and programmatic interface to the registry
	to operate upon resource records (either might require
	authentication, but that is Good).

    o	For a service, getCapabilities returns only service metadata,
	and can support any client app including both user apps and
	the registry.

    o	Something based on VOSI or a getAvailabilty service operation is
	used to monitor service status, perhaps including some important
	status information including modtime, build number or some such to
	trigger updates (also perhaps useful information such as uptime).

    o	The issues of more "fine grained" metadata are similar, but may
    	involve other service interfaces.

So far as I can tell, this addresses all the concerns that have been
raised, including what DAL requires.

    - Doug



----
On Thu, 10 May 2007, Doug Tody wrote:

> I can see where one might want to do this in the kind of situation
> you describe.  Perhaps the right way to think of this is as a registry
> feature, with the service framework taking the place of a human using
> the registry Web interface.  If so, it might want to continue to be a
> "push" (call to a registry doRegistration method of some sort), using
> pull as is now planned to have the registry update cached metadata,
> once it already has the service registered.
~