calculi for committed choices and compensations roberto bruni - dipartimento di informatica,...

Calculi for Committed Choices and Compensations Roberto Bruni - Dipartimento di Informatica, Università di Pisa

joint work with

Gianluigi FerrariHernán MelgrattiUgo MontanariDaniele StrolloEmilio TuostoDip. Informatica, Univ. Pisa

Santa Cruz (CA) USA, 18 January 2005

Calculi for Committed Choices

and Compensations 2

Roberto Bruni @ Santa Cruz (CA) USA 18 Jan. 2005

Motivations Design of business processes

rigorous mathematical foundations clean semantics “expressiveness” well-disciplined service composition modular implementation

Web Service Composition defining complex services as

aggregations of simpler services


and Compensations 3


Motivations 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


and Compensations 4


Compensations 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

The most important fact: Compensations have a cost


and Compensations 5


Compensations: Examples 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


and Compensations 6


Approaches Flow Composition or Hierarchical

Patterns Similar to workflow systems: a process

describes the flow of both control and data among WS

Interaction based Composition, Conversational Patterns or Global Model Services describe the ways they can be

engaged in a larger process


and Compensations 7


Flow Composition

A1

A2 A3

A4

A5


and Compensations 8


Transactional Flows

A1

A2 A3

A4

A5


and Compensations 9


Compensation

A1

B1

A2

B2

A3

B3 A4

B4

A5

B5


and Compensations 10


Compensation Flow

A1

B1

A2

B2

A3

B3 A4

B4

A5

B5




Nested Flow Diagrams

A1

B1

A2

B2

A3

B3

PP

A4

B4



Roberto Bruni @ Santa Cruz (CA) USA 18 Jan. 2005 Interaction and

Agreements In commercial applications, separately

designed and implemented components must interact avoiding ad-hoc proprietary solutions offering alternatives to centralized

transaction managers hiding the coordination layer (separation

of concerns)




P1

P2

P3

{}

{}

Interacting Transactions

{}




P1

P2

P3

{}

{}


{}




P1

P2

P3

{P3}

{P2}


{}




P1

P2

P3

{P1,P3}

{P2}


{P2}




Outline of the talk Part I

Transactional Flows with Compensations Part II

A Process Calculus for Distributed Transactions

Part III Prototype Implementations




Part I - Flows Sequential Sagas

Graphical representation Syntax Big Step Semantics Adequacy results

Parallel Sagas Nested Sagas Additional features




Flow Diagrams and PDLs Many PDL proposals to describe business

processes unambiguously XML-based

WSFL, XLANG, BPEL4WS, … Extensions of known calculi

committed Join (cJOIN), t-calculus, web-calculus Flow-based

Structured Activity Compensation (StAC) now evolving to compensating CSP

core flow language (FL) for sagas [BMM:POPL2005]



Roberto Bruni @ Santa Cruz (CA) USA 18 Jan. 2005 Sequential Sagas:

Graphically

Accept OrderRefuse Order

Update CreditRefund Money

Prepare OrderUpdate Stock




Sequential Sagas: Syntax




(Step) X ::= 0 | A | A%B(Process) P ::= X | P;P(Saga) S ::= { P }




Sequential Sagas: Syntax




S = { AO%RO ; UC%RM ; PO%US }

(Step) X ::= 0 | A | A%B(Process) P ::= X | P;P(Saga) S ::= { P }




Semantics

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

= {A1 ,…, An }




Semantics

A saga S = { P } under either commits ( ) aborts ( ) fails ( )

is the observable flow

S

S

S

*




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

aborts = successfully compensated ß, ß’ are the installed compensations

Sequential Sagas: Semantics

<P,ß> < ,ß’>

<P,ß> < , 0>

<P,ß> < , 0>

*




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

{P}




Semantics

<0,ß> < , ß>

0(zero)

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

{P}




Semantics

<0,ß> < , ß>

0(zero)

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

{P}

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

A(s-act)




Semantics

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

A

<0,ß> < , ß>

0

(zero)

(s-act)

(s-cmp)

(saga)

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

<ß,0> < , 0>

(f-cmp)A , <A%B,ß> < , 0>

<ß,0> < , 0>

*

<P,0> < , ß>

{P}




Semantics

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

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

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

;’

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

<P,ß> < , 0>

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

<P;Q,ß> < ,0>

*

*




Adequacy S

and = A1;…;An

A1 Aj Ak An




Adequacy S

and = A1;…;An

S

and = A1;…;Ak-1;Bk-1;…;B1

A1 Aj Ak An

A1 Aj Ak An

BjB1




Adequacy S

and = A1;…;An

