1 Ivan Lanese Computer Science Department University of Bologna Italy On the Interplay between Fault...
-
date post
19-Dec-2015 -
Category
Documents
-
view
213 -
download
0
Transcript of 1 Ivan Lanese Computer Science Department University of Bologna Italy On the Interplay between Fault...
1
Ivan LaneseComputer Science Department
University of BolognaItaly
On the Interplay between Fault Handlingand Request-response Service Invocations
Joint work with Claudio Guidi, Fabrizio Montesi and Gianluigi Zavattaro
Roadmap
Idea of the work
Our approach to error handling
– Extending SOCK
– Dynamic installation of handlers
– Interplay with request-response
The automotive case study
Conclusive remarks
Roadmap
Idea of the work
Our approach to error handling
– Extending SOCK
– Dynamic installation of handlers
– Interplay with request-response
The automotive case study
Conclusive remarks
Service Oriented Computing (SOC)
SOC is a paradigm to program distributed applications– Based on the composition of dynamically discovered, loosely-
coupled services– Services interact using the notification and request-response
patterns Allows integration of services from different companies
– Great code reusability Has to deal with interoperability, dynamicity, security,
Quality of Service, reconfiguration… Based on standards for data (XML), communication
(SOAP), discovery (WSDL and UDDI) and orchestration (BPEL)
Error handling
Safe composition of services requires todeal with faults– Scarce guarentees on components’ behaviour
because of loose coupling
– Unexpected events can happen
A fault is an abnormal situation that forbids the continuation of an activity– An activity that generates a fault is terminated
Faults should be managed so that the whole system can reach a consistent state
BPEL offers various mechanisms for error handling
Fault handling mechanisms
Based on the idea of long running transactions– ACID transactions impossible to obtain
– Compensations are used to reach a consistent state
Faults terminate the current activity and trigger recovery activities specified by suitable handlers
Fault handler: executed as answer to a fault Termination handler: executed to smoothly terminate a
parallel activity Compensation handler: executed to undo the effect of an
already completed activity
What we propose?
A formal model for faults and compensations in SOC– Based on the process calculus SOCK– Rigorous LTS semantics
1. Expressive high-level primitives– Mimicking BPEL ones– Allowing for easy management of different kinds of faults
2. Dynamic installation of handlers– The fault handling code is always up-to-date
3. Faults do not spoil request-response communications– Automatic notification in case of server fault– The client always waits the reply from the server– Possible to recover from remote errors
Why process calculi?
Formal methods are necessary to master the complexity of SOC– Different implementations of BPEL have different behaviours
– Standards are only informally defined
– Difficult to understand the interplay between different features
Process calculi allow to unequivocally specify the behaviour of the different mechanisms…– Clarify their semantics and their interactions
– Drive the implementations
… and prove properties of the resulting system– Good behaviour guarenteed
The underlying language
SOCK (Service Oriented Computing Kernel) is a process calculus for SOC
Explores service interactions– Based on notification and request-response primitives
– Composed using standard operators from imperative languages (while, …) and process calculi (parallel composition, …)
Strongly related to current technologies– WSDL, BPEL
But with full formal semantics Driving the implementation of the language JOLIE
Roadmap
Idea of the work
Our approach to error handling
– Extending SOCK
– Dynamic installation of handlers
– Interplay with request-response
The automotive case study
Conclusive remarks
Extending SOCK with faults and compensations
Code boxed into scopes {P}q
– Provide a hierarchical structure
– Define the boundaries of error handling activities
Primitives for:– Throwing faults: throw(f)
– Installing handlers: inst(u,P)
– Invoking compensations: comp(q)
A few other things
More on fault propagation
Recovery activities cannot be killed by other faults– Error recovery activities are always completed
But termination overrides fault handling– Global errors more important than internal ones
After having been killed a scope smoothly terminates– Ongoing communications are terminated
– No more faults can be thrown
Compensation handlers
Allow to undo the effect of an already completed activity– The fault handler of a purchase activity could ask to annul a
previously done payment
Has to be explicitly programmed and invoked– Primitive comp(q)
– Available only inside handlers
– Only child activities can be compensated
Roadmap
Idea of the work
Our approach to error handling
– Extending SOCK
– Dynamic installation of handlers
– Interplay with request-response
The automotive case study
Conclusive remarks
Dynamic fault handling
In all the languages we are aware of handlers are statically installed while programming– Java throw … catch …
– BPEL handlers
Not always easy to write the desired compensation
Example
{ throw(f) | while (i <100) if i%2=0 then P else Q , H}q
We want to compensate each completed execution of P and Q in the reverse order of execution
We need auxiliary variables to track the executions of P and Q– Complex and error-prone
Atomicity problem– Suppose P has been executed but the auxiliary variables have
not been updated yet– If a fault occurs then the last execution of P is not
compensated
Our solution
{ throw(f) | while (i <100) if i%2=0 then P ; inst(f,P’;cH)
else Q ; inst(f,Q’;cH) , H0}q
P’ compensates P, Q’ compensates Q The handlers are dynamically installed cH (for current handler) allows to recover the previous
handler for updating inst is a special primitive that has higher priority than
fault execution– No atomicity problem
Compensation handlers
When an activity terminates the last defined termination handler becomes its compensation handler
Same handling for faults immediatly before activity termination and immediatly after activity termination
Roadmap
Idea of the work
Our approach to error handling
– Extending SOCK
– Dynamic installation of handlers
– Interplay with request-response
The automotive case study
Conclusive remarks
Fault handling and request-response
Request-response is a long lasting interaction Faults on one side influence the other side Two possibilities:
– Faults on server side during the interaction
– Faults on client side while waiting for the answer
Faults on server side
A client asks a payment to the bank, the bank fails In ActiveBPEL the client receives a generic “missing-
reply” exception Our approach
– The exact fault is notified to the client
– The notification acts as a fault for the client
– Suitable actions can be taken to manage the remote fault
Faults on client side
A client asks a payment to the bank, then fails before the answer
In BPEL the return message is discarded Our approach
– The return message is waited for
– The handlers can be updated according to whether or not a non-faulty message is received
– The remote activity can be compensated if necessary
Roadmap
Idea of the work
Our approach to error handling
– Extending SOCK
– Dynamic installation of handlers
– Interplay with request-response
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
(Part of) 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
Feedback from the case study
Easy to write the desired error handling policies All the mechanisms are used
– Useful to allow for frozen variables in handlers code
All unexpected behaviours catched
Roadmap
Idea of the work
Our approach to error handling
– Extending SOCK
– Dynamic installation of handlers
– Interplay with request-response
The automotive case study
Conclusive remarks
Conclusions
Formal framework for error handling in SOC– Near to current technologies (BPEL)…
– … but with formal semantics
Dynamic installation of handlers– Allows to update the termination handler as the activity
progresses
Errors do not spoil the request-response protocol– Either the fault or the normal answer is sent back
– The answer can be used during error recovery
Future work
Check whether the approach can be applied to other languages– Other languages for SOC (COWS, SSCC, CASPIS)
– π-calculus
Study the relationships between different kinds of primitives for fault handling– Static vs dynamic– Hierarchical vs flat