1. 1 Ivan Lanese Computer Science Department University of Bologna Italy On the expressive power of primitives for compensation handling Joint work with Catia Vaz and Carla Ferreira

2. Map of the talk l Comparing primitives for compensations l A hierarchy of calculi l Encoding parallel recovery l An impossibility result l Conclusions

3. Map of the talk l Comparing primitives for compensations l A hierarchy of calculi l Encoding parallel recovery l An impossibility result l Conclusions

4. Error handling l We want to compose services to create complex applications l Safe composition of services requires to deal with faults –No guarentee on services’ behaviour because of loose coupling –Disconnections, message losses, … l A fault is an abnormal situation that forbids the continuation of an activity –An activity that generates a fault is terminated l Faults should be managed so that the whole system reaches a consistent state

5. Compensation handling l Managing errors require to undo previously completed activities l Undoing can not be perfect –Some activities can not be undone –Impossible to lock resources for long times l The programmer defines some code (the handler) to take the system to a consistent state l Handlers are associated to long-running transactions –Computations that either succeed or are compensated –Weaker requirement w.r.t. ACID transactions

6. Different proposals l Different calculi and languages provide primitives for fault and compensation handling –BPEL, Sagas, StAC, cjoin, SOCK, dcπ, webπ, … l Are the proposed primitives equivalent? l Which are the best ones?

7. A difficult problem l Approaches to compensation handling can differ according to many features –Flat vs nested transactions –Automatic vs programmed kill of subtransactions –Static vs dynamic definition of compensations l Approaches applied to different underlying languages –Differences between the languages may hide differences between the primitives

8. Our approach l Taking the simplest possible calculus (π-calculus) l Adding different primitives to it l Comparing their expressive power looking for compositional encodings l Try to export the results to the original calculi l Too many possible differences l We concentrate on static vs dynamic definition of handlers –Other differences will be considered in future work

9. Static approach l The error recovery code is fixed –Java try P catch e Q –Whenever a fault is triggered inside P code Q is executed l For a more fine-grained control –One can use nested try-catch blocks »More complex code –Or Q has to check the state to understand when the fault happened »Need for auxiliary variables, race conditions problem l This is the approach of Java, Webπ, πt-calculus, conversation calculus

10. Dynamic approach l The error recovery code can be updated during the computation –Requires a specific primitive for doing the update l Parallel recovery: new error recovery processes can be added in parallel –This is the approach of dcπ and the approach of Sagas and StAC for parallel activities l General dynamic recovery: a (higher-order) function can be applied to the error recovery code –This is the approach of SOCK –BPEL, Sagas and StAC use backward recovery for sequential activities »It is a particular form of general dynamic recovery

11. Map of the talk l Comparing primitives for compensations l A hierarchy of calculi l Encoding parallel recovery l An impossibility result l Conclusions

12. A hierarchy of calculi P ::= 0 inaction Σ i π i.P i guarded choice !π.P guarded replication P|Q parallel composition (νx)P restriction t[P,Q] transaction protected block X process variable inst[λX.Q].P compensation update

13. l Transactions can compute l Transactions can be killed l Transactions can suicide l Protected code is protected Simple examples: static compensations a h b ij t [ a ( x ) : x : 0 ; Q ] ! 0 j t [ b : 0 ; Q ] t j t [ a : 0 ; Q ] ! h Q i t [ t : 0 j a : 0 ; Q ] ! h Q i t [ t : 0 jh a : 0 i ; Q ] ! h a : 0 ijh Q i

14. l Parallel update l Sequential update l Compensation deletion Simple examples: compensation update t [ i ns t b ¸ X : P j X c. a : 0 ; Q ] ! t [ a : 0 ; P j Q ] t [ i ns t b ¸ X : b : X c. a : 0 ; Q ] ! t [ a : 0 ; b : Q ] t [ i ns t b ¸ X : 0 c. a : 0 ; Q ] ! t [ a : 0 ; 0 ]

15. Race conditions l Should never happen that an action has been performed and its compensation has not been installed l Otherwise in case of fault the compensation is not the desired one l Compensation update should have priority w.r.t. normal actions

16. Classes of calculi l General dynamic recovery l Parallel recovery –All compensation updates have the form λX. Q|X l Static recovery –Compensation updates are never used l General dynamic recovery is more expressive than parallel recovery l Parallel recovery and static recovery have the same expressive power

