[kepler-dev] thanks and ReST

[Douglas Fils]

Ilkay (and all)
    Thanks for the info regarding the installer.  For us here at CHRONOS 
it is not an issue as we are a linux camp, but some others in the 
CHRONOS system are windows and mac based so I will just wait till the 
new installers are out to get them involved in workflow creation.  It's 
a very nice package for checking how well our servers chain together to 
form bigger messes (er I mean solutions).  ;)

    Now for a different topic:

    We have been working at CHRONOS  to make our services and procedures 
as well exposed as possible.  For grid environments we are working with 
GEON and for the wider unauthenticated world this means web services.  
We have also been looking at ways to expose our procedures as ReST 
(REpresentational STate architectural) so that a larger audience of 
people could call upon the services to use.   

Has anyone talked about doing a ReST actor for Kepler?
    I don't want to get into a SOAP vs ReST debate..  since I am really 
more of  SOAP supporter anyway but let me just bullet out some ideas.

a) ReST is a way doing things, not a defined API, so we have problems 
like: "there is no way to really know before hand what the input and 
output parameters and types are"

(at this point someone might say, just use the File Reader actor, and 
put in your ReSTfull URL and get back your XML and deal with that in the 
normal work flow, but this doesn't allow me to have the ReST resource in 
the middle of a flow getting data too)

b) However, CHRONOS has set up collection of XML and XSL files that 
allow us to know what our input and output parameters are for our ReST 
resources.    Check out:
http://services.chronos.org/searches/    (this is just a test site, not 
a deployed service..  it has bugs and errors)
This page is actually created on the fly from an XSL transform of a 
local XML files we call the Query Description File (QDF).  These are all 
ReST calls made here.   If you want to try it use genus:  gl  and 
species: mitra and select XML as the output, you should get back a 
webrowsets formated result. 

    The QDF contains information regarding input and output vars and 
types of our various ReST "ports" it is in a way our WSDL for the ReST 
stuff.   We use it to dynamically create out the forms interface here. 

c) so...  by extension we could do a QDF -> real WSDL transform and we 
plan to do just this.  There is some debate as to if the WSDL format is 
really set up to correctly describe a ReST resource, but I think it can  
(optimist perhaps).   Plus there is nothing else that we have found that 
is even community supported for describing ReST interfaces (please let 
me know if I have missed something)

d) so... this means that an actor could take this "ReST WSDL file" and 
create an actor that simply constructs the ReST method GET call.


points:
i)  exception handling in this sucks (by virtue of not really 
existing).  This means if this actor failed, the user might not know 
since it would just pass garbage to the next actor which then might 
exception out correctly.
ii)  ReST is, as pointed out, just a way to do things, so it's hard to 
know what the return is.  For us we provide this as an option "Get 
output as" which is also defined in the ReST call and XML (webrowsets 
dtd) is one output option that would then work well in kepler since a 
user could then XSL it to whatever they need give the right XSL file of 
course.
iii) lots of other problems...


ok..  if you have made it this far I guess the short version of this is


1) anyone thought about a ReST actor? 
2) is ReST just too "undefined" to fit well in a workflow system where 
semantics is important?


Anyway, look forward to hearing what people thing about this....
take care
doug