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

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

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

Service oriented computing (SOC) l 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 l All managed by standards for interoperability (SOAP, WSDL, UDDI, BPEL, …) l 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

Service oriented computing and faults l 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, … l A fault is an abnormal situation that forbids the continuation of an activity l Approaches based on long running transactions and compensations l A long running transaction cannot backtrack in case of failure (differently from ACID transactions) –Impossible to lock resources for long times, irreversible actions l A compensation is executed to take the system to a consistent state

Long running transactions l Different mechanisms are commonly used for defining long running transactions l 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

Formal models for long running transactions l 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 l We compare two models, one for each approach –SOCK for interaction based compensations –SAGAs calculi for compensable flow composition models

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

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

Behaviour primitives o z ( ~ y ; ~ x ) o ( ~ x ) o r ( ~ x ; ~ y ; P ) OutputInput One-way Request-response z ( ~ y ) and assignment x: = e

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

Fault handling in SOCK l Fault handling exploits fault/termination/compensation handlers as in BPEL l …but handlers can be installed and updated dynamically l At runtime the scope will also contain the active handlers: {P;H} q P :: = ::: S t an d ar d opera t ors f P g q S cope t h row ( f ) T h rowa f au l t i ns t ( H ) I ns t a llh an dl er comp ( q ) C ompensa t eascope

The scope hierarchy P H q P H q P H q P H q P H q

Throwing a fault q1q1 q2q2 (f,Q) Throw (f) (q 2,T 2 ) (q 1,T 1 ) A fault f is raised by Throw(f)

Throwing a fault q1q1 q2q2 (f,Q) (q 2,T 2 ) (q 1,T 1 ) f It propagates upward and kills the traversed activities

Throwing a fault T1T1 q1q1 T2T2 q2q2 (f,Q) f Termination handlers of parallel activities are executed

Throwing a fault T1T1 q1q1 T2T2 q2q2 Q f The fault handler for f is executed

Dynamic installation of handlers l New handlers update the old ones l Allowed for fault and termination handlers l Allows to keep the handler up-to-date as far as the activity progresses l 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

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

Installing a fault/termination handler (f,Q)

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

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

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

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

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

Our approach l 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 l A client always waits for the reply, even if reached by a local fault l Furthermore, in case of successful response the receive operation can update handlers to match the state change –o r (y,x, H ) installs handlers in H only if a successful answer is received

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

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

SAGAs semantics l SAGAs are equipped with a labelled big-step semantics l 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 l Labels of the big-steps contain the names of activities completed with success

Atomic compensable activity A%B l Succeeds if A succeeds –A as label –Compensation B is installed l Aborts if A aborts –Empty label –No compensation is installed

Sequential composition P;P’ l Succeeds if P and P’ succeed –The observation is the sequential composition of observations l Aborts if P aborts l 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

Parallel composition P|P’ l Succeeds if both P and P’ succeed –The observation is the parallel composition of the observations l 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 l Parallel activities are compensated in parallel

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

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

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

Extracting the structure of compensations [[ 0 ]] r = 0 [[ A % B ]] r = comp ( a ) [[ P ; Q ]] r = [[ Q ]] r ; [[ P ]] r [[ P j Q ]] r = [[ P ]] r j [[ Q ]] r

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

Composing basic activities l The mapping is homomorphic [[ 0 ]] = 0 [[ P ; Q ]] = [[ P ]] ; [[ Q ]] [[ P j Q ]] = [[ P ]] j [[ Q ]]

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

Behavioural correspondance l SOCK observations are much more detailed than SAGAs’ ones –We observe only successful answers from request-responses and faults l From the SOCK LTS we extract an abstract LTS l A SAGA S has a big-step with observation O iff its translation can perform all the abstract LTSs compatible with O l 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)

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

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

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

Dynamic SAGAs l In SAGAs parallel activities are compensated in parallel l Using the SOCK approach parallel actions are recovered in reverse order of completion (as for sequential actions) –Order of compensations depends on runtime execution l 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

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

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

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

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

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

The end