Programming SAGAs in SOCK

1. Programming SAGAs in SOCK The SOCK saga Ivan Lanese Computer Science Department University of Bologna Italy Joint work with Gianluigi Zavattaro

2. The saga • The world: faults and compensations in SOC • The weapon: SOCK • The treasure: SAGAs • The quest: a mapping • The way back: dynamic SAGAs • Conclusion: and all the activities were compensated

3. The saga • The world: faults and compensations in SOC • The weapon: SOCK • The treasure: SAGAs • The quest: a mapping • The way back: dynamic SAGAs • Conclusion: and all the activities were compensated

4. Service oriented computing (SOC) • A world where applications are programmed by composing entities called services • Distributed over the network • Autonomous and heterogeneous (loosely coupled) • Dynamically searched according to their properties and composed • All managed by standards for interoperability (SOAP, WSDL, UDDI, BPEL, …) • Upon composition services interact via message passing according to WSDL operations • One-way for invoking a service • Request-response for invoking a service and waiting for the response

5. Service oriented computing and faults • Safe composition of services requires to deal with faults • No guarentee on components’ behaviour because of loose coupling • Only what published in the interfaces can be assumed • Disconnections, message losses, … • A fault is an abnormal situation that forbids the continuation of an activity • Approaches based on long running transactions and compensations • A long running transaction cannot backtrack in case of failure (differently from ACID transactions) • Impossible to lock resources for long times, irreversible actions • A compensation is executed to take the system to a consistent state

6. Long running transactions • Different mechanisms are commonly used for defining long running transactions • For instance, BPEL exploits • Fault handlers: specify how to recover from a fault • Termination handlers: specify how to terminate an ongoing activity when reached by a fault from a parallel activity • Compensation handlers: specify how to compensate a successfully terminated activity if requested for fault recovery

7. Formal models for long running transactions • Different formal models have been proposed to analyze long running transactions • Interaction based compensations, extending name passing calculi such as pi-calculus with operators for error handling • Compensable flow composition, analyzing how compensations of simple activities are composed • We compare two models, one for each approach • SOCK for interaction based compensations • SAGAs calculi for compensable flow composition models

8. The saga • The world: faults and compensations in SOC • The weapon: SOCK • The treasure: SAGAs • The quest: a mapping • The way back: dynamic SAGAs • Conclusion: and all the activities were compensated

9. SOCK (Service Oriented Computing Kernel) • A calculus for modelling service oriented systems • Strongly inspired by current technologies… • WSDL, WS-BPEL • Implemented by Jolie • …but featuring a formal LTS semantics • SOCK has three layers: behaviour, engine and system • Faults are managed at behaviour layer

10. x : e = ( ( ) ) ~ ~ ~ @ @ ( ( ) ) ~ ~ ~ P o o z z y y x o o x x y r ; r ; ; Behaviour primitives and assignment

11. P j ? h l d P P Q P Q Q P P i w  ; e :  ² ; o i i W i 2 Behaviour composition operators • From sequential languages • From concurrent calculi

12. d d P S t t : : a n a r o p e r a o r s = : : : f g P S c o p e q ( ) h f h f l T t t r o w r o w a a u ( ) l l h d l H I i t t n s n s a a n e r ( ) C t c o m p q o m p e n s a e a s c o p e Fault handling in SOCK • Fault handling exploits fault/termination/compensation handlers as in BPEL • …but handlers can be installed and updated dynamically • At runtime the scope will also contain the active handlers: {P;H}q

13. q q q q q H H H H H P P P P P The scope hierarchy

14. Throwing a fault A fault f is raised by Throw(f) (f,Q) q2 (q2,T2) q1 Throw (f) (q1,T1)

15. Throwing a fault It propagates upward and kills the traversed activities (f,Q) f q2 (q2,T2) q1 (q1,T1)

16. Throwing a fault Termination handlers of parallel activities are executed (f,Q) f q2 T2 q1 T1

17. Throwing a fault The fault handler for f is executed Q f q2 T2 q1 T1

