Three cheers for GET services - but we still have to SOAP the VO

[Martin Hill]

Ooooh flame bait....

All these things are fine about what you call GET. [I'm not sure about 
this, but I think SOAP is run over http GET too - rather than POST - but 
I know what you mean].

In fact I will add that although SOAP can also take more complex types, 
this doesn't preclude GET, which could take URLs to them instead. 
Similarly you can use GET to run different methods.

SOAP gives you a *defined interface* with WSDL; that is, you can define 
explicitly which parameters are expected and their types, and you can 
define the different methods that can be called on a service. This gives 
us enough information that we can use to connect services together; 
there is no 'service metadata', or descriptions about how to use a 
service, with a GET.  For example, with GET there is no way of knowing 
that one service allows BANDPASS=z and another doesn't.

This is why our VO services as a minimum need to support SOAP (or 
something similarly well-described); we won't have a VO that can 
interoperate if we don't!  We could of course follow the Astronomer Way 
and invent our own description language based on GETs, so that we can't 
interoperate with any non-VO services... :->

(As an aside, it is awkward, but not impossible, to build GET URLs for 
anything other than a few simple parameters; for example building a 
reasonable-sized ADQL query would in practice require some kind of 
client software to help.  Imagine trying to build a GET service for 
SExtractor, with its 100+ arguments, some of which are enumerations. 
How would the user know what the parameters are, and which parameters 
take which values?)

more below:

Roy Williams wrote:
> Three cheers for GET services
> 
> (This subject line is just to stir up the SOAP fundamentalists). As I start
> moving to the world of SOAP, I want to know how to do all the nifty things I
> used to be able to do with GET.
> 
> (1) Please find below an email that I sent to myself yesterday. It is a pointer
> to a GET-based web service, and that is why it is easy to send the email. Just
> click on it in your email spool. It is a virtual finding chart, bringing not
> just a picture, but a browser of many layers and other drilldown features. It is
> nifty to send a complete "service request" to a colleague, and all they need to
> do is to click on it.
> 
> But when we are running things on SOAP services, how can we do the same thing?
> Suppose I write to my colleague saying "use the http://blah service with x=2 and
> y=3", how long would it take them to figure out how to see the result?

Remember that when a VO service has been called, we would expect the 
results to be put somewhere in MySpace (or similar).  So instead of 
passing around a URL to the call (and therefore requiring the query to 
be run again - what a waste of processing power!) you email to your 
colleages (or yourself) a URL to the results.

> (3) There are a lot of nice read/parse qualities about GET requests. It would be
> nice to have both GET and SOAP at the same time. To somehow send keyword-value
> by the GET channel, but the complex objects and binary through the SOAP channel.

As you say, supporting GET is handy for the end user for simple service 
calls, and so it makes sense that services that provide data to the end 
user provide a GET interface as well.  But do we need to get involved in 
this? Is this up to the individual service to decide how much they want 
to implement, or should we specify a minimum for each service type?

We certainly don't want to start *mixing* GET and SOAP, if that's what 
you mean.  Let's allow services to provide two separate points of access 
if they want, but SOAP is what we need for the VO to interoperate.

> 
> People know and trust the GET method. Crossing the bridge to SOAP should be
> possible by gradual steps.

Unfortunately there's no 'gradual' step to deciding whether you support 
a (for example) SOAP SkyNode interface or not.  What we can do is make 
sure there are simple interfaces that don't require too much backend 
code, and so as the SkyNode folks have done is to define a simple 
SkyNode interface and ways of extending it.  But you can't 'gradually' 
add SOAP methods to build a standard interface and still expect it to 
interoperate, until the full (minimum) interface has been implemented.

I do feel we should also provide standard 'client API' software for the 
common astronomer languages - (FORTRAN?, Python?, Perl?, .NET?) - so 
that astronomers can reach remote services easily with all the power of 
SOAP but without caring about it.

Me? Fundamentalist? Is that the same as being Loud? :-)

Cheers,

Martin

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