IBM Research – Zurich Process Management Technologies A ...

© 2010 IBM Corporation

A New Semantics for the Inclusive Converging Gateway in Safe Processes

IBM Research – ZurichProcess Management Technologies

Hagen Völzer IBM Research -- Zurich

(aka Or-join)

© 2010 IBM Corporation2 Sep 14, 2010


Or-Join Semantics Problem

� The BPMN (Business Process Model and Notation) standard contains the Or-join gateway

� Precise semantics of the Or-join and its formalization is an open issue

� Semantics needs to define whether an Or-join is enabled in an given state of a BPMN diagram

Or-join

Tokens define the state



Why is this problem interesting?

� Communicating a process to a human– Modeling for documentation– Formalized semantics is mildly interesting (e.g. for teaching the language)

� Communicating a process to a machine– Modeling for automated analysis– Modeling for automated execution– Formalization of semantics is indispensable

� BPMN 2.0 standardization– Unified language for documentation and execution– OMG required formalized execution semantics



Three Problems in One

� Semantics problem: We don’t understand the intended meaning, i.e., behavior, for some diagrams. What is a reasonable behavior for them? (Understanding)

� Formalization problem: We know the meaning, we want to formalize it. (Formal Definition)

� Execution problem: We have a formalization, we want to execute it efficiently (Runtime Algorithm)

� Focus in the literature is on formalization and execution



Contribution

� Derive a new semantics from discussing the intended meaning of Or-joins

� Formalization is straight-forward

� Propose linear-time execution algorithm for new semantics



Outline

� Acyclic diagrams– Semantics through use cases– Formalization problem

� Cyclic diagrams



Or-Join for Closing Or-Splits (1/2)

� Or-split provides conditional concurrent branching

� Or-join should synchronize the active branches (i.e. tokens produced by split)

� The semantics is non-local– Enabling depends on tokens that are not at the join



Or-Join for Closing Or-Splits (2/2)

� Splits and joins may not be exactly paired

� Synchronize tokens that were produced “upstream” of the Or-join



Or-Join for Closing a Combination of And- and Xor-Splits

� Similar to Or-splits– Synchronize tokens that were produced “upstream”

� And- or Xor-join cannot be used directly– Otherwise we get deadlock or lack of synchronization



Soundness

� Deadlock = some tokens are blocked; not enough tokens for execution– Subsequent task does not get executed

� Lack of synchronization = concurrent tokens don’t get synchronized, multiple tokens on a single edge

– Subsequent task get executed twice (or more)

� Soundness = no deadlock and no lack of synchronization

Deadlock Lack of synchronization



Or-join for Correctly Closing any Combination of Splits

� Or-join is the magic that joins two or more paths without creating deadlock or lack of synchronization

– If some combination of And- and Xor-joins could be used, it would blow up the model



Outline

� Acyclic diagrams– Semantics through use cases– Formalization problem

� Cyclic diagrams



Informal Semantics

� Or-join is enabled if– At least one slot is filled– It is not the case that some token “may still arrive” on an empty slot

empty slot

filled slot

Needs interpretation!



State-Based Interpretation

� “May still arrive” = current state of the diagram can evolve into a state where the empty slot gets filled

� Does not yield a proper definition (Van der Aalst, Desel, Kindler 2002)– Def. of gateway enabling becomes dependent on def. of state evolution– Def. of state evolution depends on def. of gateway enabling

� Potential problem for execution engine– there are exponentially many states that the current state can evolve into



Graph-Based Interpretation

� “May still arrive” = there is a directed path from a token to an empty slot

� Inspired by BPMN 1.0 spec– Similar approach suggested by Dumas et al. 2007

� Formalization straight-forward

� Execution simple and efficient



Contribution

� Graph-based interpretation and state-based interpretation are essentially equivalent on acyclic diagrams

– They coincide on all sound diagrams

� Semantics induced by BPEL’s Dead Path Elimination (DPE) is equivalent as well

– DPE is applied to acyclic BPMN diagrams here



Outline

� Acyclic diagrams

� Cyclic diagrams– Semantics– Execution



A Symmetric “Vicious Circle”

j1

j2

� State-based interpretation– j1 is enabled if j2 is not enabled– j2 is enabled if j1 is not enabled– cyclic dependency intrinsic to the diagram

� Graph-based interpretation– Defines deadlock

� How should the diagram behave? --- Unclear.

� Diagram should be sorted out



An Asymmetric “Vicious Circle”

� Technically the same situation

� How should the diagram behave? --- Suggest:– First j1 then j2– Then loop

� Structure makes the difference w.r.t. previous example



Composition Principle

� Formal argument for the suggested behavior:– The behavior of a simple block should not change when nesting it into a simple loop– “Simple block” could be any sound acyclic block– “Simple loop” could be any cyclic sequential block– More general: Any nesting of such blocks should preserve semantics

� Benefits:– Supports modular understanding, composition and analysis– Preserves semantics when mapping from/to BPEL

+



A New Semantics

� How to adapt graph-based semantics to establish the desired behavior?– Graph-based: Or-join waits if there is a path from a token to an empty slot

� Have to rule out the blue paths (witnessing a round error)– In (a), blue path visits the join itself– In (b), blue path visits e.g. s1

• Execution of s1 could bring a second token to Token 1 (lack of synchronization)

� Plain path = a path that does not visit the join under consideration

� Join waits if there is a plain path from a token to an empty slot unless – the path visits a node that has a plain path to a filled slot



Properties of New Semantics (Contributions)

� New semantics – is equivalent with the discussed semantics on sound acyclic graphs– obeys the composition principle– induces intuitive behavior on some cyclic unstructured graphs, e.g.:



Symmetric “Vicious Circle” Revisited

� New semantics still defines a deadlock

� Since intended behavior of this diagram is not clear,– Deadlock can be used to reject this diagram in static analysis



Beware of unstructured loops with multiple Or-joins

� Semantics defines deadlock

� How should this diagram behave?– (a) might suggest first j2 then j1– (b) is the same graph in a different layout– (b) might suggest first j1 then j2– (c) is another layout, better reflecting the symmetry– Intended meaning not clear (independent from layout)

� Can be sorted out by detecting the deadlock



Outline

� Acyclic diagrams

� Cyclic diagrams– Semantics– Execution



Execution Algorithm (Determines Enabling)

� Starting from filled slots of j– All backward-reachable edges in brown, stop at j– Computes the area that does not need to be searched for tokens

� Starting from empty slots of j– All backward-reachable edges in green, stop at j or any brown edge– Computes the area that needs to be searched for tokens

� If there is a token on a green edge, j needs to wait– Otherwise j is enabled

� Takes linear time in the number of edges



Conclusion

� “Vicious circles” exist in “normal” diagrams

� New semantics– is graph-based

• straight-forward formalization and linear-time execution– is modular (obeys composition principle)

• eases understanding, analysis, refactoring, translation to/from BPEL– still induces deadlocks for some diagrams

• There, intended meaning is unclear, diagrams should be sorted out

� This semantics is included in BPMN 2.0

� Semantics is designed for safe processes – i.e., no lack of synchronization

IBM Research – Zurich Process Management Technologies A ...

Documents