Comparing Two Approaches to Compensable Flow Composition joint work with Michael Butler Carla Ferreira Tony Hoare Hernán Melgratti Ugo Montanari CONCUR

Comparing Two Approaches to Compensable Flow Composition

joint work with

Michael ButlerCarla FerreiraTony HoareHernán MelgrattiUgo Montanari

CONCUR 2005, San Francisco (CA) USA, 23-26 August 2005

Roberto Bruni - Dipartimento di Informatica, Università di Pisa

Comparing Two Approaches

to Compensable Flow Composition 2

Roberto Bruni @ CONCUR 200523-26 Aug. 2005S. Francisco (CA) USA

Roadmap Introduction Background

cCSP Sagas

Informal Discussion Sequential Sagas Parallel Sagas Concluding Remarks & Future Work





cCSP Sagas





Technological Scenario WS composition is an emerging paradigm for application

integration within and across organization boundaries WS is primarily an integration technology and it must bridge the

gap between technologists and business people each WS handles a specific task designed and built by technical people

like a whole car engine, car frame, transmission tasks are combined by business people to solve business level

problems like assembling the engine, the frame and the transmission without having

to look at the many pieces within them Business collaborations can require long-running interactions

a key issue in business processes languages Design of such business processes calls for

graphical presentation rigorous mathematical foundations well-disciplined service composition principles modular implementation




Long-Running Transactions and Compensations

When the transaction is long lasting and interactive, familiar automatic techniques of locking, check-pointing and rollback are not always adequate partial agreements can be reached and locally

committed by parties to be confirmed on success to be compensated in case of failure

to Compensate (Merriam-Webster OnLine) 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

compensation is not rollback




Compensations: Examples A client buys books in an on-line bookstore

the bookstore debits client's account as the payment for the 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 back the account with the amount wrongfully debited and send an apologise letter

Failures on credit checks can cause the abort of parallel activities, e.g.

to unpackage the goods to be sent and to cancel the courier booking

Late cancelling of hotel reservations can involve fees The most important fact: Compensations have a cost!




Contribution Take two recent formalizations Discover the analogies / differences on their core

fragment (hence the current title of the paper)

Show that each presentation style can recover the semantics of the other formalization...

(hence the original title: Reconciling Two Approaches to Compensable Flow Composition)

...but they are not quite the same: From the comparison Four Different Policies for Handling

Compensable Concurrent Processes emerged (yet another possible title...)

three already formalised + a new one the four semantics form a partial order





cCSP Sagas





A Coarse-Grain (Partial) View

Graphical Design

(Diagram enthusiasts)

WS Standards

(XML enthusiasts)

Interaction Patterns

(PC enthusiasts)

INFO

RM

AL

FOR

MA

L

ORCHESTRATION

CHOREOGRAPHY

cJoin (Pisa)

t (Bologna)

web (Bologna)

Compensable Flows

(PA enthusiasts)

StAC

cCSP

Sagas Calculus

A landscape of languages and techniques has emerged

WSFL, BPML, WSCI, XLANG, BPEL4WS, BTP, WS-AT, WS-BP, ...

continuously enriched with new proposals from different vendor coalitions

a babel of ad hoc proposals for standard

poorly disciplined provision of "accessory" features

informal (textual) description of "behaviour"

Formal models are needed

to reason rigorouslyto find specification

bugsto run simulationsto ease verification

Two main approachesFlow Composition or

Hierarchical Patterns a process describes

the control and data flows among WS

a flow engine invokes the services according to the application logic

Two main approaches

Interaction based Composition or Conversational Patterns

services describe the ways they can be engaged in larger processes

separately designed services interact to reach their goals




Orchestration & Choreography

Orchestration is about describing and executing a single view point model

executable framework Choreography

is about describing and guiding a global model (control is shared between domains that are responsible for their tasks)

abstract discipline The entirely deliberate analogy is with

the way in which skilled musicians and dancers co-ordinate their actions while carrying out predetermined instructions

But the distinction can blur in many occasions

On Demand




too many similar constructs

semantics not entirely satisfactory

several variants / improvements

