Problem with standard NVO web services

[martin hill]

As I understand it, each service has its own WSDL file.  What we need to do is
to ensure that certain standard methods exist on each service - this can perhaps
be verified by checking the WSDL when the service is registered, to see what
'standard' methods it provides.  

However we need to keep an eye on all the 'private' arguments - if these appear
often, then really they are 'common' arguments and we need to standardise them.
 But this can be done as an 'extended cone search' method provided as well as
the simple one, so that we preserve backward compatibility with the simple one.

Cheers,

Martin

Quoting Roy Williams <roy at cacr.caltech.edu>:

> 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
> 
> 


-- 
Martin Hill
07901 55 24 66
www.mchill.net