[kepler-dev] thanks and ReST
fils at iastate.edu
Thu Dec 9 08:21:01 PST 2004
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.
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
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....
More information about the Kepler-dev