Fault in the Future

1. Fault in the Future Ivan Lanese Computer Science Department University of Bologna/INRIA Italy Joint work with Gianluigi Zavattaro and Einar Broch Johnsen

2. Map of the talk • Our aim • ABS language • Primitives for compensations • Conclusions

3. Map of the talk • Our aim • ABS language • Primitives for compensations • Conclusions

4. Error handling • Unexpected, dangerous events frequently happen • In Iceland: volcanoes… • In distributed concurrent systems • Unexpected events in distributed systems: • Client or server crash • Lost messages • Values outside the desired range • … • Error handling techniques are needed for programming reliable applications in an unreliable environment • Errors should not cause the crash of the whole application

5. Our approach • Object-oriented languages are going towards concurrent and distributed systems • Asynchronous method calls • Results returned using futures • We want to apply here techniques for error handling inspired from web services (e.g., BPEL) • Activities can fail • Failures are notified to interacting services • Handlers are defined for managing faults • Activities may be compensated

6. Compensations • Perfect rollback is not always possible • Sending of an e-mail • Sometimes not even desirable • If you undo an hotel reservation, the hotel may want to keep part of the payment • A compensation is an activity for partially undoing a previous activity • Leads to a state which is not the starting one • But it is consistent

7. Our goal • A framework for error handling • For ABS, an object-oriented language based on futures • Allowing notification of remote faults • Going towards distributed management of faults • Allowing to compensate past method executions • With a full formal semantics

8. Motivating scenario • Hotel booking for DISCOTEC 2011 • We assume that each hotel offers a method for online booking • We want a safe trip: in case of volcano eruption we are not going to the conference • We assume a method for monitoring the state of the volcano • Possible errors • Booking may fail: e.g., no rooms are available (or just the server may be down) • Booking has to be annulled in case of volcano eruption (so to get back the money)

9. Map of the talk • Our aim • ABS language • Primitives for compensations • Conclusions

10. ABS language • An object-oriented language • Chosen as specification language inside the HATS European project • Based on asynchronous method calls and futures • Providing cooperative scheduling • Equipped with a full formal semantics based on rewriting logic • Suitable for static analysis

11. Futures • A standard mechanism for allowing asynchronous method calls (cfr. java.util.concurrent) • An asynchronous method call spawns a remote computation but local computation can proceed • The result of the remote computation is stored in a future • The caller checks the future to get the result • It has to block only when it needs the result • The future allows to interact with the remote computation (e.g., kill)

12. ABS basics • S ::= … (standard o-o constructs) f := e!m(e1,…en) (asynchronous invocation) x := f.get (read future) await g do {s} (await) release (processor release) • g is a guard including: • Boolean expressions • Checks for future availability: ?f

13. Booking without error handling • int DISCOTEC(hotelInfo info){f := fron!book(info);…;res := f.get; return res; } • No check for volcano eruption • No facilities for undoing the booking

14. Map of the talk • Our aim • ABS language • Primitives for compensations • Conclusions

15. Error handling in ABS • Failures are possible both on server and on client side • On server side • The invoked method may fail • E.g., no rooms available at Fron • The method execution is interrupted • Failure notified to the caller • It may thus react, e.g., trying to book a different hotel • On client side • The invoking method may fail • E.g., trip annulled because of the volcano • The invocation may become useless or even undesired • Don’t want to pay for the hotel • The invocation should be annulled or compensated

16. Primitives for error handling • Abort for throwing a server side error • Fault notification put in the future • On compensate for installing a compensation • Get is extended with on fail clauses for catching errors • Kill to ask for annulling a method call • Annulled if not already started • Compensated otherwise • Condition ?f in an await guard is true • When the future f contains a value • When the future f contains a fault notification

17. book f on x:=f.get no-room abort no-room Server error example on fail no-room …

18. book f f’ return res kill(f’) f’:=kill(f) return v v … Client error example on compensate

19. Extended syntax • S ::= … (standard ABS) abort n (server abort) return e on compensate s (compensation def) on x:=f.get do s (getting the result) on fail ni si f’:=f.kill (killing a call)await g do {s} (await)

20. Implementing the example: Fron server • Result book(hotelInfo info){avail := localDB.check(info);if (avail == false) then abort no-roomsres := localDB.update(info);return res on compensate r := localDB.undo(info); return r;}

21. Implementing the example: client • Bool DISCOTEC(hotelInfo info){f := fron!book(info);g := volcano_monitor!state(“Grimsvotn”);on state := g.get do if state == “erupting” then f’ := f.kill on fail error screen!print(“Warning: no volcano information”)on res := f.get do return true on compensate f’ := f.kill on fail no-rooms return false on fail Ann return false}

22. Special faults • The programmer can define its own faults • e.g., no-rooms • Ann: when method execution has been annulled • Either killed before it started • Or killed but aborted on its own • NoC: when a method that defines no compensation has been required to compensate

23. Other contributions • Full formal semantics using rewriting logic • Extending ABS semantics • Allows for straightforward implementation • Extension of ABS type system • The client is able to manage all faults it may receive • Standard subject reduction and type safety results hold

24. Map of the talk • Our aim • ABS language • Primitives for compensations • Conclusions

25. Summary • We proposed a new framework for error handling in asynchronous object-oriented languages • It integrates asynchronous method calls, futures, faults and compensations • Fully formalized and well-typed • The approach is quite general, e.g. it can be straightforwardly applied to Java

26. Future work • Extending the ABS implementation with faults and compensations management • Extending the approaches for static analysis based on invariants to take faults and compensations into account • This may shed light on the problem of compensation correctness

27. End of talk Thanks! Questions?