S

and = A1;…;Ak-1;Bk-1;…;B1

S

and = A1;…;Ak-1;Bk-1;…;Bj+1

A1 Aj Ak An

A1 Aj Ak An

BjB1

A1 Aj Ak An

BjB1

*




Parallel Sagas: Syntax








(Step) X ::= 0 | A | A%B(Process) P ::= X | P;P | P|P(Saga) S ::= { P }








S = { AO%RO ; UC%RM | PO%US }

(Step) X ::= 0 | A | A%B(Process) P ::= X | P;P | P|P(Saga) S ::= { P }







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




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




<P,ß> < , 0>

A process P under either commits ( ) aborts ( ) fails ( ) is forced to abort ( ) is forced to fail ( )

is the observable concurrent flow

<P,ß> < , 0>

<P,ß> < , 0>

<P,ß> < , 0>

Parallel Sagas: Semantics

<P,ß> < ,ß’>

*

*





(saga)

(forced-abt’) <P,ß> < ,0>

<ß, 0> < , 0>

(forced-abt’’) <P,ß> < ,0>

<ß, 0> < , 0>

*

{ , , } * <P,0> <, ß>

{P}




<P,0> < ,ß’>


(s-par) <Q,0> < ,ß’’>

’

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

|’





<Q,0> <2,0>

’ <P,0> <1,0>

<P|Q, ß> < 1 2 , 0>

|’;

(c-par’)

<ß,0> < ,0>

1, 2 { , }

*

*

* *

***** * *




Parallel Sagas: Semantics(c-par’’)

*

*

* *

***** * *

<Q,0> <2,0>

’ <P,0> <1,0>

<P|Q, ß> < 1 2 , 0>

|’;

<ß,0> < ,0>

1, 2 { , }

*





<Q,0> <2 ,0>

’ <P,0> <1,0>

<P|Q, ß> < 1 2 , 0>

|’

(f-par)

1 { , }

2 { , , , }

**

**

*

*

* *

***** * *




Parallel Sagas: AdequacyCompletion




Parallel Sagas: AdequacySuccessful Compensation




Parallel Sagas: AdequacyFailed Compensation




Nested Sagas: Graphically




Add Points

Subtract Points




Nested Sagas: Syntax

(Step) X ::= 0 | A | A%B | S (Process) P ::= X | P;P | P|P(Saga) S ::= { P }




Nested Sagas: Syntax

S { AO%RO ; UC%RM | PO%US | {AP%SP} }




Add Points

Subtract Points



Roberto Bruni @ Santa Cruz (CA) USA 18 Jan. 2005 Nested Sagas: Semantics

(sub-cmt) <P,0> < , ß’>

<{P},ß> < , ß’;ß>

(sub-abt) <P,0> < , 0>

<{P},ß> < , ß>

(sub-fail) <P,0> < , 0>

<{P},ß> < , 0>

ß’ acts as default compensation

*

*



Roberto Bruni @ Santa Cruz (CA) USA 18 Jan. 2005 Nested Sagas: Semantics

(sub-forced-1)

(sub-forced-2’)

<P,0> < , 0>

*

<{P},ß> < , 0> *

(sub-forced-2’’)

{ , } *

<ß,0> <,0>

<P,0> < ,0>

<{P}, ß> < ,0>

;*

<ß,0> < ,0>

<P,0> < ,0>

<{P}, ß> < ,0>

;



Roberto Bruni @ Santa Cruz (CA) USA 18 Jan. 2005 Nested Sagas: Adequacy

Completion



Roberto Bruni @ Santa Cruz (CA) USA 18 Jan. 2005 Nested Sagas: Adequacy

Successful Compensation




Failed Compensation

Nested Sagas: Adequacy




More on Sagas Exception handling try S with P

Used to catch crashes during backward computation Forward recovery strategies try S or P

Can be used to retry or to improve activities Fully programmable compensations S%P

More expressive than default compensation (sub-cmt) Allowed by languages like BPEL4WS

Choices: Discriminator PQ Choices: Internal PQ Data dependencies AB

Valid executions must satisfy dependency constraints




Part II - cJoin Distributed Negotiations CHAM and JOIN cJOIN




Distributed Negotiations Negotiations / Contracts

commit, abort, compensation hierarchical decisions dynamic membership fully distributed control

Process cooperation coordination / orchestration / choreography different platforms and policies




Our Proposal: cJOIN committed JOIN

Process Description Language presentation Non ACID (unrealistic in highly distributed

systems) Multiway (several parties can start separately

but commit on reached agreement) Programmable abort / non-perfect compensation Concurrency and distribution (Distributed 2PC) Different levels of abstraction (serializability)