18. Dynamic installation of handlers • New handlers update the old ones • Allowed for fault and termination handlers • Allows to keep the handler up-to-date as far as the activity progresses • Handler update has priority on other operations • It is never the case that the state has changed and the corresponding handler update has not been performed

19. Installing a fault/termination handler Inst (f,Q)

20. Installing a fault/termination handler (f,Q)

21. Compensation handlers • Allow to undo the effect of a successfully terminated activity • Are the last available termination handlers • Should be activated explicitly by comp(q) • Do nothing if the activity to be compensated has not terminated with success

22. Installing compensation handlers q’ q Inst (q,Q)

23. Installing compensation handlers q’ q terminates q (q,Q)

24. Installing compensation handlers q’ (q,Q) Handlers in q’ can compensate q using comp(q)

25. Faults and request-responses • We don’t want faults to spoil the request-response communication pattern • Faults may happen both at client and service side • A fault at the service side may cause no response message • A fault at the client side may cause the client not to wait for the answer

26. Our approach • At the service side, a running request-response reached by a fault sends a fault notification as answer • The fault is notified to the client side, and the client can perform local recovery actions • A client always waits for the reply, even if reached by a local fault • Furthermore, in case of successful response the receive operation can update handlers to match the state change • or(y,x,H) installs handlers in H only if a successful answer is received

27. The saga • The world: faults and compensations in SOC • The weapon: SOCK • The treasure: SAGAs • The quest: a mapping • The way back: dynamic SAGAs • Conclusion: and all the activities were compensated

28. SAGAs calculi • A language for modelling compensable transactions • Proposed by Bruni, Montanari, Melgratti [POPL’05] • The basic building blocks are compensable actions A%B • That can be composed in sequence and parallel to build a SAGA • Allows to model long running transactions at the high level of abstraction • Different possible semantics • We consider the semantics with interruption and centralized compensation

29. SAGAs semantics • SAGAs are equipped with a labelled big-step semantics • The final result of a SAGA can be • ¤ : success • £ : abort, if the forward flow aborts but the compensation succeeds • ¥ : failure, if both the forward flow and the compensation abort • Labels of the big-steps contain the names of activities completed with success

30. Atomic compensable activity A%B • Succeeds if A succeeds • A as label • Compensation B is installed • Aborts if A aborts • Empty label • No compensation is installed

31. Sequential composition P;P’ • Succeeds if P and P’ succeed • The observation is the sequential composition of observations • Aborts if P aborts • If P succeeds and P’ aborts, P should be compensated • If the compensation of P succeeds then P;P’ aborts • If the compensation of P aborts then P;P’ fails • Sequential activities are compensated in reverse order

32. Parallel composition P|P’ • Succeeds if both P and P’ succeed • The observation is the parallel composition of the observations • Does not succeed if any activity aborts • The other is stopped (interruption) • The activities executed so far are compensated (centralized compensation) • If the compensation succeeds then P|P’ aborts • If the compensation aborts then P|P’ fails • Parallel activities are compensated in parallel

33. The saga • The world: faults and compensations in SOC • The weapon: SOCK • The treasure: SAGAs • The quest: a mapping • The way back: dynamic SAGAs • Conclusion: and all the activities were compensated

34. Why a mapping? • SAGAs are at the high level of abstraction • Good for fast modelling and proving properties • SOCK is at the low level of abstraction • Implemented by Jolie • We want to pass automatically from the SAGA specification to the SOCK implementation • Extract skeletons of SOCK programs defining error handling from SAGAs

35. Idea of the mapping • Activities are implemented by remote services • An operation Ar for each activity A • If the activity succeeds, the service sends back a normal answer • If the activity aborts, the service sends back a fault • We use fault c for abort of activities, f for failures • From a SAGA we extract two components • The structure of the process • The structure of the compensations

36. r [ [ ] ] 0 0 = r [ [ % ] ] ( ) A B c o m p a = r r r [ [ ] ] [ [ ] ] [ [ ] ] P Q Q P ; ; = r r r [ [ j ] ] [ [ ] ] j [ [ ] ] P Q P Q = Extracting the structure of compensations

