[kepler-dev] thanks and ReST

[Ilkay Altintas]

Doug, Matt,

I think this is a great idea. This also brings back to my mind a 
discussion with Bertram on designing a language for command 
description. Maybe something like this would also help for the Rest 
actor.

I don't know much about the exact format of the outputs but it would 
also be good to add an actor/functionality to parse the output of the 
rest actor. So the Rest GET actor just takes the description and brings 
the output and the parser makes it useful to the rest of the world. I'm 
not sure if this makes sense though. Doug?

-ilkay


On Dec 9, 2004, at 11:58 AM, Matt Jones wrote:

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