On 9/14/07, Lavanya Ramakrishnan <[EMAIL PROTECTED]> 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.). -- [EMAIL PROTECTED] http://mult.ifario.us/
