Fault in the future
1 / 27

Fault in the Future - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Fault in the Future' - milica

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

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
Map of the talk

  • Our aim

  • ABS language

  • Primitives for compensations

  • Conclusions

Map of the talk1
Map of the talk

  • Our aim

  • ABS language

  • Primitives for compensations

  • Conclusions

Error handling
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
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
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
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 talk2
Map of the talk

  • Our aim

  • ABS language

  • Primitives for compensations

  • Conclusions

Abs language
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
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
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 talk3
Map of the talk

  • Our aim

  • ABS language

  • Primitives for compensations

  • Conclusions

Error handling in abs
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
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

Server error example



on x:=f.get


abort no-room

Server error example

on fail no-room …

Client error example




return res



return v


Client error example

on compensate

Extended syntax
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
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
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}

Special faults
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
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 talk4
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
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
End of talk