Error Handling: From Theory to Practice

1. Error Handling: From Theory to Practice Ivan Lanese Computer Science Department University of Bologna/INRIA Italy Joint work with Fabrizio Montesi italianaSoftware s.r.l./IT University of Copenhagen

2. Roadmap • The quest for error handling primitives • Theoretical concerns • Practical concerns • Conclusive remarks

3. Roadmap • The quest for error handling primitives • Theoretical concerns • Practical concerns • Conclusive remarks

4. Our aim • Error handling is a fundamental aspect of calculi and languages for service-oriented computing systems • Many approaches, no one accepted as the “best” one • Which properties make an approach good? • Are those properties the same in theoretical calculi and full-fledged languages?

5. 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 one-way and request-response patterns • Has to deal with interoperability, dynamicity, reconfiguration… • Based on standards for data (XML), communication (SOAP), discovery (WSDL and UDDI) and orchestration (BPEL) • Allows integration of services from different companies

6. Error handling • Safe composition of services requires todeal with faults • Scarce guarentees on service behaviour because of loose coupling • Unexpected events can happen • Faults should be managed so that the whole system can reach a consistent state • Tackled using long-running transactions and compensations

7. Error handling in everydays life • A process Parameters: Fault handler:

8. Some terminology (in the BPEL/Jolie style) • Long-running transaction: transaction that performs approximate rollback in case of error • Handler: piece of code executed for error recovery • Q in the Java code try P catch e Q • Scope: a boundary for handler execution • Scopes may be nested • Fault handler: handler executed in case of internal fault • Termination handler: handler that smoothly terminates an activity in case of an external fault • Compensation: handler for undoing the effects of an activity in case of later fault

9. Process calculi • The complexity of error handling requires formal models • To really understand the behavior of systems • To prove properties • Process calculi are a widely used model of concurrency • In particular for SOC and error handling • Good basis for developing a real language • Allows to experiment and assess different primitives • λ-calculus is the basis of functional languages • Many languages based on π-calculus • E.g., Pict

10. The zoo of calculi for error handling • CSP interrupt operator (Hoare, 1985) • Πt-calculus (Bocchi, Laneve, Zavattaro, 2003) • StAC (Butler, Ferreira, 2004) • cJoin (Bruni, Melgratti, Montanari, 2004) • cCSP (Butler, Hoare, Ferreira, 2004) • SAGAs calculi (Bruni, Melgratti, Montanari, 2005) • Webπ (Laneve, Zavattaro, 2005) • COWS (Lapadula, Pugliese, Tiezzi, 2007) • SOCK (Guidi, Lanese, Montesi, Zavattaro, 2008) • Dcπ (Vaz, Ferreira, Ravara, 2008) • ATc (Bocchi, Tuosto, 2010)

11. Roadmap • The quest for error handling primitives • Theoretical concerns • Practical concerns • Conclusive remarks

12. Desirable properties for calculi • There are too many calculi • Which are the aims those calculi want to achieve? • Which are the interesting dimensions for comparing them? • We consider 4 interesting properties • Full specification • Expressiveness • Intuitiveness • Minimality • Apply to calculi in general, but we concentrate on error handling

13. Full specification • The calculus has to specify the behavior of error handling in all possible cases • Including boundary/rare cases • E.g., what happens if a fault handler throws a fault? • E.g., what happens if a fault happens in parallel to a running request-response service invocation? • Usually, all theoretical models enjoy this property • Easy to check for instance for semantics defined by structural induction • This is not the case for informal specifications • BPEL specification is unclear on many points • Different BPEL implementations have different behaviors

14. Expressiveness • The available primitives should be able to express all the policies that may be needed for programming applications • Difficult to define which are “all the policies” • Normally tackled using encodings and case studies • An encoding of a calculus C1 into C2 proves that C2 is at least as expressive as C1 • Which properties should the encoding preserve? • Gaps in expressiveness can be proved via non-encodability results • A case study shows the suitability of a calculus for a particular application

15. Intuitiveness • The behavior of the primitives should match the intuition of the programmer • (after some training) • Having the calculus following some clear and orthogonal principles strongly helps • E.g., a scope may either fail by throwing a unique fault, or succeed by installing its compensation for later use • Those principles should be defined before formalizing the calculus • Those principles are the base of the manual for the programmer • For complex cases it may be necessary to go back to the specification • It is possible to prove that the calculus semantics really follows those principles

16. Minimality • The calculus should avoid redundant or overlapping primitives • More easy to understand • More easy to prove properties • Having the calculus following some clear and orthogonal principles strongly helps (again!) • One may prove that the calculus is more expressive than its fragments • Difficult result

17. Roadmap • The quest for error handling primitives • Theoretical concerns • Practical concerns • Conclusive remarks

18. From a calculus to a language • Calculi can (should?) be used as a basis for implementing languages • Many examples starting from λ-calculus and π-calculus • Not many examples for error handling in SOC • Which is the difference between a calculus and a full-fledged language? • No easy answer • Languages are used for programming real applications • Personal (not so serious) answer: languages allows comments • Languages should have “something more”

19. Desirable properties for languages • The differences between calculi and languages influence the properties seen before • Minimality less strict, intuitiveness even more important • We devise 3 new properties • Usability • Robustness • Compatibility • Again, we concentrate on error handling • Based on the Jolie experience • A language for programming SOC applications based on the calculus SOCK • With strong support for error handling

20. Usability • The programmer should be able to use the language for its day-by-day programming • Includes expressiveness and intuitiveness • Powerful data handling is needed • Normally not detailed in calculi • The most common patterns should be easy and fast to program

21. Usability in Jolie • SOCK throw primitive has the syntax throw(f) • This becomes throw(f,M) in Jolie • M is some data to be used during error recovery • E.g., information on the fault or an error message • Can be accessed by the handlers • More interesting (but complex!) examples in the paper

22. Robustness • The language should be able to deal with failures in the environment • Network problems, node crashes • Those aspects normally not modelled in calculi • Unless they are dedicated calculi • Programming languages need to manage these • E.g., if a communication chennel breaks a system fault has to be thrown • Jolie runtime support raises a system fault IOexception • This can be managed using the standard SOCK/Jolie handler constructs

23. Compatibility • Real programs have to interact with different, heterogeneous applications • These applications may follow different protocols, in particular for error handling • SOCK/Jolie services ensure notification in case of remote errors • Useful for distributed error handling • Non Jolie services provide no such a guarentee • Jolie engine checks when a connection is closed unexpectedly and provides a notification via IOexception

24. Roadmap • The quest for error handling primitives • Theoretical concerns • Practical concerns • Conclusive remarks

25. Conclusions • Defining a good calculus for error handling in SOC is not easy • Important to follow clear principles • … but there are a lot of good proposals • Defining a good language based on them is even more difficult • … and there are not many proposals around • We have described some of the main issues and pointed out possible approaches • We hope to see new languages for SOC with formal underpinning in the future

26. End of talk Thanks! Any question?