17. Map of the talk l Comparing primitives for compensations l A hierarchy of calculi l Encoding parallel recovery l An impossibility result l Conclusions

18. Encoding parallel update [[ t [ P ; Q ]]] p 2 s = ( ºr ) t [[[ P ]] p 2 s ; [[ Q ]] p 2 s j r ] [[ i ns t b ¸ X : Q j X c : P ]] p 2 s = [[ P ]] p 2 s jh r : ([[ Q ]] p 2 s j r ) i l Other constructs are mapped to themselves l Each transaction has an associated name r l Compensations are stored in the code, protected and guarded by r l Output on r is added to the static compensation and regenerated by stored compensations

19. Example of the encoding

20. Sample execution ( ºr ) t £ b oo k : h r : ( un b oo k j r ) ij pay : h r : ( re f un d j r ) i ) ; 0 j r ] b oo k ¡¡¡ ! ( ºr ) t £ h r : ( un b oo k j r ) ij pay : h r : ( re f un d j r ) i ) ; 0 j r ] pay ¡¡ ! ( ºr ) t £ h r : ( un b oo k j r ) ijh r : ( re f un d j r ) i ) ; 0 j r ] t ¡ ! ( ºr ) h r : ( un b oo k j r ) ijh r : ( re f un d j r ) i ) jh r i ¿ ¡ ! ( ºr ) h r : ( un b oo k j r ) ijh ( re f un d j r ) i ) ¿ ¡ ! ( ºr ) h ( un b oo k j r ) ijh re f un d i ) un b oo k ¡¡¡¡ ! ( ºr ) h ( r ) ijh re f un d i ) re f un d ¡¡¡¡¡ ! ( ºr ) h ( r ) ijh 0 i )

21. Properties of the encoding l The encoding is defined by structural induction on the term l The process to be encoded is weakly bisimilar to its encoding –For processes that do not install compensations at top-level l The encoding does not introduce divergency

22. Map of the talk l Comparing primitives for compensations l A hierarchy of calculi l Encoding parallel recovery l An impossibility result l Conclusions

23. Conditions for compositional encoding 1. Parallel composition mapped into parallel composition 2. Well-behaved w.r.t. substitutions 3. Transactions implemented by some fixed context lWith transaction name as a parameter 4. Process to be encoded should testing equivalent to its encoding lOnly for well-formed processes lWeaker than asking weak bisimilarity 5. Divergency not introduced

24. Are the conditions reasonable? l These or similar conditions have been proposed in the literature [Gorla, Palamidessi] l Testing equivalence only for well-formed processes –Processes that do not install compensations outside transactions –Otherwise those compensations can be observed –Those compensations can never be executed l Sanity check: our previous encoding satisfies these properties

25. Impossibility result l There is no compositional encoding of general dynamic recovery into static recovery l Idea of the proof –With general dynamic recovery it is possible to understand the order of execution of parallel actions by looking at their compensations –With static or parallel recovery this is not possible l The process has a trace a,b,t,b’ but no trace a,b,t,a’ l This behaviour can not be obtained using static recovery t [ a : i ns t b ¸ X : a 0 : 0 cj b : i ns t b ¸ X : b 0 : 0 c ; 0 ]

26. Map of the talk l Comparing primitives for compensations l A hierarchy of calculi l Encoding parallel recovery l An impossibility result l Conclusions

27. Application: dcπ l Dcπ is an asynchronous pi-calculus with parallel recovery l Dcπ can be seen as a fragment of our calculus with parallel update of compensations l The encoding works also in the asynchronous case, thus dcπ can be mapped into its static fragment

28. Application: webπ and webπ ∞ l Webπ ∞ is an asynchronous fragment of our calculus with static recovery l It is not possible to implement general dynamic recovery on top of it l It is possible to implement parallel recovery l Webπ has timed transactions, which add an orthogonal expressiveness dimension

29. Application: c-join l C-join is a calculus with static recovery based on join –Also some features of parallel recovery, since transactions can be merged l Join patterns are more expressive than pi-calculus communication l We conjecture that this gives the additional power required to implement general dynamic recovery

30. Application: Sagas, StAC and BPEL l They use parallel recovery for parallel activities, backward recovery for sequential ones –More than parallel recovery, less than general dynamic recovery –The counterexample used in the impossibility theorem does not apply l Sagas and StAC have no communication, so also observations are different

31. Future work l Many questions still open –Nested vs flat –What about backward recovery? –…–… l We think that a similar approach can be used to answer them

32. End of talk