1
Programming SAGAs in SOCK
Ivan LaneseComputer Science Department
University of BolognaItaly
Joint work with Gianluigi Zavattaro
The SOCK saga
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
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
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
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
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
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
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
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
Behaviour primitives
or @z(~y;~x)
o(~x)
or (~x;~y;P )
Output Input
One-way
Request-response
o@z(~y)
and assignment x := e
Behaviour composition operators
P ;Q �P : Q while  do P
P jQ
From sequential languages
From concurrent calculiP
i2W ²i ;Pi
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
P ::= :: : Standard operatorsfP gq Scopethrow(f ) Throw a faultinst(H) Install handlercomp(q) Compensate a scope
The scope hierarchy
P H
q
P H
q
P H
q
P H
q
P H
q
Throwing a fault
q1
q2
(f,Q)
Throw
(f)
(q2,T2)
(q1,T1)
A fault f is raised
by Throw(f)
Throwing a fault
q1
q2
(f,Q)
(q2,T2)
(q1,T1)
f
It propagates upward and
kills the traversed
activities
Throwing a fault
T1
q1
T2
q2
(f,Q)
f
Termination handlers
of parallel activities
are executed
Throwing a fault
T1
q1
T2
q2
Q
f
The fault handler for f
is executed
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
Installing a fault/termination handler
Inst
(f,Q)
Installing a fault/termination handler
(f,Q)
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
Installing compensation handlers
q
q’
Inst
(q,Q)
Installing compensation handlers
q
(q,Q)
q terminates
q’
Installing compensation handlers
(q,Q)
Handlers in q’
can compensate
q using comp(q)
q’
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
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
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
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
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
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
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
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
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
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
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
Extracting the structure of compensations
[[0]]r = 0
[[A%B ]]r = comp(a)
[[P ;Q ]]r = [[Q ]]r ; [[P ]]r
[[P jQ ]]r = [[P ]]r j [[Q ]]r
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
[[A%B ]] = fAr @lA (:::)ga
[[A%B ]] = fAr @lA ([a 7! f :::;Br @lB gb])ga
[[A%B ]] = fAr @lA ([a 7! f inst([c7! throw(f )]);Br @lB gb])ga
Composing basic activities
The mapping is homomorphic[[0]] = 0
[[P ;Q ]] = [[P ]];[[Q ]]
[[P jQ ]] = [[P ]]j [[Q ]]
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
[[f[P ]g]] = f :::;[[P ]]gu
[[f[P ]g]] = f inst([c7! [[P ]]r ; : : :]);[[P ]]gu
[[f[P ]g]] = f inst([c7! [[P ]]r ;throw(c)]);[[P ]]gu
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)
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)A¡!B¡!
f[A%B;C%D]g
f[A%B;C%D]g ! ¡
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
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?
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
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
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
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
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
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?
The end
