1 Ivan Lanese Computer Science Department University of Bologna Italy Managing faults and...

1

Ivan LaneseComputer Science Department

University of BolognaItaly

Managing faults and compensations in SOCK

Joint work with Claudio Guidi, Fabrizio Montesi and Gianluigi Zavattaro

Roadmap

SOCK

Extension for faults and

compensations

The automotive case study

Conclusive remarks

Roadmap

SOCK

Extension for faults and

compensations

The automotive case study

Conclusive remarks

SOCK (Service Oriented Computing Kernel)

One of the core calculi in Sensoria The one that more closely follows current technologies Explores service interactions

– based on one-way and request-response primitives – coordinated using the correlation sets mechanism

Has a 3 layers structure– Service behaviour layer: defines the basic behaviours of

service instances– Service engine layer: deals with state, correlation sets and

instantiation of sessions– Service system layer: composes located engines into a

network

Service behaviour syntax

² : :=s j o(~x) j or (~x;~y;P )

² ::=s j o@z(~y) j or@z(~y;~x)

P ::= 0 Empty process² Output² Inputx := e AssignmentÂ?P : Q If-then-elseP ;Q Sequential compositionP

i2W ²i ;Pi Non-deterministic choice ­ P IterationP jQ Parallel composition

Higher layers

A service engine is:

where c is a correlation set, Pi are processes and Si states

A service system is:

where li are locations

We will concentrate on the service behaviour layer, where error handling is managed

Y ::=c. Pd[(P1;S1)j : : : j(Pn ;Sn)]

E ::=Y1@l1jj : : : jjYn@ln

Roadmap

SOCK

Extension for faults and

compensations

The automotive case study

Conclusive remarks

Error handling

Safe composition of services requires to deal with faults– No guarentee on components’ behaviour because of loose coupling– Disconnections, message losses, …

A fault is an abnormal situation that forbids the continuation of the activity– An activity that generates a fault is terminated

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

Linguistic extensions

We add some constructs to SOCK to manage faults

At runtime the scope will also contain the active handlers: {P;H}q

P ::= :: : Standard operatorsfP gq Scopeinst(u;P ) Install handlerthrow(f ) Throw a faultcomp(q) Compensatea 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)

Throwing a fault

q1

q2

(f,Q)

(q2,T2)

(q1,T1)

f

Throwing a fault

T1

q1

T2

q2

(f,Q)

f

Throwing a fault

T1

q1

T2

q2

Q

f

Killing activities

When a fault propagates activities are killed but For parallel activities the termination handler (if

present) is executed For ongoing solicit-responses the fault is sent to the

partner– The same fault is raised at the partner side

– A solicit-response always receives a response, either normal or faulty

Activities related to error recovery cannot be killed– Handlers, …

Installing an handler

Inst

(f,Q)

Handlers can be

installed dynamically

Installing an handler

(f,Q)Handlers can be

installed dynamically

Dynamic installation of handlers

Allowed for fault and termination handlers New handlers replace the older ones Dynamic installation of termination handlers allows to

update the handler as far as the activity progresses– No need to add auxiliary scopes

The last defined termination handler becomes the compensation handler when the activity terminates

Available handlers are installed before any fault is managed– Always the most updated handler is used

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’

Compensation handlers

Are the last available termination handlers Allow to undo the effect of a successfully terminated

activity Should be activated explicitly by comp(q) Only other handlers can do it

Roadmap

SOCK

Extension for faults and

compensations

The automotive case study

Conclusive remarks

Automotive case study

A car failure forces the car to stop The car service system looks for

– A garage to repair the car

– A tow truck to take the car to the garage

– A car rental to take the driver home

The suitability of the services is checked The services are booked and paid via a bank

Modeling the automotive case study in SOCK

CARP ::= RP j (GP ;TP )

RP ::= book@R(Gcoords;hRacc;R idi );pay@B(hRpr ices;R id;Racci ;Rpayid)

GP ::= book@G(f ailure;hGacc;Gidi );pay@B(hGpr ice;Gid;Gacci ;Gpayid)

TP ::= book@T(hCARcoords;Gi ;hTacc;Tidi );pay@B(hTpr ice;Tid;Tacci ;Tpayid)

Adding tow truck faults

CARP ::= finst(f T;comp(g) j comp(r));( RP j (GP ;TP ) )

gmainRP ::= f : : :grGP ::= f : : :ggTP ::= f

inst(f B ;comp(tb);throw(f T)); fbook@T(hCARcoords;Gi ;hTacc;Tidi );inst(tb;revbook@T(Tid))

gtb;pay@B(hTpr ice;Tid;Tacci ;Tpayid)gt

Screenshots from JOLIE

Screenshots from JOLIE

Roadmap

SOCK

Extension for faults and

compensations

The automotive case study

Conclusive remarks

Conclusions

Formal framework for error handling in SOC– Near to current technologies (BPEL)…

– … which have no formal semantics

Dynamic installation of handlers as main improvement– Allows to merge termination and compensation handlers

– Allows to update the termination handler as the activity progresses

Error situations do not spoil the solicit-response protocol– Either the fault or the normal answer is sent back

A further idea

In WSDL faults can be sent only as answers to solicit-responses– SOCK follows the same approach

Callbacks (mutual invocation) can be used to model solicit-responses – The fault part cannot be mimicked faithfully

– Two different faults instead of the communication of the same one

This can be solved by allowing to send faults in notifications

Possible next steps

Check whether the approach can be applied to the other Sensoria core languages– COWS, SCC…

– They already have error-handling, but more “low-level”

Analyze the effect of faults on the relationship between choreography and orchestration

End of talk

Adding car rental faults

RP ::= f( inst(f R;Rpayid 6= ? ?RrevpayP : 0) jinst(f B ;revbook@R(R id)) jinst(r;(R id = ? ?RbookHandlerP : RredirectP );RpayP ) );RbookP ; inst(r;RredirectP ;Rpayid = ? ?RpayP : 0);RpayP ; inst(r; f inst(f R;RrevpayP );RredirectP gr c)

gr