1 The SOCK SAGA Ivan Lanese Computer Science Department University of Bologna Italy Joint work with...
-
date post
19-Dec-2015 -
Category
Documents
-
view
217 -
download
3
Transcript of 1 The SOCK SAGA Ivan Lanese Computer Science Department University of Bologna Italy Joint work with...
1
The SOCK SAGA
Ivan LaneseComputer Science Department
University of BolognaItaly
Joint work with Gianluigi Zavattaro
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
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
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
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
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
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
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
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
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
P ::= :: : Standard operatorsfP gq Scopeinst(H) Install handlercH Retrieve previous handlerthrow(f ) Throw a faultcomp(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 Available handlers are installed before any fault is
managed– Always the most updated handler is used
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)
– Only other handlers can do it
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
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
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
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
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
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
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
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
Nested SAGA {[P]}
Succeeds if P succeeds or fails– If P succeeds the compensation is installed
Crashes if P crashes
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
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
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
[[f[P ]gu ]]r = comp(u)
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
[[A%B ]] = fAr @zA (:::)ga
[[A%B ]] = fAr @zA ([a 7! f :: :;[[B ]]gb])ga
[[A%B ]] = fAr @zA ([a 7! f inst([f 7! throw(c)]);[[B ]]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 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
[[f[P ]gu ]] = f :::;[[P ]]gu
[[f[P ]gu ]] = f inst([:::;u 7! [[P ]]r ]);[[P ]]gu
[[f[P ]gu ]] = f inst([f 7! [[P ]]r ; inst([u 7! 0]);u 7! [[P ]]r ]);[[P ]]gu
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)
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
f[A%B;C%D]gu
f[A%B;C%D]gu ! ¡
A¡!B¡!
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
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
Future work
Complete our quest Understand relationship between different approaches to
compensations– Static vs dynamic
– Hierarchical vs flat
The end