New version of VO Support Interfaces: v0.26

[Tony Linde]

As usual, Doug, I agree with a 'not yet' caveat :)

I'll just take the registry issue. A service which is not registered is not
in the VO. At the moment, we have the proposal from GWS that every service
implement a getCapabilities method which returns the full registry record -
one which, I would emphasise, is in a format determined by the group which
has come up with the service standard (hopefully in discussion with the
registry wg).

If we allow every service standard to come up with its own method of
introspecting service metadata then every registry implementation has to be
modified every time a new service is proposed (and several times during the
standard's development if the service is to be tested in a real VO
environment). This is, IMO, not very practical. The getCapabilities method
is no additional effort (compared with other specialised introspection
methods) on services which are under development anyway.

In the longer term, we may have some intermediate layer between services and
the registry which provides the equivalent of getCapabilities to the
registry but contains service introspection details which are service
specific. We need to get a lot further along the service development path
before this becomes feasible I think.

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 00:21
> To: Roy Williams
> Cc: grid at ivoa.net; dal at ivoa.net
> Subject: Re: New version of VO Support Interfaces: v0.26
> 
> Hi Roy -
> 
> My view is that we have to be careful to keep the system modular,
> and avoid unnecessary interdependencies which make it difficult
> to do anything without exposure to multiple parts of the system.
> To publish data, it should be possible for a user to be able to
> implement and test a data service stand-alone, ideally by reading
> only one document, the service specification (no STC, no Registry
> internals or schemas, possibly not even a VOTable spec if a library
> is used).  The "minimally compliant" version of the service needs to
> be kept simple enough to make it a reasonable job to implement with
> this approach, much as SIA is now.  Completeness and robustness will
> probably always be a problem with this approach however.
> 
> To go to the next level we will need interoperable service frameworks
> that provide all the "recommended" and advanced capabilities in
> a rigorous and robust fashion, largely transparent to the service
> implementor.  The user would pick one of the user-oriented frameworks
> as the basis for their service, and would only need to add the
> "business logic" required to interface to their data.  This should
> still be about as easy overall, as the minimal case described above.
> Once we get to this level, all the advanced capabilities such as
> ADQL, asynchronous operations, complex regions, VOSpace, etc.,
> become mainly an issue internal to the IVOA (a nontrivial issue in
> itself as things become more complex), and are largely transparent
> to the user-developer.
> 
> I think ultimately we have to go this route to have a useful system.
> 
>  	- Doug
> 
> 
> 
> On Mon, 7 May 2007, Roy Williams wrote:
> 
> > We have come a long way from Simple Cone Search.  If a developer
> wants to
> > expose a catalog by IVOA service, it turns out to be pretty
> complicated, with
> > all the MUSTs and SHOULDs and REGISTRY full of complicated XML. The
> service
> > developer has to do these:
> >
> > -- UCDs for the output table,
> > -- Heartbeat and uptime services, next scheduled downtime
> > -- Recording usage in special IVOA logging format
> > -- Passing a RunID tag from place to place
> > -- Choosing a registry interface, reading the RM document, filling in
> the
> > form
> > -- Implementation of getAvailability, getCapabilities,
> getRegistration,
> > metadataLastChanged etc etc
> > -- STC document describing coverage of the service
> > -- A SOAP interface including a WSDL document
> > -- A REST interface that works with nice "resources" and has no nasty
> dirty
> > "verbs"
> > -- Understanding complex multi-layered XML and making it all valid
> >
> > ....... and soon there will also be
> > -- Units for each column in proper format
> > -- Implementation of TAP protocol
> > -- Connection to IVOA data model and relevant utypes in the output
> table
> > -- Bulk access interfaces for inventory, bulk crossmatch, etc
> >
> > Questions
> > (1) Can the IVOA support this level of complexity?
> > (2) Where is the robust software that leads the service developer
> through the
> > maze?
> > (3) Can the IVOA Recommend any of the above standards in the absence
> of that
> > implementation software?
> > (4) If somebody makes a service that has fabulous science data but
> NONE OF
> > THE ABOVE, should the IVOA reject it?
> >