Formal Languages for Flow Composition and Compensation : cCSP

1. Models and Languages for Coordination and Orchestration IMT- Institutions Markets Technologies - Alti Studi Lucca Formal Languages for Flow Composition and Compensation: cCSP Roberto Bruni Dipartimento di Informatica Università di Pisa

2. Motivation • Key issues in business processes languages for WS • WS Composition, Orchestration, Choreography • WS Transactions • Interesting for both Academy and Industry • A plethora of ad hoc proposals for standard • poorly disciplined provision of "accessory" features • Design of business processes calls for • rigorous mathematical foundations • clean, elegant semantics • well-disciplined service composition principles • modular implementation Models and Languages for Coordination and Orchestration

3. Flow Diagrams meet Process Description Languages • Many proposals to describe business processes unambiguously • XML-based • WSFL, XLANG, WSCI, BPEL4WS • Extensions of known mobile calculi • committed Join, t-calculus, web-calculus • Flow-based • Compensating CSP (Butler, Hoare, Ferreira) • previously Structured Activity Compensation (StAC) • Sagas Calculus (Bruni, Melgratti, Montanari) Models and Languages for Coordination and Orchestration

4. Long-Running Transactions (L-RT) • A L-RT is • an interactive component of a distributed system which must be executed as if it were a single atomic action • In principle (high-level abstraction) • it should not be interrupted or fail in the middle • and it must not be interleaved with other atomic actions of other concurrently executing components of the system • In practice (implementors viewpoint) • it is not easy to keep the illusion alive in (mobile, concurrent) distributed interactive systems! • external interactions may require undo of committed activities • because the transaction is interactive, familiar automatic techniques of check-pointing and rollback are no longer adequate / applicable • the illusion of atomicity for a LRT is achieved with the aid of compensation actions supplied by the programmer Models and Languages for Coordination and Orchestration

5. Compensations • In long lasting negotiations partial agreements can be reached and locally committed by parties • to be compensated in case of failure • to be published / confirmed on success • Formal models are needed • to discover specification bugs • to reason rigorously • to run simulations • to ease verification Models and Languages for Coordination and Orchestration

6. Compensations(Merriam-Webster OnLine) • To Compensate • to neutralize the effect of • to supply an equivalent to • to provide with means of counteracting variation • to offset an error, defect, or undesired effect • The most important fact: • Compensations have a cost! Models and Languages for Coordination and Orchestration

7. Compensations: Examples I • A client buys books in an on-line bookstore • the bookstore debits client's account as the payment for the book order • the bookstore later realizes that one of the book in the client's order is out of print • to compensate the client for this problem, • the bookstore can credit the account with the amount wrongfully debited • and send a letter apologising for their mistake Models and Languages for Coordination and Orchestration

8. Compensations: Examples II • Late cancelling of hotel reservations can involve payment of fees • Failures on credit checks can cause the abort of parallel activities (which can be partially completed) e.g. • to unpackage the goods to be sent • to cancel the courier booking • Statements of politicians typically require an unbounded number of nested compensations Models and Languages for Coordination and Orchestration

9. Sagas • Compensation is important when a system cannot control everything, such as when interaction with other agents (including humans) is involved • Garcia-Molina and Salem exploit the concept of compensation to define the notion of a saga • a saga partitions a L-RT into a sequence of several smaller sub-transactions, where each of the sub-transactions has an associated compensation • If one of the sub-transactions in the sequence aborts, the compensation associated with those committed sub-transactions is executed in the reverse order Models and Languages for Coordination and Orchestration

10. Flow Composition A2 A3 A1 A4 A5 Models and Languages for Coordination and Orchestration

11. Transactional Flows A2 A3 A1 A4 A5 Models and Languages for Coordination and Orchestration

12. CompensationActivities A2 A3 B2 B3 A1 A4 B1 B4 A5 B5 Models and Languages for Coordination and Orchestration

13. A2 A3 B2 B3 A1 A4 B1 B4 A5 B5 Compensation Flow Models and Languages for Coordination and Orchestration

14. Nested Flow Diagrams A2 A3 B2 B3 A1 A4 B1 B4 P Models and Languages for Coordination and Orchestration

15. Approaches • Interaction based Composition, Conversational Patterns or Global Model • Services describe the ways they can be engaged in a larger process • Flow Composition or Hierarchical Patterns • Similar to workflow systems: a process describes the flow of both control and data among WS Models and Languages for Coordination and Orchestration

16. The Road to Compensating CSP • First use of process algebras for modeling compensations: • StAC (Structured Activity Compensation) • by Michael Butler, Carla Ferreira et al. • poorly disciplined, several variants / improvements along the years • Compensating CSP • by Michael Butler, Carla Ferreira, Tony Hoare • robust formalization of compensable flow compositions • closer to the spirit of Process Algebras • few key primitives • inspired by BPEL • and to the independently developed saga calculus Models and Languages for Coordination and Orchestration

17. Compensating CSP: Ingredients • Alphabet of observable actions • ranged by A,B,... • Set of special events = { , !, ? } • ranged by  •  disjoint from  • Interactive processes • Standard processes • ranged by P,Q,... • Compensable processes • ranged by PP,QQ,... Models and Languages for Coordination and Orchestration

