[kepler-dev] thanks and ReST

[Matt Jones]

Hi Doug,

Thanks for the followup on REST.  I think what you propose is a great 
idea.  Its also closely related to the discussions we've had about 
needing a WSDL-like language for describing commandline applications. 
In this case, we frequently want to wrap existing simulation codes by 
simply invoking them onthe commandline.  We currently do not have a way 
of describing the required inputs and outputs of these codes, but if we 
had one it would make the generation of a useful actor much easier.

I think describing the inputs, which are usually pretty structured, will 
be much easier than describing the outputs, which can at times be more 
like semi-structured reports than data streams.  This is probably true 
for REST services as well.  So it may not be possible to produce the 
formalized decription of the interface that we'd like to see and use for 
semantic processing, but my guess is that it would still help with 
invoking the services.  I also think the techniques for describing the 
REST services would be very similar to that needed for describing 
commandline services.

Matt

Douglas Fils wrote:
> 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
> 
> 
> 
> _______________________________________________
> kepler-dev mailing list
> kepler-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------