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

Roadmap l The quest for error handling primitives l Theoretical concerns l Practical concerns l Conclusive remarks

Roadmap l The quest for error handling primitives l Theoretical concerns l Practical concerns l Conclusive remarks

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

Service Oriented Computing (SOC) l 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 l Has to deal with interoperability, dynamicity, reconfiguration… l Based on standards for data (XML), communication (SOAP), discovery (WSDL and UDDI) and orchestration (BPEL) l Allows integration of services from different companies

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

Error handling in everydays life l A process Parameters: Fault handler:

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

Process calculi l The complexity of error handling requires formal models –To really understand the behavior of systems –To prove properties l Process calculi are a widely used model of concurrency –In particular for SOC and error handling l 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

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

Roadmap l The quest for error handling primitives l Theoretical concerns l Practical concerns l Conclusive remarks

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

Full specification l The calculus has to specify the behavior of error handling in all possible cases l 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? l Usually, all theoretical models enjoy this property –Easy to check for instance for semantics defined by structural induction l This is not the case for informal specifications –BPEL specification is unclear on many points –Different BPEL implementations have different behaviors

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

Intuitiveness l The behavior of the primitives should match the intuition of the programmer –(after some training) l 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 l Those principles should be defined before formalizing the calculus l Those principles are the base of the manual for the programmer –For complex cases it may be necessary to go back to the specification l It is possible to prove that the calculus semantics really follows those principles

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

Roadmap l The quest for error handling primitives l Theoretical concerns l Practical concerns l Conclusive remarks

From a calculus to a language l 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 l 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 l Languages should have “something more”

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

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

Usability in Jolie l SOCK throw primitive has the syntax throw(f) l 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 l More interesting (but complex!) examples in the paper

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

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

Roadmap l The quest for error handling primitives l Theoretical concerns l Practical concerns l Conclusive remarks

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

End of talk