Focus on Compensable Flows

Structured Activity Compensation

(StAC)

Independently developed

Robust formalizations of compensable flow compositions with few key primitives

more abstract than StAC and closer to the spirit of Process Algebras

Butler, Ferreira, et al.

Sagas Calculi

(Sagas)

Bruni, Melgratti, Montanariinspired by SAGASCompensating CSP

(cCSP)

Butler, Ferreira, Hoareinspired by BPEL




Flow Composition

A1

A2 A3

A4

A5

A1 ; ( (A2 ; A3) | A5 ) ; A4




Transactional Flows

A1

A2 A3

A4

A5

[ A1 ; ( (A2 ; A3) | A5 ) ; A4 ]




Compensation Pairs

A1

B1

A2

B2

A3

B3 A4

B4

A5

B5

[ A1 % B1 ; ( (A2 % B2 ; A3 % B3) | A5 % B5 ) ; A4 % B4 ]




Compensation Flow

A1

B1

A2

B2

A3

B3 A4

B4

A5

B5

Note: compensations are to be executed in reverse order

[ A1 % B1 ; ( (A2 % B2 ; A3 % B3) | A5 % B5 ) ; A4 % B4 ]

forward flow

backward flow




cCSP: SyntaxCompensable processes

PP,QQ ::= P % Q | PP + QQ | PP ; QQ | PP | QQ | SKIPP | THROWW | YIELDD

Standard processesP,Q ::= A | [ PP ] | P + Q | P ; Q | P | Q | SKIP | THROW | YIELD

| P Q

() atomic action

sequential composition

choice

parallel composition

normal termination

throw an interrupt

yield to an interrupt

interrupt handler

transaction block compensation pair




A Running Example




A Running Example




PackOrder = |iItems ( PackItem(i) % UnpackItem(i) )

FulfillOrder = BookCourier % CancelCourier | PackOrder | CreditCheck ; ( SKIPP + THROWW )

cCSP: Running Example

OrderTransaction = [ ProcessOrder ]ProcessOrder = (AcceptOrder % RestockOrder) ;

FulfillOrder



Roberto Bruni @ CONCUR 200523-26 Aug. 2005S. Francisco (CA) USA cCSP: Denotational Trace

Semantics each P is assigned a set of traces

set of special events = { , !, ? } (disjoint from ) traces p,q,... are -event-terminated sequences of

actions in . 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 concatenation Note: unlike CSP, prefix traces are not considered

each PP is assigned a set of trace-pairs (p,q) where

p is the forward trace q is the corresponding compensation trace




cCSP Semantics: Basic Processes & Sequential Cmp

A =trace { A, } performs an atomic event and ends ok

SKIP =trace { } terminates successfully

THROW =trace { ! } raises an interrupt

YIELD =trace { ? , } either yields to an interrupt or ends ok

P ; Q =trace { p;q | pP qQ }

wherep ; q = pqp ; q = p if




cCSP Semantics:Parallel Composition

P | Q =trace { r | rp||q pP qQ }

wherep1 || q2 = { r1&2 | rint(p,q) }

Processes running in parallel synchronise on joint termination or on joint interruption

int(p,) = int(,p) = {p} int(Ap,Bq) = { Ar | rint(p,Bq) } { Br | rint(Ap,q) }

1 2 1&

2!

!

!

?

?

!

?

?

!

!

!

?

?

joint terminal event




cCSP Semantics: Transaction Block and Compensation Pairs

