Retry Scopes to Enable Robust Workflow Execution in Pervasive Environments2nd Workshop on Monitoring, Adaptation and Beyon...
Outline<br />Introduction<br />1<br />Background Information<br />2<br />Concept & BPEL Realization<br />3<br />4<br />Out...
Introduction<br />Processes running in a real world environment usually have to deal with environment instability and data...
Extensions should integrate with BPEL smartly</li></ul>3<br />
Allow Project<br />Goal: New programming paradigm for flow-based pervasive applications<br />Our vision is that everything...
What is a flow? (Beyond classical workflows)<br />5<br />
BPEL Scopes (1)<br />A Scope compasses a set of activities<br />A Scope is a unit of work<br />In BPEL a scope is a unit o...
BPEL Scopes (2)<br />7<br />
Retry/Rerun Semantics<br />Retry<br />Work already done is compensated<br />Rerun<br />Work already done is not compensate...
Additional Requirements<br />No general retry/rerun<br />As common in BPEL different faults should be treated differently<...
Design Goals For BPEL Extensions<br />New modeling elements should follow BPEL’s modeling paradigm<br />New modeling eleme...
Possible Modeling Approaches (1)<br />Adding a Restart/Rerun property to the BPEL scope<br />Introducing a Retry/Rerun Sco...
Possible Modeling Apporaches (2)<br />12<br />
Approach<br />Introducing a Restart Activity<br />Rerun semantics can be executed by using the restart activity in fault h...
Scope State Transition Extensions<br />14<br />
Retry Example<br />&lt;faultHandlers&gt;<br />  &lt;catch faultName=&quot;NoUserFound&quot;&gt;<br />    &lt;sequence&gt;<...
Rerun Example<br />&lt;faultHandlers&gt;<br />  &lt;catch faultName=&quot;NoUserFound&quot;&gt;<br />    &lt;sequence&gt;<...
Conclusions<br />Restart activity allows modelers to model retry as well as rerun semantics<br />Solution fits best into B...
Upcoming SlideShare
Loading in …5
×

Retry Scopes to Enable Robust Workflow Execution in Pervasive Environments

739 views

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
739
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Retry Scopes to Enable Robust Workflow Execution in Pervasive Environments

  1. 1. Retry Scopes to Enable Robust Workflow Execution in Pervasive Environments2nd Workshop on Monitoring, Adaptation and Beyond (MONA+)November 24, 2009 <br />
  2. 2. Outline<br />Introduction<br />1<br />Background Information<br />2<br />Concept & BPEL Realization<br />3<br />4<br />Outlook and Conclusion<br />
  3. 3. Introduction<br />Processes running in a real world environment usually have to deal with environment instability and data uncertainty<br />E.g. workers and tools are moving around in space<br />E.g. network connections breaks down temporary<br />Faults occur at a certain point time. A short time later, the faults would not occur again.<br />Under this assumption, a restart might would result in a successful execution. <br />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.<br />Goals:<br /><ul><li>Extend BPEL with Retry/Rerun semantics
  4. 4. Extensions should integrate with BPEL smartly</li></ul>3<br />
  5. 5. Allow Project<br />Goal: New programming paradigm for flow-based pervasive applications<br />Our vision is that everything can be modeled. <br />Design of suitable models<br />Execution infrastructure for the models<br />Away from programming towards modeling<br /><ul><li>Bringing together BPM and pervasive systems</li></ul>4<br />http://www.allow-project.eu<br />
  6. 6. What is a flow? (Beyond classical workflows)<br />5<br />
  7. 7. BPEL Scopes (1)<br />A Scope compasses a set of activities<br />A Scope is a unit of work<br />In BPEL a scope is a unit of fault, compensation, and termination handling<br />Forward recovery by fault handlers<br />Similar to try … catch<br />All-or-nothing behavior <br />Compensation<br />Termination handler<br />Scope is terminated if fault occurs in parallel activity<br />In BPEL a scope is an activity<br />6<br />Sequence<br />Empty<br />Scope<br />Flow<br />Invoke1<br />Scope<br />
  8. 8. BPEL Scopes (2)<br />7<br />
  9. 9. Retry/Rerun Semantics<br />Retry<br />Work already done is compensated<br />Rerun<br />Work already done is not compensated<br />8<br />
  10. 10. Additional Requirements<br />No general retry/rerun<br />As common in BPEL different faults should be treated differently<br />E.g. Retry on fault A, rerun on fault B, rethrow on fault C<br />Definition of the iterationsper fault<br />Limit the number of retries/reruns<br />9<br />
  11. 11. Design Goals For BPEL Extensions<br />New modeling elements should follow BPEL’s modeling paradigm<br />New modeling elements should support the required semantics and concise as possible<br />New modeling elements shall support the modeler’s work and should be therefore intuitive and comprehensible<br />New modeling elements should not define redundant semantics<br />10<br />
  12. 12. Possible Modeling Approaches (1)<br />Adding a Restart/Rerun property to the BPEL scope<br />Introducing a Retry/Rerun Scope (extension activity)<br />Introducing Retry/Rerun extension activities for usage within fault handler<br />Introduce a Restart extension activity which simply trigger a restart of the scope<br />11<br />
  13. 13. Possible Modeling Apporaches (2)<br />12<br />
  14. 14. Approach<br />Introducing a Restart Activity<br />Rerun semantics can be executed by using the restart activity in fault handler<br />Retry can be executed as combination of normal compensation followed by restart<br />Complies with BPEL’s approach of explicitly modeling compensation, termination and fault handling<br />Defines no redundant semantics<br />Not compliant to BPEL’s extension rules, that none of BPEL’s semantics is allowed to be changed<br />Unfortunately, none of the proposed approach would have been <br />13<br />
  15. 15. Scope State Transition Extensions<br />14<br />
  16. 16. Retry Example<br />&lt;faultHandlers&gt;<br /> &lt;catch faultName=&quot;NoUserFound&quot;&gt;<br /> &lt;sequence&gt;<br />&lt;compensate/&gt;<br /> &lt;wait/&gt;<br />&lt;restart times=&quot;5&quot; /&gt;<br /> &lt;/sequence&gt;<br /> &lt;/ catch&gt;<br />&lt;/faultHandlers&gt;<br />15<br />
  17. 17. Rerun Example<br />&lt;faultHandlers&gt;<br /> &lt;catch faultName=&quot;NoUserFound&quot;&gt;<br /> &lt;sequence&gt;<br /> &lt;wait/&gt;<br />&lt;restart times=&quot;5&quot; /&gt;<br /> &lt;/sequence&gt;<br /> &lt;/ catch&gt;<br />&lt;/faultHandlers&gt;<br />16<br />
  18. 18. Conclusions<br />Restart activity allows modelers to model retry as well as rerun semantics<br />Solution fits best into BPEL as possible<br />Compliance with BPEL’s extension rules not reachable<br />Future work<br />Native implementation<br />17<br />

×