1 Ivan Lanese Computer Science Department University of Bologna Italy Managing faults and compensations in SOCK Joint work with Claudio Guidi, Fabrizio Montesi and Gianluigi Zavattaro

Roadmap l SOCK l Extension for faults and compensations l The automotive case study l Conclusive remarks

Roadmap l SOCK l Extension for faults and compensations l The automotive case study l Conclusive remarks

SOCK (Service Oriented Computing Kernel) l One of the core calculi in Sensoria l The one that more closely follows current technologies l Explores service interactions –based on one-way and request-response primitives –coordinated using the correlation sets mechanism l 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 o r ( ~ x ; ~ y ; P ) ²:: = s j z ( ~ y ) j o z ( ~ y ; ~ x )

Higher layers l A service engine is: where c is a correlation set, P i are processes and S i states l A service system is: where l i are locations l We will concentrate on the service behaviour layer, where error handling is managed Y :: = c. P d [( P 1 ; S 1 ) j ::: j ( P n ; S n )] E :: = Y 1 jj ::: jj Y n

Roadmap l SOCK l Extension for faults and compensations l The automotive case study l Conclusive remarks

Error handling l Safe composition of services requires to deal with faults –No guarentee on components’ behaviour because of loose coupling –Disconnections, message losses, … l A fault is an abnormal situation that forbids the continuation of the activity –An activity that generates a fault is terminated l Faults should be managed so that the whole system reaches a consistent state l 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 l We add some constructs to SOCK to manage faults 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 i ns t ( u ; P ) I ns t a llh an dl er t h row ( f ) T h rowa f au l t 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 )

Throwing a fault q1q1 q2q2 (f,Q) (q 2,T 2 ) (q 1,T 1 ) f

Throwing a fault T1T1 q1q1 T2T2 q2q2 (f,Q) f

Throwing a fault T1T1 q1q1 T2T2 q2q2 Q f

Killing activities l When a fault propagates activities are killed but l For parallel activities the termination handler (if present) is executed l 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 l 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 l Allowed for fault and termination handlers l New handlers replace the older ones l Dynamic installation of termination handlers allows to update the handler as far as the activity progresses –No need to add auxiliary scopes l The last defined termination handler becomes the compensation handler when the activity terminates l 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 l Are the last available termination handlers l Allow to undo the effect of a successfully terminated activity l Should be activated explicitly by comp(q) l Only other handlers can do it

Roadmap l SOCK l Extension for faults and compensations l The automotive case study l Conclusive remarks

Automotive case study l A car failure forces the car to stop l 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 l The suitability of the services is checked l The services are booked and paid via a bank

Modeling the automotive case study in SOCK

Adding tow truck faults

Screenshots from JOLIE

Roadmap l SOCK l Extension for faults and compensations l The automotive case study l Conclusive remarks

Conclusions l Formal framework for error handling in SOC –Near to current technologies (BPEL)… –… which have no formal semantics l Dynamic installation of handlers as main improvement –Allows to merge termination and compensation handlers –Allows to update the termination handler as the activity progresses l Error situations do not spoil the solicit-response protocol –Either the fault or the normal answer is sent back

A further idea l In WSDL faults can be sent only as answers to solicit- responses –SOCK follows the same approach l 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 l This can be solved by allowing to send faults in notifications

Possible next steps l Check whether the approach can be applied to the other Sensoria core languages –COWS, SCC… –They already have error-handling, but more “low-level” l Analyze the effect of faults on the relationship between choreography and orchestration

End of talk

Adding car rental faults