18. Compensating CSP: Syntax Standard processes P,Q ::= A | [PP] | P + Q | P ; Q | P || Q | SKIP | THROW | YIELD | P  Q Compensable processes PP,QQ::=P%Q |PP + QQ |PP ; QQ |PP || QQ |SKIPP |THROWW |YIELDD atomic action transaction block compensation pair choice sequential composition parallel composition normal termination throw an interrupt yield to an interrupt interrupt handler Models and Languages for Coordination and Orchestration

19. Compensating CSP: Example PackOrder = ||iItems ( PackItem(i)%UnpackItem(i) ) FulfillOrder = BookCourier%CancelCourier || PackOrder || CreditCheck ; ( Ok ; SKIPP + NotOk ; THROWW ) OrderTransaction = [ ProcessOrder ] ProcessOrder = (AcceptOrder%RestockOrder) ; FulfillOrder Models and Languages for Coordination and Orchestration

20. Compensating CSP:Semantics • Denotational Trace Semantics • defined in a compositional style • each standard process is assigned a set of traces • traces are ranged over by p,q,... • they are -event-terminated sequences of actions • ex. A,B, • each compensable process is assigned a set of trace-pairs (p,q) where • p is the forward trace • q is the corresponding compensation trace Models and Languages for Coordination and Orchestration

21. Compensating CSP:Ordinary Traces • All traces for standard processes have three possible shapes: • A,B, • trace leading to normal termination • A,B,! • trace leading to interrupt throw • A,B,? • trace leading to interrupt yield • pq denotes the trace obtained by juxtaposition • ex. A B, = A,B, = A,B • Note: • unlike trace semantics for CSP, prefix traces are not considered Models and Languages for Coordination and Orchestration

22. Trace Semantics:Atomic Actions For any A we define A =trace { A, } (The process performs a single atomic event and terminates successfully) Models and Languages for Coordination and Orchestration

23. Trace Semantics:Skip SKIP =trace {  } (SKIP immediately terminates successfully) Models and Languages for Coordination and Orchestration

24. Trace Semantics:Throw THROW =trace { ! } (THROW immediately raises an interrupt) Models and Languages for Coordination and Orchestration

25. Trace Semantics:Yield YIELD =trace {  , ? } (YIELD can either yield to a raised interrupt or terminate) Models and Languages for Coordination and Orchestration

26. Trace Semantics:Choice For any standard processes P and Q P + Q =trace P  Q (The semantics for choice is the union of the possible traces of P and Q) Models and Languages for Coordination and Orchestration

27. Trace Semantics:Sequential Composition For any standard processes P and Q P ; Q =trace { p;q | pP  qQ } where the sequential operator is defined on traces by p ; q = pq p ; q = p if    Models and Languages for Coordination and Orchestration

28. SECOND HOMEWORK:Prove or Disprove That: For any standard processes P,Q,R,S P;(Q+R) =trace (P;Q)+(P;R) (P+Q);R =trace (P;R)+(Q;R) (P+Q);(R+THROW) =trace P+Q (P;Q);R =trace (P;Q);R P;SKIP =trace P SKIP;P =trace P P;THROW =trace THROW THROW;P =trace THROW YIELD;YIELD =trace YIELD Models and Languages for Coordination and Orchestration

29. Playful Digression:10 Advanced Proof Methods I • Proof by obviousness • "The proof is so clear that it need not be mentioned." • Proof by lack of sufficient time • "Because of the time constraint, I leave the proof to you." • Proof by general agreement • "All in favor?. . . " • Proof by majority rule • Only to be used if general agreement is impossible • Proof by accident • "Hey, what have we here?!" Models and Languages for Coordination and Orchestration

30. Playful Digression:10 Advanced Proof Methods II • Proof by authority • "Well, Don Knuth says it's true, so it must be!" • Proof by intuition • "I just have this gut feeling. . ." • Proof by intimidation • "Don't be stupid; of course it's true." • Proof by terror • When intimidation fails ... • Proof by deception • "Now everyone turn their backs. . ." Models and Languages for Coordination and Orchestration

31. Trace Semantics:Interrupt Handler For any standard processes P and Q P  Q =trace { pq | pP  qQ } where the interrupt handling is defined on traces by p!  q = pq p  q = p if   ! Models and Languages for Coordination and Orchestration

32. Trace Semantics:Useful Laws for Interrupt For any standard processes P,Q,R (P Q) R =traceP  (Q  R) SKIP  P =traceSKIP YIELD  P =traceYIELD THROW  P =traceP Models and Languages for Coordination and Orchestration

33. Compensating CSP: A Limitation • Synchronous execution of observable actions is not supported (yet) • Concurrency modeled by interleaving • Processes running in parallel can synchronise only • on joint termination • or on joint interruption • The kind of synchronization is decided by just looking at the terminal events of parallel traces • it is convenient to define an operator for deriving the joint terminal event Models and Languages for Coordination and Orchestration

