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