Managing faults and compensations in SOCK

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

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

3
Roadmap

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

4
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

5
Service behaviour syntax
6
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

7
Roadmap

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

8
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

9
Linguistic extensions

• We add some constructs to SOCK to manage faults
• At runtime the scope will also contain the active
  handlers PHq

10
The scope hierarchy
11
Throwing a fault
(f,Q)
q2
(q2,T2)
q1
Throw (f)
(q1,T1)
12
Throwing a fault
(f,Q)
f
q2
(q2,T2)
q1
(q1,T1)
13
Throwing a fault
(f,Q)
f
q2
T2
q1
T1
14
Throwing a fault
Q
f
q2
T2
q1
T1
15
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,

16
Installing an handler
Handlers can be installed dynamically
Inst (f,Q)
17
Installing an handler
Handlers can be installed dynamically
(f,Q)
18
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

19
Installing compensation handlers
q
q
Inst (q,Q)
20
Installing compensation handlers
q
Q terminates
q
(q,Q)
21
Installing compensation handlers
q
(q,Q)
Handlers in q can compensate q using comp(q)
22
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

23
Roadmap

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

24
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

25
Modeling the automotive case study in SOCK
26
Adding tow truck faults
27
Screenshots from JOLIE
28
Screenshots from JOLIE
29
Roadmap

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

30
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

31
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

32
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

33
End of talk

• Thanks!

• Questions?

34
Adding car rental faults