[PP] =trace { p | (p,p')PP }

{ pp' | (p!,p')PP }

P % Q =trace { p%q | pP qQ } { (?,) }

where p % q = (p,q)p % q = (p,) if

SKIPP =trace SKIP % SKIP

THROWW =trace THROW % SKIP

YIELDD =trace YIELDD % SKIP




cCSP Semantics: Compensable Sequential and Parallel

PP ; QQ =trace { x;y | xPP yQQ }

where (p,p') ; (q,q') = (pq,q';p')(p,p') ; (q,q') = (p,p') if

PP | QQ =trace { z | zx||y xPP yQQ }

where(p,p') || (q,q') = { (r,r') | rp||q r'p'||q' }




cCSP: Core FragmentCompensable processes

PP,QQ ::= A % B | PP + QQ | PP ; QQ | PP | QQ | SKIPP | THROWW | YIELDD

Standard processesP,Q ::= A | [ PP ] | P + Q | P ; Q | P | Q | SKIP | THROW | YIELD

| P Q

atomic action


choice


normal termination

throw an interrupt

yield to an interrupt

interrupt handler

transaction block compensation pair




Sagas: Core FragmentProcessesP,Q ::= 0 | A % B | PQ | PQ | P ; Q | P | Q | S | try S with P | try S or P | S % P

SagasS,T ::= [ P ]

programmable compensation


internal choice


interrupt handler

transaction block

compensation pair

discriminator

nil

forward recovery

nesting

Any action can succeed or fail

THROW and YIELD are not explicit in the language

big-step SOS semantics two different

compensation policies devised for parallel processes




Naive Sagas: SOS Semantics

An activity A either commits (A ) aborts (A )

A scenario = {A1 ,…, An }

A saga S in either commits ( ) aborts ( ) fails ( )

is the observable concurrent flow

abort = successfully compensated

S

S

S

*

A process P in either commits ( ) aborts ( ) fails ( )

ß, ß’ are installed compensations

<P,ß> < ,ß’>

<P,ß> < ,ß’>

<P,ß> < ,ß’>

*




Revised Sagas: SOS Semantics

An activity A either commits (A ) aborts (A )

A scenario = {A1 ,…, An }

A saga S in either commits ( ) aborts ( ) fails ( )

is the observable concurrent flow

abort = successfully compensated

S

S

S

*

A process P in either commits ( ) aborts ( ) + forced abort fails ( ) + forced fail

ß, ß’ are installed compensations

<P,ß> < ,ß’>

<P,ß> < ,ß’>

<P,ß> < ,ß’>

* *




PackOrder = |iItems ( PackItem(i) % UnpackItem(i) )

FulfillOrder = BookCourier % CancelCourier | PackOrder | CreditCheck ; ( SKIPP + THROWW )

Sagas: Running Example

OrderTransaction = [ ProcessOrder ]ProcessOrder = (AcceptOrder % RestockOrder) ;

FulfillOrder




(Sequential) Sagas: Semantics

(f-cmp)

A , <A%B,ß> < , 0>

<ß,0> < , 0>

*

(saga) <P,0> < , ß>

[P]

<0,ß> < , ß>

0(zero)

A , <A%B, ß> < , B;ß>

A(s-act)

(s-cmp)

A , <A%B,ß> < , 0>

<ß,0> < , 0>

(s-step) <Q,ß’’> < ,ß’>

’ <P,ß> < ,ß’’>

<P;Q, ß> < ,ß’> ;’

(a-step’)

<P;Q,ß> < ,0>

<P,ß> < , 0>

(a-step’’) <P,ß> < , 0>

<P;Q,ß> < ,0>

*

*

On Demand





cCSP Sagas





Sagas vs cCSP I Trace models

interleaving in cCSP (centralized flavour) concurrent in Sagas (distributed flavour)

Executions of activities always successful in cCSP dependent on the context in Sagas

Failures raised by primitive THROW in cCSP raised by activities that fail in in Sagas

Yielding to interrupt both explicit and implicit in cCSP only implicit in Sagas




Sagas vs cCSP II Abnormal termination

successful compensation and abnormal termination of a transaction block are silent to parent processes in cCSP

but not in Sagas where e.g. try S or P can be introduced

Adequacy results via self-cancelling in cCSP

simple and intuitive but imprecise via complex adequacy theorems in Sagas

more precise but less intuitive Compensation policy of parallel processes

coordinated interruption in cCSP no interruption but distributed compensation in Sagas

naive distributed interruption in Sagas revised





cCSP Sagas





Encoding cCSPseq and Sagasseq

Each cCSPseq process defines: a Sagasseq process a particular scenario of execution [[ _ ]] : cCSPseq Sagasseq

Each Sagasseq process defines: a set of cCSPseq processes PP

one for each particular scenario of execution [[ _ ]]_ : Sagasseq cCSPseq




Correspondence Let [[ PP ]] = P ,

If , then =traces [PP] where is obtained by removing all

subscripts from the activities in

Let [[ P ]] = PP If , then =traces [PP]

Remark: is uniquely determined

{P}

{P}




Encoding cCSPseq in Sagasseq

A subtlety: all activities must have different names An auxiliary function is used to rename activities in PP [[ _ ]]_ : cCSPseq N* Sagasseq

[[ PP ]] = [[ PP ]]0

[[ A%B ]]s = As%Bs , {As , Bs } [[ SKIPP ]]s = 0 , [[ YIELDD ]]s = 0 , [[ THROWW ]]s = Ts , {Ts } [[ PP1;PP2 ]]s = P1;P2 , 1 2

where [[ PPi ]]s.i = Pi , i

On Demand




Encoding Sagasseq in cCSPseq

[[ 0 ]] = SKIPP [[ A ] ] A , = A [[ A ] ] A , = THROWW [[ A%B ] ] A , B , = A%B [[ A%B ] ] A , = THROWW [ [ P1;P2 ]] = [ [ P1 ]] ; [ [ P2 ]]

Note: The encoding for compensation pairs is defined only if B commits, because THROW is not allowed as compensation

On Demand





cCSP Sagas





Expected Encoding [[ PP1|PP2 ]]s = P1|P2 , 1 2

where [[ PPi ]]s.i = Pi , i

[ [ P1|P2 ]] = [ [ P1 ]] | [ [ P2 ]]

Unfortunately the semantic correspondence does not work properly in this case!




Coordinated Interruption The difference can be nicely

illustrated in terms of semantic equivalence [ A % A° | B % B° | THROWW ] =traces

1. (A|B) ; (A°|B°)2. (A;A°) | (B;B°)3. SKIP (A;A°) (B;B°) (A|B);(A°|B°)4. SKIP (A;A°) (B;B°) (A;A°)|(B;B°)

cCSP

revised Sagas

naive Sagas

Processes can be stopped when siblings abort,but their compensations is activated only whenall are stopped




Parallel Sagas in cCSP

A1; B1;…;Bj-1;B’j-1;…;B’1 ;A’1

A1; ((B1;…;Bj-1)|C1) ; ((B’j-1;…;B’1)|C’1) ;A’1

…

A1; ((B1;…;Bj-1)|(C1;…;Cm)) ; ((B’j-1;…;B’1)|(C’m;…;C’1)) ;A’1

B1 Bj Bn

C1 Ck Cm

A1 A2

B’1 B’j

A’1

C’1 C’k C’m




No Interruption and Distributed Compensation

The difference can be nicely illustrated in terms of semantic equivalence [ A % A° | B % B° | THROWW ] =traces


cCSP

revised Sagas

naive Sagas

Processes execute until completion, then they can compensate, without waiting for the completion of their siblings




Parallel Sagas: NaïvelyB1 Bj Bn

C1 Ck Cm

A1 A2

B’1 B’j

A’1

C’1 C’k C’m

A1;(B1;…;Bj-1;B’j-1;…;B’1 | C1;…;Cm;C’m;…;C’1);A’1




Distributed Interruption The difference can be nicely

illustrated in terms of semantic equivalence [ A % A° | B % B° | THROWW ] =traces


cCSP

revised Sagas

naive Sagas

Processes can be interrupted and their compensationscan be activated without waiting for the completion of their siblings




Parallel Sagas: Revised

A1;(B1;…;Bj-1;B’j-1;…;B’1 | 0);A’1

A1;(B1;…;Bj-1;B’j-1;…;B’1 | C1;C’1);A’1

…

A1;(B1;…;Bj-1;B’j-1;…;B’1 | C1;…;Cm;C’m;…;C’1);A’1

B1 Bj Bn

C1 Ck Cm

A1 A2

B’1 B’j

A’1

C’1 C’k C’m




No Interruption and Centralised Compensation

The difference can be nicely illustrated in terms of semantic equivalence [ A % A° | B % B° | THROWW ] =traces


cCSP

revised Sagas

naive Sagas

Processes execute until completion, then theyare all compensated if some abort

NEW!




Relating Emerged Policies

cCSP revised Sagas

naive Sagas

Sagaspar1 / cCSPpar1 Sagaspar2 / cCSPpar2

Sagaspar3 / cCSPpar3 Sagaspar4 / cCSPpar4

NEW!




cCSPpari, Sagaspari and Correspondence

cCSPpar1: no yielding cCSPpar2: only parallel yielding cCSPpar4: also parallel yielding Sagaspar1

only three outcomes of Sagaspar2 (commit, abort, fail) different set of SOS rules

Sagaspar3 outcomes of Sagaspar1 plus "forced termination" rules of Sagaspar1 plus an additional one

Correspondence par1: correspondence as for the sequential case par2, par3, par4: slightly rephrased (no unique )

On Demand




cCSPpar1: No Yielding

A % B =trace { p%q | pA qB } { (?,) }

=trace { (A,,B,) } { (?,) }

YIELDD =trace SKIPP =trace { (,) , (?,) }

THROWW =trace { (!,) , (?,) }

p1 || q2 = { r1&2 | rint(p,q) 1,2 {,!} }

On Demand




cCSPpar2: Only Parallel Yielding

A % B =trace { p%q | pA qB } { (?,) }

=trace { (A,,B,) } { (?,) }

YIELDD =trace SKIPP =trace { (,) , (?,) }

THROWW =trace { (!,) , (?,) }

(p,p')||(q,q') = { (r?, ) | rpp'||qq' } { (r,r') | rint(p,q) r' int(p',q') }(p1,p')||(q2,q') = { (r1&2,) | rpp'||qq' }(p,p') || (q,q') = { (r,r') | rp||q r'p'||q' }

On Demand




cCSPpar4: Also Parallel Yielding

(p,p')||(q,q') = { (r?, ) | rpp'||qq' } { (r,r') | rint(p,q) r' int(p',q') }(p1,p')||(q2,q') = { (r1&2,) | rpp'||qq' }(p,p') || (q,q') = { (r,r') | rp||q r'p'||q' }

On Demand





cCSP Sagas





Some Concluding Remarks cCSP and Sagas

abstract away from low-level computations can be easily extended independent from the coordination mechanisms that

implement the primitives Allow to reason about program properties

adequacy process equivalence correctness of implementation

Our research has been valuable in deepening our understanding of the phenomenon of compensable parallel transactions and the range of available design options




Implementation Issues: JSaga

Design as well-formed flow diagrams or as processes in a suitable language or as corresponding (validated) XML

document Automatic generation of coordination

wrappers for invoking involved services in a sound

way for managing commitments and

compensations

Java Signal Core Layer(JSCL)

Java Transaction

al Layer (JTL)

Java Sagas

Layer (JSL)

Sagas Markup Languag

e

Sagas Testing

Environment (STE)




Future Goal: Fully Bridge the Gap between cCSP and Sagas

Extend the comparison to advanced features nesting message passing joint transactions action refinement

Implementation toolkit




References Theoretical foundations for compensations in flow

composition languages R. Bruni, H. Melgratti, U. Montanari (Proc. POPL'05)

Models and languages for global computing transactions H. Melgratti (PhD Thesis, Univ. of Pisa, 2005)

A trace semantics for long-running transactions M. Butler, C. Ferreira, T. Hoare (Proc. 25 Years of CSP)

Executable Semantics for Compensating CSP M. Butler, S. Ripon (Proc. WS-FM 2005)

From Theory to Practice in Transactional Composition of Web Services (Proc. WS-FM 2005)

R. Bruni, G. Ferrari, H. Melgratti, U. Montanari, D. Strollo, E. Tuosto

JSagas Tutorial at WS-FM 2005 D. Strollo, N. Zappone




Documents

Comparing Two Approaches to Compensable Flow Composition joint work with Michael Butler Carla Ferreira Tony Hoare Hernán Melgratti Ugo Montanari CONCUR