StandardInterfaces V0.1

[Guy Rixon]

On Wed, 14 Jan 2004, Tony Linde wrote:

> Firstly, I'm glad Wil has done this and given us something to shoot at. We
> need to agree this before we set any more specific services.
>
> General:
> - why restrict this to web services? We should be able to agree more than
> one way of implementing services: web service and cgi as a minimum I guess.
>
> 2.1:
> - most s/w will view the registry as the authoritative source of metadata.
> If the service administrator has not updated the entry in the registry (or
> caused it to be harvested) then it won't be recognised by services using the
> registry.
>
> - metadata document is the RM (Resource Metadata) : not RSM (Resource &
> Metadata)
>
> - maybe a link to the document area would be useful here
>
> SI-1:
> - chicken and egg here: does the metadata returned include the authorityId
> and resourceKey? If so, how is this got? Manually by administrator first, I
> guess.
>
> SI-2:
> - do we really need this? Most harvesting will be done by using the Metadata
> i/f and a "since" keyword, so will return changes since some date.

This interface is useful for checking on harvesting operations.

 - shows up any cases where new metadata have not yet been harvested, i.e.
   check harvesting timestamp in registry with curernt value ex service;
   therefore good for debugging;

 - allows polling of services for by registries _if_ we decide that any
   registries want to work that way.

I know that you're not much in favour of registries polling services but there
may be edge cases where it's desirable.  E.g. a private registry monitoring a
few, selected services.

> General:
> - do we need to have services harvestable for their metadata? How often will
> a service's metadata change? If infrequently, it is a waste of time for the
> registry to ask it each night (or whenever) for metadata changes. And if we
> end up with tens of thousands of services will burden the registry. Can we
> not put the onus on the service to update its metadata on the registry
> whenever a change is made? And then the registries just harvest data from
> each other. So replace SI-1 and SI-2 with...
>
> SI-1: All VO services will update the registry with which they are
> registered with any changes to metadata.

See above.  There may be registries that want to get metadata which the
service administrator doesn't know about.

Also, one way to implement notification of a registry by a service is for the
service to send an "I have changed" message to the registry and for the
registry to come back later to harvest.  This may be more efficient that the
service transmitting all the metadata to the registry in the initial
notification.

> SI-3:
> - I'm not sure this is necessary. Uptime might be used. ValidTo is unlikely
> to be kept up to date. ContactDetails are in the metadata. Position: why do
> we need this?

ValidTo is extremely valuable if the service knows this.  Consider the case of
a data-warehouse service on which as user plans a job that will take two days
to load up and six hours to run.  If the service is going down in 40 hours for
maintenance then the user need to know that.

There has to be some value of validTo that means "don't know".  make it a
nilable element?  Make it optional?  Need to agree a format.  ISO8601? Or is
there an XSD type to use for this?

I agree about the contact details.

Not sure about Position.  Can this be moved to the basic VOResource schema?




> SI-4:
> - there may be privacy issues with returning what people are doing. This
> should be optional I think.

I agree that this interface should be optional.  Or...if the log is private,
perhaps the interface should exist and return an error or an empty log.

Logs could be vast if the time-selection parameters are used unwisely; is the
service allowed to truncate the response?  if so, should it drop earlier or
later records?

>
> I'll flag this spec up to the AstroGrid developers and get them to provide
> their own comments.
>
> Cheers,
> Tony.
>
> > -----Original Message-----
> > From: owner-grid at eso.org [mailto:owner-grid at eso.org] On
> > Behalf Of Tony Linde
> > Sent: 14 January 2004 10:59
> > To: Grid_Ivoa_List
> > Subject: StandardInterfaces V0.1
> >
> >
> > Wil posted a draft for a standard interface at:
> >
> > http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/Stand
> > ardInterfaces-
> > 0.1.pdf
> >
> > but I don't remember a notice here. So this is it. Apologies
> > if I missed it.
> >
> > Cheers,
> > Tony.
> >
> > __
> > Tony Linde
> > Phone:  +44 (0)116 223 1292    Mobile: +44 (0)7753 603356
> > Fax:    +44 (0)116 252 3311    Email:  ael at star.le.ac.uk
> > Post:   Department of Physics & Astronomy,
> >         University of Leicester
> >         Leicester, UK   LE1 7RH
> >
> > Project Manager,            Director,
> > AstroGrid                   Leicester e-Science Centre
> > http://www.astrogrid.org    http://www.e-science.le.ac.uk/
> >
> >
>
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523