1. 1 SOCK and JOLIE from the formal basis to a service oriented programming language Ivan Lanese Computer Science Department University of Bologna Italy Joint work with Claudio Guidi, Fabrizio Montesi and Gianluigi Zavattaro

2. Roadmap l SOCK l Extension for faults and compensations l Jolie l Demo

3. Roadmap l SOCK l Extension for faults and compensations l Jolie l Demo

4. Service Oriented Computing

5. SOCK (Service Oriented Computing Kernel) l A calculus for modelling service oriented systems l Strongly inspired by current technologies… –WSDL, WS-BPEL –Implemented by Jolie l …but featuring a formal LTS semantics –Avoids ambiguities and enables formal analysis –Different BPEL engines implement different behaviours l SOCK explores service interactions –based on one-way and request-response primitives –coordinated using the correlation sets mechanism

6. SOCK layers l SOCK has a 3 layers architecture –Service behaviour layer: defines the basic behaviours of service instances –Service engine layer: deals with state, correlation sets and instantiation of sessions –Service system layer: composes located engines into a network

7. Behaviour primitives o r @ z ( ~ y ; ~ x ) o ( ~ x ) o r ( ~ x ; ~ y ; P ) OutputInput One-way Request-response o @ z ( ~ y ) and assignment x: = e

8. Behaviour composition operators P ; Q  ? P : Q w h i l e d o P P j Q From sequential languages From concurrent calculi P i 2 W ² i ; P i

9. Service engine layer l Each running behaviour is completed by a state l Process definitions are specified, and instantiated on demand l A definition and all its instances are tagged by a correlation set ( P 1 ; S 1 ) P d [( P 1 ; S 1 ) j ::: j ( P n ; S n )] Y = c. P d [( P 1 ; S 1 ) j ::: j ( P n ; S n )]

10. More on correlation sets l A correlation set is a set of variables l When there are many possible receivers for a message… –A definition and an instance –Many instances of the same definition l …the most correlated one receives the message –Roughly a message (2,3) is received by (2,x) over (y,x) if both x and y are in the correlation set l If the definition receives the message a new instance is created

11. Service system layers l A service system is a parallel composition of located service engines Y 1 @l 1 jj ::: jj Y n @l n

12. l A three layered LTS semantics l The behaviour produces all the possible transitions l The service engine discards the transitions non compatible with state and correlation –The transition above is allowed in a state with y=5, not in a state with y=6 l The matching between inputs and outputs is checked at the system level An idea about the semantics x: = y; P ¿ ([ 5 = y ] : [ 5 = x ]) ¡¡¡¡¡¡¡¡ ! P

13. Roadmap l SOCK l Extension for faults and compensations l Jolie l Demo

14. Error handling l Safe composition of services requires to deal with faults –No guarentee on components’ behaviour because of loose coupling –Disconnections, message losses, … l A fault is an abnormal situation that forbids the continuation of an activity l Faults should be managed so that the whole system reaches a consistent state l Different mechanisms are commonly used –Fault handlers: specify how to recover from a fault –Termination handlers: specify how to terminate an ongoing activity when reached by a fault from a parallel activity –Compensation handlers: specify how to compensate a successfully terminated activity if requested for fault recovery

15. Linguistic extensions l We extend SOCK with some operators for fault handling l We allow dynamic installation of handlers l At runtime the scope will also contain the active handlers: {P;H} q P :: = ::: S t an d ar d opera t ors f P g q S cope i ns t ( u ; P ) I ns t a llh an dl er t h row ( f ) T h rowa f au l t comp ( q ) C ompensa t eascope

16. The scope hierarchy P H q P H q P H q P H q P H q

17. Throwing a fault q1q1 q2q2 (f,Q) Throw (f) (q 2,T 2 ) (q 1,T 1 ) A fault f is raised by Throw(f)

18. Throwing a fault q1q1 q2q2 (f,Q) (q 2,T 2 ) (q 1,T 1 ) f It propagates upward and kills the traversed activities

19. Throwing a fault T1T1 q1q1 T2T2 q2q2 (f,Q) f Termination handlers of parallel activities are executed

20. Throwing a fault T1T1 q1q1 T2T2 q2q2 Q f The fault handler for f is executed

21. Faults and request-responses l If a partner of an ongoing request-response is reached by a fault, the fault is notified to the other side –A request-response always sends a response, either normal or faulty l A solicit-response always waits for the reply, even if reached by a local fault l Allow recovery from remote errors

22. Installing an handler Inst (f,Q) Handlers can be installed dynamically

23. Installing an handler (f,Q) Handlers can be installed dynamically

24. Dynamic installation of handlers l New handlers update the old ones l Allowed for fault and termination handlers l Allows to keep the handler up-to-date as far as the activity progresses l Available handlers are installed before any fault is managed –Always the most updated handler is used

25. Installing compensation handlers q q’q’ Inst (q,Q)

26. Installing compensation handlers q (q,Q) Q terminates q’q’

27. Installing compensation handlers (q,Q) Handlers in q ’ can compensate q using comp(q) q’q’

28. Compensation handlers l Allow to undo the effect of a successfully terminated activity l Are the last available termination handlers l Should be activated explicitly by comp(q) –Only other handlers can do it

29. Conclusions l Formal framework for SOC –Near to current technologies (BPEL)… –… but with a formal semantics l Expressive extension for faults and compensations –Dynamic installation of handlers –Faults do not spoil the request-response protocol