Fault in the future
Sponsored Links
This presentation is the property of its rightful owner.
1 / 27

Fault in the Future PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Fault in the Future

Ivan Lanese

Computer Science Department

University of Bologna/INRIA


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

  • Primitives for compensations

  • Conclusions

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

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


  • 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

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

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)

Map of the talk

  • Our aim

  • ABS language

  • Primitives for compensations

  • Conclusions

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


  • 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)

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

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

Map of the talk

  • Our aim

  • ABS language

  • Primitives for compensations

  • Conclusions

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

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



on x:=f.get


abort no-room

Server error example

on fail no-room …




return res



return v


Client error example

on compensate

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)

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;}

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” thenf’ := f.killon fail error screen!print(“Warning: no volcano information”)on res := f.get do return true on compensate f’ := f.killon fail no-rooms return falseon fail Ann return false}

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

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

Map of the talk

  • Our aim

  • ABS language

  • Primitives for compensations

  • Conclusions


  • 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

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

End of talk



  • Login