1 / 27

Fault in the Future

Fault in the Future. Ivan Lanese Computer Science Department Univers ity of Bologna/INRIA Italy. Joint work with Gianluigi Zavattaro and Einar Broch Johnsen. Map of the talk. Our aim ABS language Primitives for compensations Conclusions. Map of the talk. Our aim ABS language

milica
Download Presentation

Fault in the Future

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related