Recent workflow languages are designed to serve the needs of business processes running in a unambiguous world based on unambiguous data. In contrast to business processes, processes running in a real world environment have to deal with data uncertainty and instability of the execution environment. Building a workflow language for real world flows based on a workflow language for business processes therefore may need additional modeling elements to be able to deal with this uncertainty and instability. Based on a real world process scenario we analyse and derive requirements for workflow language extensions for real world processes. The contributions provided by this paper are at first to investigate, how a workflow language can be extended properly followed up by the definition of workflow language extensions for real world processes, whereas the extensions are motivated by the real world process scenario. In this paper we use the Business Process Execution Language (BPEL) as extension foundation.

1. Retry Scopes to Enable Robust Workflow Execution in Pervasive Environments2nd Workshop on Monitoring, Adaptation and Beyond (MONA+)November 24, 2009

2. Outline Introduction 1 Background Information 2 Concept & BPEL Realization 3 4 Outlook and Conclusion

4. Extensions should integrate with BPEL smartly3

6. What is a flow? (Beyond classical workflows) 5

7. BPEL Scopes (1) A Scope compasses a set of activities A Scope is a unit of work In BPEL a scope is a unit of fault, compensation, and termination handling Forward recovery by fault handlers Similar to try … catch All-or-nothing behavior Compensation Termination handler Scope is terminated if fault occurs in parallel activity In BPEL a scope is an activity 6 Sequence Empty Scope Flow Invoke1 Scope

8. BPEL Scopes (2) 7

9. Retry/Rerun Semantics Retry Work already done is compensated Rerun Work already done is not compensated 8

10. Additional Requirements No general retry/rerun As common in BPEL different faults should be treated differently E.g. Retry on fault A, rerun on fault B, rethrow on fault C Definition of the iterationsper fault Limit the number of retries/reruns 9

11. Design Goals For BPEL Extensions New modeling elements should follow BPEL’s modeling paradigm New modeling elements should support the required semantics and concise as possible New modeling elements shall support the modeler’s work and should be therefore intuitive and comprehensible New modeling elements should not define redundant semantics 10

12. Possible Modeling Approaches (1) Adding a Restart/Rerun property to the BPEL scope Introducing a Retry/Rerun Scope (extension activity) Introducing Retry/Rerun extension activities for usage within fault handler Introduce a Restart extension activity which simply trigger a restart of the scope 11

13. Possible Modeling Apporaches (2) 12

14. Approach Introducing a Restart Activity Rerun semantics can be executed by using the restart activity in fault handler Retry can be executed as combination of normal compensation followed by restart Complies with BPEL’s approach of explicitly modeling compensation, termination and fault handling Defines no redundant semantics Not compliant to BPEL’s extension rules, that none of BPEL’s semantics is allowed to be changed Unfortunately, none of the proposed approach would have been 13

15. Scope State Transition Extensions 14

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. Conclusions Restart activity allows modelers to model retry as well as rerun semantics Solution fits best into BPEL as possible Compliance with BPEL’s extension rules not reachable Future work Native implementation 17