Why JOIN? Well-known asynchronous calculus process calculus presentation

few constructs, based on rendez-vous (atomic non-local interactions)

basis for distributed programming language




Why JOIN? Extends a higher-order functional

language parallelism in expressions (fork calls) parallelism in function patterns (join patterns)

Distributed implementations JoCaml ( http://join.inria.fr ) Polyphonic C#




Based on an elementary model of concurrency the reflexive chemical abstract machine = generic

CHAM + imposing locality + adding reflection locality: only linear reaction patterns allowed

each molecule or reaction rule is associated to a single reaction site

reflection: reactions can generate new kinds of molecules together with their defining reaction rules

Why JOIN?



Roberto Bruni @ Santa Cruz (CA) USA 18 Jan. 2005 Chemical Abstract

Machine States are called solutions s

Multisets of molecules m1,…,mn data and rules (reflexive CHAM)

Hierarchical structure via membranes Group solutions into molecules e.g. { s1 , { s2 } , { s3, { s4 } } }

multisetunion

Evolution (chemical rules) Heating / cooling (reversible)

Structural equivalence Reactions

Transitions Concurrency




Join calculus vs. calculus Join is essentially with restrictions on

communication patterns Join combines restriction, reception and

replication in a single receptor definition: they are not available separately

Asynchrony forces us to create and send continuations in join

Nevertheless, join and asynchronous have the same expressive power demonstrated by fully abstract encoding in

each direction up to weak barbed congruence




Example: Cell Abstraction

getk | sv kv | sv

A cell s contains the value v To get the value:

send a message on port get the parameter k is the return address, where

the value v will be sent to





getk | sv kv | sv

A cell s contains the value v To set the value:

send a message on port set the parameter m is the new value for s k is the return address (for confirmation)

setm,k | sv k | sm





getk | sv kv | sv

The initial value in s is n But get, set and s are locally bound by def

get and set must be extruded, otherwise no one can use them

instead, s can be kept private

setm,k | sv k | sm

def in sn





getk | sv kv | sv

A message to create triggers the outermost def: Three fresh names for s, get and set are allocated

the initial value of s is the first parameter n get and set are sent back to the second argument c instead s will never be extruded

Invariant in every configuration there is exactly one message on s

setm,k | sv k | sm

def in sn | cget,set

def createn,c

in …




Committed JOIN Syntax

M,N::= 0 | xŷ | M|NP,Q ::= M | def D in P | P|Q | abort |

[P:Q]D,E ::= JP | DE | JP J,K ::= xŷ | J|K

messages

programmable abort

compensation

contract

boundaries

merge definitions (boards):

defined boards must be disjoint from ordinary

defined names




Committed JOIN Semantics0

P|Q P,Q

DE D,E

def D in P Ddn(D) , Pdn(D) range() fresh

J P, J J P, P





P|Q P,Q

DE D,E


J P, J J P, P

[P:Q] { P , Q }

compensation is kept frozen

contract P can evolve in isolation





P|Q P,Q

DE D,E


J P, J J P, P

[P:Q] { P , Q }

{ M|def D in 0 , Q } M

commitglobal resources





P|Q P,Q

DE D,E


J P, J J P, P

[P:Q] { P , Q }


{ abort |P , Q } Qcompensation on abort





P|Q P,Q

DE D,E


J P, J J P, P

[P:Q] { P , Q }


{ abort |P , Q } Q

J1|…|JnP, i{ Ji, Si, Qi } J1|…|JnP, {P, iSi, iQi }

merge n ongoing contracts




JOIN vs cJOIN

PROPOSITIONcJOIN is a conservative extension of

JOIN:P J Q iff P

cJ Q (for P and Q JOIN

processes)




Hotel Booking

H def WaitBooking [ def requesto o$ | price$ price$ | confirmv BookedRoomv price$ abort in offeringRoom request,confirm : Q ]

BookedRoomv … in WaitBooking | …




Hotel Booking



C def BookingHotel [def hotelMsg r,c def offer$ cvisa | HotelFound

offer$ abort in rofferin searchRoom hotelMsg : Q’ ]

in BookingHotel | …




Hotel Booking



C def BookingHotel [def hotelMsg r,c def offer$ cvisa | HotelFound

offer$ abort in rofferin searchRoom hotelMsg : Q’ ]

in BookingHotel | …

HB def searchRoom hm | offeringRoom r,c hmr,c in H | C




Hotel Booking…, WaitBooking , BookingHotel

…, […, offeringRoomrequest,confirm : Q ] , […, searchRoomhotelMsg : Q’]

…, […, hotelMsgrequest,confirm : Q | Q’]

…, […, requestoffer : Q | Q’]

…, […, offer$, price$ : Q | Q’]

…, […, confirmvisa, HotelFound , price$ : Q | Q’]

…, […, BookedRoomvisa, HotelFound : Q | Q’]

…, BookedRoomvisa, HotelFound




Trip Booking IH as before

F def WaitBooking [ def requesto o$ | price$ price$ | confirmv BookedFlightv price$ abort in offeringFlight request,confirm : Q ]

BookedFlightv … in WaitBooking | …

local name, different from homonym name

in H




Trip Booking IIC def hotelOKfc | flightOKhc fc | hc BookingHotel [def hotelMsgr,c def offer$ cvisa | hotelOKflightConf

offer$ abort flightConf HotelFound in rofferin searchRoom hotelMsg : Q’ ]

BookingFlight [def flightlMsgr,c def offer$ cvisa | flightOKhotelConf

offer$ abort hotelConf FlightFound in rofferin searchFlight flightMsg : Q’’ ]

in BookingHotel | BookingFlight | …

TB def searchRoomhm | offeringRoom r,c hmr,c searchFlightfm | offeringFlight r,c fmr,c in H | F | C

both needed to commit




Something About cJOIN A simple type system guarantees

serializability for Shallow processes Proof via correspondence w.r.t. big step semantics

Commit primitives of cJOIN can be used to implement committed choices of AKL explicit encoding of search strategies and

unification via continuation passing and compensation

Zero-safe nets can also be straightforwardly encoded as cJOIN processes




Java Transactional Web Services (JTWS) Java Signal Core Layer (JSCL) Java Transactional Layer (JTL)

cJOIN compiler D2PC

Part III - Implementation




JTWS Methodology GOAL: Automatic generation of the

“coordination code” from a description of a composed WS design as

well-formed flow diagrams or as processes in a suitable language

automatic generation of coordination wrappers

for invoking involved services in a sound way for managing commitments and compensations




JTWS and JSCL JTWS tailored to long running transactions

JTWS is based on signal exchanges, publish/subscribe, event notification

JSCL gives a minimal set of functionalities for creation/dismissal of new signal types

signal emitters / handlers as services describing connections between components

asynchronous / synchronous typed, peer-to-peer, unidirectional

broadcast and bidirectional just requires additional links management of flow sessions




JTL Specialized kind of JTWS component

API for (paradigms of) connectors only a minimal subset of signals is

considered three signals can encode compensable

transactions onInvoke onRollBack onCommit




JTL Component Wrappers

WSiRb

In

iCt

Out

oRb

oCt



Roberto Bruni @ Santa Cruz (CA) USA 18 Jan. 2005 JTL Transactional

Component

WS1

iRb

In

iCt

Out

oRb

oCt

WS2

WS1 % WS2

links are dynamicallyestablished depending on the internal state




JTL Sequence

In Out

iRb

iCt

oRb

oCt

JTL1 ; JTL2



Roberto Bruni @ Santa Cruz (CA) USA 18 Jan. 2005 JTL Transactional

Sequence

In Out

offer the method addInternalComponent

{ JTL1 ; JTL2 }



Roberto Bruni @ Santa Cruz (CA) USA 18 Jan. 2005 JTL Trans. Parallel

Component

In Out

offer the method addInternalComponent

{ JTL1 | JTL2 }




Encoding of cJOIN in JOIN Aim:

Define an implementation of cJOIN in JOIN Associate to every cJOIN process a JOIN

process that simulate its behavior

Ideas: Identification of basic forms for definitions Definition of a type system to single out

canonical processes Reuse controllers of the D2PC protocol




Distributed 2PC (D2PC) The Distributed 2PC is a variant of the

decentralized 2PC When a participant P is ready to commit it has

only a partial knowledge of the whole set of participants

Only those who directly cooperated with P To commit P must contact all its neighbors and

learn the identity of other participants from them The D2PC can be conveniently written in

Jocaml




D2PC Every participant P acts as coordinator

During the transaction P builds its own synchronization set LP of cooperating agents

When P is ready to commit, P asks readiness to processes in LP (if empty P was isolated and can commit)

In doing so, P sends them the set LP

Other participants will send to P either a successful reply with their own synchronization sets or a failure message

(in this case, failure is then propagated) Successful replies are added to LP

The protocol terminates when LP is transitively closed




P1

P2

P3

Example: D2PC




P1

P2

P3

{}

Example: D2PC




P1

P2

P3

{}

{}

Example: D2PC




P1

P2

P3

{}

{}

Example: D2PC

{}




P1

P2

P3

{P3}

{P2}

Example: D2PC

{}




P1

P2

P3

{P1,P3}

{P2}

Example: D2PC

{P2}




P1

P2

P3

{P1,P3}

{P2} [P2] ()

<P3,{P2}>

Example: D2PC

{P2}




P1

P2

P3

{P1,P3}

<P3,{P2}>

{P2} [P2] ()

Example: D2PC

{P2}




P1

P2

P3

{P1,P3} [P1,P3] ()

<P3,{P2}>

{P2} [P2] ()

<P2,{P1,P3}><P2,{P1,P3}>

Example: D2PC

{P2}




P1

P2

P3

<P3,{P2}>

{P2} [P2] ()

<P2,{P1,P3}>

<P2,{P1,P3}>

{P1,P3} [P1,P3] ()

Example: D2PC

{P2}




P1

P2

P3

{P2} [P2] ()

<P2,{P1,P3}>

<P2,{P1,P3}>

{P1,P3} [P1,P3] (P3)

Example: D2PC

{P2}




P1

P2

P3

{P1,P2} [P2] (P2)

<P2,{P1,P3}>

{P1,P3} [P1,P3] (P3)

Example: D2PC

{P2}




P1

P2

P3

{P1,P2} [P1,P2] (P2)

<P2,{P1,P3}>

{P1,P3} [P1,P3] (P3)

<P3,{P1,P2}>

Example: D2PC

{P2}




P1

P2

P3

{P2} [P2] ()

{P1,P2} [P1,P2] (P2)

<P2,{P1,P3}>

{P1,P3} [P1,P3] (P3)

<P3,{P1,P2}>

<P1,{P2}>

Example: D2PC




P1

P2

P3

{P2} [P2] ()

{P1,P2} [P1,P2] (P2)

<P2,{P1,P3}>

{P1,P3} [P1,P3] (P1,P3)

<P3,{P1,P2}>

Example: D2PC




P1

Q2

P3

{P2} [P2] ()

{P1,P2} [P1,P2] (P2)

<P2,{P1,P3}>

{P1,P3} [P1,P3] (P1,P3)

<P3,{P1,P2}>

Example: D2PC




P1

Q2

P3

{P2,P3} [P2] (P2)

{P1,P2} [P1,P2] (P2)

{P1,P3} [P1,P3] (P1,P3)

<P3,{P1,P2}>

Example: D2PC




P1

Q2

P3

{P2,P3} [P2] (P2)

{P1,P2} [P1,P2] (P2)

{P1,P3} [P1,P3] (P1,P3)

<P3,{P1,P2}>

<P1,{P2,P3}>

Example: D2PC




P1

Q2

P3

{P2,P3} [P2 ,P3] (P2 ,P3)

{P1,P2} [P1,P2] (P2)

{P1,P3} [P1,P3] (P1,P3)

<P1,{P2,P3}>

Example: D2PC




P1

Q2

P3

{P2,P3} [P2 ,P3] (P2 ,P3)

{P1,P2} [P1,P2] (P1,P2)

{P1,P3} [P1,P3] (P1,P3)

Example: D2PC




Q1

Q2

Q3

{P2,P3} [P2 ,P3] (P2 ,P3)

{P1,P2} [P1,P2] (P1,P2)

{P1,P3} [P1,P3] (P1,P3)

Example: D2PC




Final Remarks I Our definition for compensable flow

languages abstracts away from low-level computations can be easily extended independent from the coordination mechanisms

that implement the primitives Java Transactional Web Services (JTWS)

Distributed implementation of flows Allows to reason about program properties

Adequacy Correctness of implementation




Final Remarks II cJOIN models multi-way transactions

by describing interacting agents but not their global structure

Shallow cJOIN is serializable cJOIN primitives are implementable in

a distributed way at least the subcalculus of flat processes D2PC protocol is used




Some Pointers R. Bruni, C. Laneve, U. Montanari

CONCUR 2002 (D2PC) R. Bruni, H. Melgratti, U. Montanari

POPL 2005 (Flows) IFIP TCS 2004 + COMETA 2003 (cJOIN)

Hernán Melgratti PhD Thesis submitted (Flows, cJOIN and more)

Daniele Strollo Master Thesis in preparation (JTWS)




JOIN: An Example A process P

P zx,z | def xy zy,x in xv

P as a solution { zx,z , wy zy,w , wv }

A reaction { zx,z , wy zy,w , wv }

{ zx,z , wy zy,w , zv,w }

bound name

extrusion

defined name

received name

free name

-conversion

calculi for committed choices and compensations roberto bruni - dipartimento di informatica,...

Documents