34. Compensating CSP: Joint Terminal Event Let 1 and 2 be the terminal events of two parallel traces Their joint terminal event 1&2 is defined by 1 2 1&2 (& is commutative) ! ! ! ! ? ! !  ! ? ? ? ?  ?    Models and Languages for Coordination and Orchestration

35. Trace Semantics:Parallel Composition For any standard processes P and Q P || Q =trace { r | rp||q  pP  qQ } where p1 || q2 = { r1&2 | rint(p,q) } int(p,) = int(,p) = {p} int(Ap,Bq) = { Ar | rint(p,Bq) }  { Br | rint(Ap,q) } Models and Languages for Coordination and Orchestration

36. Trace Semantics:Useful Laws for Parallel For any standard processes P,Q,R P || Q =trace Q || P (P || Q) || R =trace P || (Q || R) Models and Languages for Coordination and Orchestration

37. Under Which Circumstances? P || Q =trace P;Q + Q;P THROW || (YIELD ; P) =trace THROW + P;THROW Models and Languages for Coordination and Orchestration

38. Trace-Pair Semantics:Compensable Choice For any compensable processes PP and QQ PP + QQ =trace PP  QQ (The semantics for choice is the union of the possible traces of PP and QQ) Models and Languages for Coordination and Orchestration

39. Trace-Pair Semantics:Compensable Parallel For any compensable processes PP and QQ PP || QQ =trace { z | zx||y  xPP  yQQ } where (p,p') || (q,q') = { (r,r') | rp||q  r'p'||q' } Models and Languages for Coordination and Orchestration

40. something wrong? Trace-Pair Semantics:Compensable Sequential For any compensable processes PP and QQ PP ; QQ =trace { x;y | xPP  yQQ } where (p,p') ; (q,q') = (pq,q';q) (p,p') ; (q,q') = (p,p')if    Models and Languages for Coordination and Orchestration

41. Trace-Pair Semantics:Compensation Pair For any standard processes P and Q P %Q =trace{ p%q | pP  qQ } { (?,) } where p % q = (p,q) p % q = (p,)if    Models and Languages for Coordination and Orchestration

42. Trace-Pair Semantics:Compensable Basic Processes SKIPP =trace SKIP % SKIP THROWW =trace THROW % SKIP YIELDD =trace YIELDD % SKIP Models and Languages for Coordination and Orchestration

43. Trace-Pair Semantics:Transaction Block For any compensable process PP [PP] =trace { pp' | (p!,p')PP }  { p | (p,p')PP } Models and Languages for Coordination and Orchestration

44. Trace-Pair Semantics:Other Useful Laws For any composable processes PP;QQ and for any standard processes P,Q PP || QQ =trace QQ || PP (PP || QQ) || RR =trace PP || (QQ || RR) (PP ; QQ) ; RR =trace PP ; (QQ ; RR) PP ; SKIPP =trace PP =trace SKIPP ; PP THROWW ; PP =trace THROWW YIELDD ; (P %Q) =trace (P % Q) Models and Languages for Coordination and Orchestration

45. THIRD HOMEWORK Evaluate the semantics of [ THROWW ] =trace ??? [ YIELDD ] =trace ??? A % A' ; B % B' =trace ??? Prove that: if P,P',Q,Q' terminate successfully, neither raising nor yielding to interrupts, then [ P%P' || Q%Q' || THROWW ] =trace SKIP + (P;P') + (Q;Q') + (P||Q);(P'||Q') Models and Languages for Coordination and Orchestration

46. Is the SemanticsAdequate? • Formal definitions can • lead to conceptual clarifications • make emerge submersed aspects • give insights for language design • The semantics we have seen • is compositional, simple and intuitive • models forward and backward flows • Is it the appropriate one? • Does it match our intuition? • Any other option available? Models and Languages for Coordination and Orchestration

47. Semantics vs Intuition • Expectations: • if no interrupt is raised a "maximal" forward flow should be executed • if an interrupt is raised, • all previously-completed activities are compensated • no consequent activities are executed within that transaction • if an interrupt is raised during the backward flow? • what else? • How can we reasonably conclude that the semantics is "correct"? Models and Languages for Coordination and Orchestration

48. Some Ideas I • P= { p | pP }  P • A successful trace is • either a forward trace with possibly many successful transactions • PP= { p | (p,q)PP } • or a trace with possibly many successfully compensated transactions • PP= { pq | (p!,q)PP } Models and Languages for Coordination and Orchestration

49. Some Ideas II • Theory of "cancellation" • each (forward) A has a compensating (backward) A° • AA° is "essentially" SKIP • but A°A is not SKIP • Theory of "independence" • independent actions can occur in either order • ex. parallel actions A||B • independency, written  , is symmetric • unlike cancelling • independency can be exploited to bring A and A° closer Models and Languages for Coordination and Orchestration

50. Some Ideas III • Abstract effect • A° annihilates A • if we remove all such pairs from a trace, we are left with an abstract residual A(s) • it gives the meaningful actions performed • Take s* and define recursively • A(s) = A(pqr) • if s=pAqA°r and Bq. B A° • A(s) = s • otherwise Models and Languages for Coordination and Orchestration