Retry Scopes to Enable Robust Workflow Execution in Pervasive Environments
0 likes329 views
The document discusses enhancing BPEL with retry and rerun semantics to improve workflow execution in unstable environments. It outlines goals for extending BPEL, necessary design principles, and proposes modeling approaches for accommodating different fault types. The conclusions emphasize the importance of compliance with BPEL’s extension rules and suggest future work for native implementation.
Retry Scopes to Enable Robust Workflow Execution in Pervasive Environments
- 1. Retry Scopes to Enable Robust Workflow Execution in Pervasive Environments2nd Workshop on Monitoring, Adaptation and Beyond (MONA+)November 24, 2009
- 2. OutlineIntroduction1Background Information2Concept & BPEL Realization34Outlook and Conclusion
- 3. IntroductionProcesses running in a real world environment usually have to deal with environment instability and data uncertaintyE.g. workers and tools are moving around in spaceE.g. network connections breaks down temporaryFaults occur at a certain point time. A short time later, the faults would not occur again.Under this assumption, a restart might would result in a successful execution. Therefore, the restart of the steps is a much more performing option, than starting straight off with traditional fault handling, where all work done would be lost.Goals:Extend BPEL with Retry/Rerun semantics
- 4. Extensions should integrate with BPEL smartly3
- 5. Allow ProjectGoal: New programming paradigm for flow-based pervasive applicationsOur vision is that everything can be modeled. Design of suitable modelsExecution infrastructure for the modelsAway from programming towards modelingBringing together BPM and pervasive systems4http://www.allow-project.eu
- 6. What is a flow? (Beyond classical workflows)5
- 7. BPEL Scopes (1)A Scope compasses a set of activitiesA Scope is a unit of workIn BPEL a scope is a unit of fault, compensation, and termination handlingForward recovery by fault handlersSimilar to try … catchAll-or-nothing behavior CompensationTermination handlerScope is terminated if fault occurs in parallel activityIn BPEL a scope is an activity6SequenceEmptyScopeFlowInvoke1Scope
- 9. Retry/Rerun SemanticsRetryWork already done is compensatedRerunWork already done is not compensated8
- 10. Additional RequirementsNo general retry/rerunAs common in BPEL different faults should be treated differentlyE.g. Retry on fault A, rerun on fault B, rethrow on fault CDefinition of the iterationsper faultLimit the number of retries/reruns9
- 11. Design Goals For BPEL ExtensionsNew modeling elements should follow BPEL’s modeling paradigmNew modeling elements should support the required semantics and concise as possibleNew modeling elements shall support the modeler’s work and should be therefore intuitive and comprehensibleNew modeling elements should not define redundant semantics10
- 12. Possible Modeling Approaches (1)Adding a Restart/Rerun property to the BPEL scopeIntroducing a Retry/Rerun Scope (extension activity)Introducing Retry/Rerun extension activities for usage within fault handlerIntroduce a Restart extension activity which simply trigger a restart of the scope11
- 13. Possible Modeling Apporaches (2)12
- 14. ApproachIntroducing a Restart ActivityRerun semantics can be executed by using the restart activity in fault handlerRetry can be executed as combination of normal compensation followed by restartComplies with BPEL’s approach of explicitly modeling compensation, termination and fault handlingDefines no redundant semanticsNot compliant to BPEL’s extension rules, that none of BPEL’s semantics is allowed to be changedUnfortunately, none of the proposed approach would have been 13
- 15. Scope State Transition Extensions14
- 16. Retry Example<faultHandlers> <catch faultName="NoUserFound"> <sequence><compensate/> <wait/><restart times="5" /> </sequence> </ catch></faultHandlers>15
- 17. Rerun Example<faultHandlers> <catch faultName="NoUserFound"> <sequence> <wait/><restart times="5" /> </sequence> </ catch></faultHandlers>16
- 18. ConclusionsRestart activity allows modelers to model retry as well as rerun semanticsSolution fits best into BPEL as possibleCompliance with BPEL’s extension rules not reachableFuture workNative implementation17