The SOCK SAGA

1. 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 • Conclusion: and all the activities were compensated

3. Quest in progress...

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

5. Service oriented computing and faults • A world where different services interact • Dynamically found and composed • Interaction based on one-way and request-response invocations • Safe composition of services requires to deal with faults • No guarentee on components’ behaviour because of loose coupling • Disconnections, message losses, … • Approaches based on long running transactions and compensations

6. Error handling • A fault is an abnormal situation that forbids the continuation of an activity • Faults should be managed so that the whole system reaches a consistent state • Different mechanisms are commonly used • 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 • Different formal models have been proposed to analyze error handling in SOC • Interaction based compensations, extending name passing calculi 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 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 • 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 • Error handling is 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 ( ) l l h d l H I i t t n s n s a a n e r h d l H R i i t c e r e v e p r e v o u s a n e r ( ) h f h f l T t t r o w r o w a a u ( ) C t c o m p q o m p e n s a e a s c o p e Error handling in SOCK • Error handling exploits fault/termination/compensation handlers • 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 • Available handlers are installed before any fault is managed • Always the most updated handler is used

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) • Only other handlers can do it

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 • If a server is reached by a fault when processing a request-response, the fault is notified to the client • A request-response always sends a response, either normal or faulty • Allows recovery from remote faults • A client always waits for the reply, even if reached by a local fault • or(y,x,H) installs handlers in H only if a successful answer is received

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

27. SAGAs • A language for modelling compensable transactions • The basic building blocks are compensable actions A%B • That can be composed in sequence and parallel… • …and grouped into transactions

28. SAGAs semantics • SAGAs are equipped with a big-step semantics • Observations contain the names of activities completed with success • The final result of a SAGA can be • ¤ : success of the SAGA • £ : failure of the SAGA but success of the compensation • ¥ : crash, i.e. failure of both the SAGA and its compensation

29. Atomic compensable activity A%B • Succeeds with observation A if A succeeds • Compensation B is installed • Fails with no observation if A fails • No compensation is installed

30. Sequential composition P;P’ • Succeeds if P and P’ succeed • The observation is the sequential composition of observations • Fails if P or P’ fail • If P succeeds and P’ fails P should be compensated • If the compensation succeeds the composition fails • If the compensation fails the composition crashes • Different sequential activities are compensated in reverse order

31. Parallel composition P|P’ • Succeeds if P and P’ succeed • The observation is the parallel composition of the observations • Fails if any activity fails • The other is stopped • The activities executed so far are compensated • If the compensation succeeds the composition fails • If the compensation fails the composition crashes • Different parallel activities are compensated in parallel

32. Nested SAGA {[P]} • Succeeds if P succeeds or fails • If P succeeds the compensation is installed • Crashes if P crashes

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

34. Idea of the mapping • Activities are implemented by remote services • If the activity succeeds, the service sends back a normal answer • If the activity fails, the service sends back a fault • We use fault f for failure of activities, c for crashes • SAGAs are anonymous while SOCK scopes have unique names • We give unique names to SAGAs • From a SAGA we extract two components • The structure of the process • The structure of the compensations

35. 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 = r [ [ f [ ] g ] ] ( ) P c o m p u = u Extracting the structure of compensations

36. [ [ % ] ] [ [ % f ] [ ] [ % ( f ] ] [ f f ( [ ( [ f ( ) [ [ g ( ] ] g ) ] ] ) ) g [ [ ] ] g ] ) g @ @ @ f h A B A B A A B A A B B i t t z a z n s a z ; r o w c ; = = 7 ! = ! 7 7 ! b b A A A r r r a 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 a fault in the compensation should be treated as a crash

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

38. r r r [ [ f [ ] g ] ] [ [ f [ f ] g ] ] ( [ [ [ f [ ] g f [ [ ] ] ] ] ( [ f ( [ [ [ [ [ ] ] ] g ] ] ) ] ) [ [ [ [ ] ] g ] ] ] ) [ [ ] ] g f P P P P P P P P P i i i 0 t t t n s n s ; n s u u ; u ; ; = = ! 7 = ! 7 7 ! 7 ! u u u u u u : : : ; : : : ; Mapping SAGAs • A SAGA is a scope • In case of external fault the activities executed so far have to be compensated • In case of internal fault the activities executed so far have to be compensated, and no compensation should be installed

39. Behavioural correspondance • From the SOCK lts we extract an abstract LTS tracking only the successful answers from request-responses • 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 • ¤ or £ iff the translation performs no label throw(c) • ¥ iff the translation performs a label throw(c)

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

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

42. Comments • SAGAs can be used to program compensation policies in SOCK • SOCK adds communication/distribution • Exploits automatic fault notification • SOCK allows to program other kinds of recovery • Different recovery policies for external faults and internal faults • Compensations can be composed in different orders

43. Future work • Complete our quest • Understand relationship between different approaches to compensations • Static vs dynamic • Hierarchical vs flat

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