Problem with standard NVO web services

[Tony Linde]

In a way this crosses with the Registry group in that whatever ways we find
of describing services have to be incorporated into the service description
in order to allow automated workflow engines to compose tasks into
workflows.

As I see it, any service is:

  inputs + options --> functions --> outputs

So what we need is:

1. a way to describe inputs and outputs. This should include some namespaced
data formats (eg VOTable) with some way of specifying backward compatibility
(eg input can be VOTable 1.1.3, 1.1.2 and 1.1.1 but not earlier); maybe just
a list of namespaces.

2. to use xsd data types for the options but need to include facility to
indicate hierarchy of options, eg if opt1=valA then opt2 and opt3 must be
specified but if opt1=valB then no more options.

3. some standard way to specify the function type(s?), eg data query
(includes cone search & sky node), image query etc; so a namespaced
enumerated list.

4. to describe how files are copied to the service for use as inputs and how
output files are retrieved: maybe a pointer to the local file transfer
service (with its own inputs, functions & outputs!); need handshaking
mechanism to determine most efficient common file transfer protocol where >1
supported.

All of the above then need to be incorporated into the registry description
of a service. A user constructing a workflow then just specifies that they
need a data query service with certain characteristics and the registry can
find relevant services. User chooses one, sets the options and plugs it into
the workflow, perhaps linking inputs to previous task outputs. The workflow
engine ensures matching file formats (and suggests converters if they don't
match), adds the appropriate file transfer services and user moves onto
specifying next task.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-dal at eso.org [mailto:owner-dal at eso.org] On Behalf 
> Of Roy Williams
> Sent: 25 October 2003 22:31
> To: Doug Tody; martin hill
> Cc: dal at ivoa.net
> Subject: Problem with standard NVO web services
> 
> 
> There is a problem looming with making our standard services 
> into web services.
> 
> For example cone search has three basic input keywords (RA, 
> DEC, SR) and some optional ones. However what we are really 
> doing is saying that these parameters must be in the request 
> object -- *in addition to others*.
> 
> When people implement a cone search, they often have extra, 
> private arguments. They want a single servlet or CGI to cover 
> a number of catalogs and circumstances. Clearly we do not 
> write a separate piece of code for each database query, we 
> write the code once. The servlet might be used by specifying 
> which catalog (CAT=2mass), which version of the catalog 
> (VERSION=1.3), or other keywords in addition to the 
> "official" keywords in the specification.
> 
> In the GET specification, it is all very simple. We register 
> our one and only service (called "search") several times like 
> this http://blahblah.edu/search?CAT=2mass&
> http://blahblah.edu/search?CAT=SDSS&VERSION=DR1&
> http://blahblah.edu/search?CAT=Messier&
> 
> Now for my question: when we make SOAP versions of the Cone 
> and SIAP services, we will make WSDL files to describe the 
> services. How many WSDL files will there be? It could be
>     -- one WSDL file because there is only one service
>     -- many WSDL files, one for each catalog/version
> 
> What we really want is like the Java "interface" construct. 
> Not a full description, like WSDL, but saying it must support 
> some specific methods.
> 
> Cheers
> Roy
> 
> --------
> Caltech Center for Advanced Computing Research 
> roy at cacr.caltech.edu 626 395 3670
>