Three cheers for GET services

[Tony Linde]

I thought SOAP was more of a back end technology. If you want to send a link
that executes a given process with specific parameters then you'll have to
construct a web page/site which performs that task. Having SOAP services
behind that page doesn't change the need for the user interface.

So if you want a web page which allows the saving and transmission of
executable links then you still need to construct that site: whether you
build it all using JSP, Javascript, C# or have a thin script layer which
calls SOAP services is up to you. But if there is a SOAP service which does
what you want then anyone CAN now build an interface to it relatively easily
instead of having to code all the access routines themselves.

In the eventual VObs world, you could send the person the VOQL/ADQL query
and they could plug it into their own favourite query front end. Or you
could send them a link to the workflow you saved in VOSpace (having given
them permission to 'see' it) and they could use that in their own workflow
engine to recreate, not just the query, but the whole flow of your analysis,
perhaps tweaking it, using different datasets or applications, then sending
it back to you to check out.

Or that's the way I saw it all anyway.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-grid at eso.org [mailto:owner-grid at eso.org] On 
> Behalf Of Roy Williams
> Sent: 07 June 2004 00:40
> To: grid at ivoa.net
> Cc: Roy Williams; Alex Szalay; Jim Gray
> Subject: Three cheers for GET services
> 
> 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?
> 
> (2) On the same topic is the question of partial arguments to 
> SOAP services. For example, under the GET system, I can 
> *derive* a service from another. If service 
> http://blah.edu/siap? returns images of all bandpasses, then 
> the new service http://blah.edu/siap?BANDPASS=z can be 
> derived (by simple concatenation!) that returns only z-images.
> 
> Or, for example, a client could go to a login screen at 
> http://blah.edu/login and get in return email a URL 
> containing his session number, such as 
> http://blah.edu/login?s=6ac3768ce8ff8. Clicking on this 
> completes the login process.
> 
> (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.
> 
> People know and trust the GET method. Crossing the bridge to 
> SOAP should be possible by gradual steps.
> 
> Roy
> 
> --------
> California Institute of Technology
> roy at caltech.edu
> 626 395 3670
> 
> ----- Original Message -----
> From: "Roy Williams" <roy at cacr.caltech.edu>
> To: "Roy Williams" <roy at cacr.caltech.edu>
> Sent: Saturday, June 05, 2004 9:10 PM
> Subject: PQ/sdss stack in VS
> 
> Finding chart PQ-2004-05-18
> 
> >
> http://virtualsky.org/servlet/Page?F=1&RA=230&DE=-.20000&Exp=G
> o+Here&T=4&P=11&S=11&X=1687&Y=2043&W=4&Z=-1&M=1
>