ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Brown" <paulrbr...@gmail.com>
Subject Re: Management APIs
Date Sat, 15 Sep 2007 06:05:06 GMT
On 9/14/07, Lavanya Ramakrishnan <laramakr@cs.indiana.edu> wrote:
>  Thanks for your quick and detailed responses. And sorry about asking so
> many questions at once ... :-)

That's what user@ is for!

> Keeping with the spirit of "asking a lot", how hard would it be to expose
> this through the Management API? If I decide to go with using Apache ODE,
> I will be happy to help but I need to get a sense of how much work this
> might involve?

It's easy -- the API and the implementation are already there; you
just have to do the work of running the wiring from that API back up
to the management facade and updating the web services.

> The BPEL workflows I am working with right now are Grid scientific
> workflows that have a huge amount of variability in the underlying
> resources. What I am looking at (actually for my Phd thesis) is building
> planning and dynamic adaptation capabilities atop a BPEL workflow engine
> which can manipulate workflow (pre-execution and real-time) to bypass some
> of these failures. In the event of the failure, I would like an external
> service to be invoked. This service might make any corrections necessary
> before invoking possibly a recoverActivity. I am looking at available BPEL
> engines to see how much management support is available that might meet a
> majority of my requirements.

Are these Globus workflows?  Via WS-GRAM or other means?  I don't know
if you've thought about it, but WS-GRAM might make a natural place to
create a boundary of sorts (along the lines of Alex's suggestion about
BPEL4People);   Also, because of the security considerations, WS-GRAM
doesn't fit well as a direct web service invocation from a BPEL
process without some additional decoration.

So, maybe something like:

(BPEL process 1) --normal invoke-> (QOS process 2) --synthetic
invoke-> WS-GRAM resource

where process 1 is the scientific workflow and process 2 contains
QOS-oriented behavior (fail from resource to resource, stage or
re-stage data, etc.).


View raw message