Formal Models for Transactions: Zero Safe Nets

Models and Languages for Coordination and Orchestration IMT- Institutions Markets Technologies - Alti Studi Lucca Formal Models for Transactions: Zero Safe Nets Roberto Bruni Dipartimento di Informatica Università di Pisa

Contents • Orchestration with Petri Nets • Transactions with Zero Safe Nets • From BizTalk to Zero Safe Nets Models and Languages for Coordination and Orchestration

Why Extending Petri Nets • P/T nets can naturally model • control flow • data flow • message passing • The basic P/T net model does not offer any synchronization between transitions • (only token synchronization) • that would be useful for expressing transactions Models and Languages for Coordination and Orchestration

Why Zero-Safe Nets • Zero-Safe Nets offers a basis for modeling distributed transactions and workflows • simple and natural extension of Petri nets • based on a concept easily exportable to other paradigms • offering both refined / abstract views • admit distributed interpreters / implementations • based on unfolding, no backtracking • based on join-calculus • easy to combine with other net flavors (e.g. read arcs) Models and Languages for Coordination and Orchestration

The Idea • Zero-Safe Nets are like P/T Petri nets but places are partitioned in • Stable places • ordinary places defining observable states • Zero-Safe places (or just zero places) • idealized resources • empty in all observable states • temporarily used during transactions (coordinating activities) • Transactions as transition synchronizations • a computation from observable states to observable states via non-stable markings • transactions can end when all tokens in zero places have been consumed Models and Languages for Coordination and Orchestration

Rendez-Vous The message can be sent send receive Models and Languages for Coordination and Orchestration

Rendez-Vous Sender is blocked until message is received send receive Frozen! Models and Languages for Coordination and Orchestration

Rendez-Vous Ready to commit send receive Models and Languages for Coordination and Orchestration

Rendez-Vous Coordinated commit send receive Models and Languages for Coordination and Orchestration

Nondeterministic Rendez-Vous receive send receive Models and Languages for Coordination and Orchestration

Origin of the Name • In classic Petri net Theory • A place a is n-safe if in any reachable marking it contains at most n tokens • A net is n-safe if all its places are such • Thus a place / net is 0-safe if in any reachable marking it is empty! • Useless? • We write zero-safe, not 0-safe • Zero places must be empty in any observable marking Models and Languages for Coordination and Orchestration

From Free-Choice to Non-Deadlocking left right left right turn turn Models and Languages for Coordination and Orchestration

From Free-Choice to Non-Deadlocking left right left right turn turn Success! Models and Languages for Coordination and Orchestration

From Free-Choice to Non-Deadlocking left right left right turn turn Models and Languages for Coordination and Orchestration

From Free-Choice to Non-Deadlocking left right left right turn turn Deadlock! Models and Languages for Coordination and Orchestration

From Free-Choice to Non-Deadlocking left right left right turn turn Only successful choices by design! Models and Languages for Coordination and Orchestration

No Reuse of Stable Tokens Before Commit The message can be sent… send receive Models and Languages for Coordination and Orchestration

No Reuse of Stable Tokens Before Commit …but no-one can receive it! send receive Models and Languages for Coordination and Orchestration

Multicasting a b send new z 2 copy receive reset c Models and Languages for Coordination and Orchestration

Formal Definition • A Zero-Safe net is B=(S,T,pre,post,u0,Z) • NB=(S,T,pre,post,u0) is the underlying P/T Petri net • ZSis the set of zero places • L=S-Z is the set of stable places • u0L is the initial marking • Note: S = (LZ)  LZ • Markings can be represented as pairs (u,x) • uL • xZ Models and Languages for Coordination and Orchestration

uxNBvy (u,)B(v,) [underlying steps] [commit] (u,x)B(v,y) uBv (u,x)B(v,x’) (u’,x’)B(v’,y) [horizontal composition] (uu’,x)B(vv’,y) Operational Semantics • We can exploit the operational semantics (step semantics) of the underlying P/T Petri net NB • The key feature is horizontal composition • it acts as sequential composition on zero places • it acts as parallel composition on stable places Models and Languages for Coordination and Orchestration

Transactions as Transitions • The admissible behaviors of the net are those that can be committed • Such concurrent transactions can be regarded as atomic activities at the higher level of abstraction • In general there can be several P/T Petri nets N such that N  B • We should select an abstract net A(B) which • is an ordinary P/T Petri net • its places are the stable places of B • its transitions are the (minimal) transactions of B • not decomposable in parallel activities • all other steps can be inferred Models and Languages for Coordination and Orchestration

Rendez-Vous send receive B A(B) Models and Languages for Coordination and Orchestration

left right left right turn turn From Free-Choice to Non-Deadlocking turn-L turn-R B A(B) Models and Languages for Coordination and Orchestration

Collective or Individual? • Different philosophies can yield different abstract nets • Define an algebra of computations • Careful axiomatization of horizontal composition * • Select only those computations  such that •  goes from stable marking to stable marking • If there exist , with =  then either = or = • Computations are processes of NB • Select only those processes that satisfy suitable conditions • connected – not decomposable in parallel active processes • all and only minimal / maximal places stable • full – no idle place CTPh ITPh Models and Languages for Coordination and Orchestration

Multicasting CTPh Infinitely many transitions! a b new n+1 3 2 1-1 1-2 1-n … … reset 2 3 n+1 c Models and Languages for Coordination and Orchestration

Multicasting ITPh Infinitely many transitions! a Different copy policies are distinguished! b n+1 new n+1 3 2 1-1 1-2 1-n 1-n … … … reset 2 3 n+1 c n+1 Models and Languages for Coordination and Orchestration

Concurrent Copies receive copy receive send copy receive copy receive Models and Languages for Coordination and Orchestration

Sequential Copies receive receive send copy copy receive copy receive Models and Languages for Coordination and Orchestration

The ITPh “Monster” n 2 … … 2 n B CTPh ITPh Models and Languages for Coordination and Orchestration

drop join fork open close FIFTH HOMEWORK • Show that given any Zero Safe net B, we can always find a corresponding Zero Safe net Bbase that: • Bbase yields the same abstract net as B • and Bbase contains only transitions of the form below: Models and Languages for Coordination and Orchestration

Extensions of Zero-Safe Nets • Read arcs • multiple concurrent reading of the same token • Data values • colored tokens / high level nets • Dynamic net reconfiguration • many others currently under investigation Models and Languages for Coordination and Orchestration

References • Zero-safe nets: comparing the collective and individual token approaches (Information and Computation 156(1-2):46-89, 2000) • R. Bruni, U. Montanari • Extending the zero-safe approach to colored, reconfigurable and dynamic nets (Advances in Petri Nets, LNCS 3098, pp. 321-336, 2002) • R. Bruni, H. Melgratti, U. Montanari Models and Languages for Coordination and Orchestration

Formal Models for Transactions: Zero Safe Nets