Retry Scopes to Enable Robust Workflow Execution in Pervasive Environments

  • 541 views
Uploaded on

Recent workflow languages are designed to serve the needs of business processes running in a unambiguous world based on unambiguous data. …

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
541
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 3. Introduction
    Processes running in a real world environment usually have to deal with environment instability and data uncertainty
    E.g. workers and tools are moving around in space
    E.g. network connections breaks down temporary
    Faults 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 smartly
    3
  • 5. Allow Project
    Goal: New programming paradigm for flow-based pervasive applications
    Our vision is that everything can be modeled.
    Design of suitable models
    Execution infrastructure for the models
    Away from programming towards modeling
    • Bringing together BPM and pervasive systems
    4
    http://www.allow-project.eu
  • 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