37. [ [ % ] ] [ [ % f ] ] [ [ % ( f [ ] ] f ( f [ ( [ f ( ) g ( ) ] ) g ] ) g g ] ) g @ l @ l @ l h @ f l @ l A B A B A A B A A B B i t t a n s a c ; r o w ; = = 7 ! = 7 ! 7 ! b b A A A B B r r r r a r a a : : : : : : Mapping basic activities • An activity is a scope containing a call to the corresponding service • If successful the compensation has to be installed • But an abort in the compensation should be treated as a failure

38. [ [ ] ] 0 0 = [ [ ] ] [ [ ] ] [ [ ] ] P Q P Q ; ; = [ [ j ] ] [ [ ] ] j [ [ ] ] P Q P Q = Composing basic activities • The mapping is homomorphic

39. r r [ [ f [ [ [ f ] g [ ] ] ] g ] ] [ [ f f [ ] f g ] ] ( [ ( [ [ [ f [ [ ] ] [ [ ] ] ] ] g ( ] ) ) [ ] [ ) [ [ ] ] g ] ] g h P P P P P P P P i i t t t n s n s c c ; ; ; r o w c ; ; = = = 7 ! 7 ! u u u : : : : : : Mapping SAGAs • A SAGA is a scope • In case of fault the activities executed so far have to be compensated • If the compensation has succeeded then the SAGA aborts

40. Behavioural correspondance • SOCK observations are much more detailed than SAGAs’ ones • We observe only successful answers from request-responses and faults • From the SOCK LTS we extract an abstract LTS • A SAGA S has a big-step with observation O iff its translation can perform all the abstract LTSs compatible with O • The SAGA result is • ¤ iff the translation performs no action with label throw(c) or throw(f) • £ iff the translation performs an action with label throw(c) • ¥ iff the translation performs an action with label throw(f)

41. A B f [ f % [ % % % ] g ] g A A B B C C D D ¡ ¡ ¡ ; ; ! ! ! Example • Consider the SAGA • Suppose A, B and D succeed and C aborts • with observation A;B • Then the translation has a computation with abstract LTS and containing a label throw(c)

42. The saga • The world: faults and compensations in SOC • The weapon: SOCK • The treasure: SAGAs • The quest: a mapping • The way back: dynamic SAGAs • Conclusion: and all the activities were compensated

43. A mismatch • The mapping does not exploit dynamic update of fault handlers • The induced code has not the typical SOCK style • Is it possible to define SAGAs so that the mapping follows the SOCK approach? • Which is the resulting SAGA calculus?

44. Dynamic SAGAs • In SAGAs parallel activities are compensated in parallel • Using the SOCK approach parallel actions are recovered in reverse order of completion (as for sequential actions) • Order of compensations depends on runtime execution • This can be useful: • I can load on a ship iron bars and copper bars in any order • If I loaded iron bars first, I cannot unload them first since they are under the copper bars

45. The results • A dynamic semantics for SAGAs • Able to specify at the high-level of abstraction dynamic compensations • Another mapping, from dynamic SAGAs to SOCK • Exploits dynamic update of handlers • The correctness result remains the same

46. The saga • The world: faults and compensations in SOC • The weapon: SOCK • The treasure: SAGAs • The quest: a mapping • The way back: dynamic SAGAs • Conclusion: and all the activities were compensated

47. Comments • SAGAs can be used to program compensation policies in SOCK • SOCK adds communication/distribution • Exploits automatic fault notification • SOCK is nearer to the implementation • SOCK allows to program other kinds of recovery • Recovery strategy not hard-wired but programmable • But SAGAs provide useful patterns for most common cases

48. Insights on the two models • The encoding provided useful insights on the features of the two models • SAGAs with interrupt and non centralized compensations impossible to implement • Some threads may start the compensation before the failure happens • Dynamic SAGAs is an interesting cross fertilization result

49. Future work • Fully analyze dynamic SAGAs • Understand the relationships between different approaches to compensations • Static vs dynamic • Hierarchical vs flat • Possible to exploit SAGAs for monitoring SOCK programs?

50. The end ...and all the activities were compensated !