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

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

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

Service Oriented Computing

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

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

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

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

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

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

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

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

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

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

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

The scope hierarchy P H q P H q P H q P H q P H q

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)

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

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

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

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

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

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

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

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

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

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

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

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