Formal Models for Distributed Negotiations A Calculus of Compensations

1

Formal Models forDistributed NegotiationsA Calculus of Compensations

Roberto BruniDipartimento di Informatica Università di Pisa

XVII Escuela de Ciencias Informaticas (ECI 2003), Buenos Aires, July 21-26 2003

Formal Models for Distributed

Negotiations 2

Compensations Long running transactions may abort

also when some of their sub-transactions have been committed Committed sub-transactions should be

undone Not always possible: visible events cannot be

canceled e.g. when booking holiday (flights, hotels, cars, shows),

only partial refund can be obtained by canceling e.g. when negotiating services and goods, some fines

must be for canceling the contract To Compensate =

to amends for, to make up for


Negotiations 3

Objectives Clear understanding of long running

transactions (LRT) and of their compositions Formal models to clarify assumptions and

obligations of the various components of a business system

Visual rendering of control structures Algebra of LRTs Design automatic analysis tools for checking

coherence of business systems and guard against deadlocks and race conditions


Negotiations 4

LRTs are not ACID LRTs

are composed out of a collection of traditional atomic transactions

for them, roll-back is supplied automatically usually engage in externally visible events

these events cannot be undone automatically user-defined (application-dependent)

compensations are needed approximately atomic and consistent, not

isolated and globally durable, no automatic roll-back


Negotiations 5

Inspiration From XLANG

context P exception E compensation C

normal entry point

normal exit point

failure

compensation entry

compensation exit


Negotiations 6

Sound Traces Normal flow is vertical, from top to

bottom Compensation flow is still vertical, but in

the reversed direction (from bottom to top)

For the moment we regard internal failures just as compensations

Sound traces OK: normal in (nin) – normal out (nout) FAIL: nin – compensation out (cout) COMP: nin – nout – cin - cout


Negotiations 7

Tree of Traces Traces can be conveniently represented as

a tree Nodes are labeled by events A trace is a path from the root of the tree

Sound transactions tree of traces must be conform to

nin

nout

cin

cout

cout


Negotiations 8

Succeed and Fail Straight arrows have no effects

nin

nout

cin

cout

nin

cout


Negotiations 9

R;S

Sequential Composition sequence R S

Compound events nin & R.nin R.nout & S.nin S.nout & nout cin & S.cin S.cout & R.cin R.cout & cout

Simultaneous occurrence of joint events

S

R

nin & R.nin

R.nout & S.nin

S.nout & nout

cin & S.cin

R.cout & cout

S.cout & R.cin

R.cout & cout

S.cout & R.cin

R.cout & cout


Negotiations 10

R;S

Sequential Composition is Sound for R

sequence R S Compound events

nin & R.nin R.nout & S.nin S.nout & nout cin & S.cin S.cout & R.cin R.cout & cout


S

R

nin & R.nin

R.nout & S.nin

S.nout & nout

cin & S.cin

R.cout & cout

S.cout & R.cin

R.cout & cout

S.cout & R.cin

R.cout & cout


Negotiations 11

R;S

Sequential Composition is Sound for S




S

R

nin & R.nin

R.nout & S.nin

S.nout & nout

cin & S.cin

R.cout & cout

S.cout & R.cin

R.cout & cout

S.cout & R.cin

R.cout & cout


Negotiations 12

R;S

Sequential Composition is Sound




S

R

nin & R.nin

R.nout & S.nin

S.nout & nout

cin & S.cin

R.cout & cout

S.cout & R.cin

R.cout & cout

S.cout & R.cin

R.cout & cout


Negotiations 13

Notes About Sequence Dynamic behaviour uniquely defined by the

flowchart Only tree that satisfies all three conditions of

soundness Sequential composition is associative

We can omit outer boxes in nested serializations omit parentheses in algebraic expressions investigate properties by considering two operands at

a time


Negotiations 14

In sequential composition, a failure of a single component triggers the compensations of all previous activities

The pick operation allows to specify two or more alternatives for the same goal tried sequentially until one succeeds or all have failed

Sequential Choice (Pick)


Negotiations 15

Sequential Choice (Pick) pick R S

(associative)SR

nin & R.nin

R.nout & nout

cin & R.cin

R.cout & cout

R.cout & S.nin

S.nout & nout

cin & S.cin

S.cout & cout

S.cout & cout

The tree is more informativethan the flowchart


Negotiations 16

Two or more transactions can be executed concurrently

The all operation allows to specify two or more concurrent activities initiated together fail if any of them fail completed when all succeed roll-back all on subsequent failures

Parallel Composition (All)


Negotiations 17

Parallel Composition (All) all R S

Petri net–like flowchart (assoc., comm.) SR

nin & R.nin & S.nin

R.nout & S.nout & nout

cin & R.cin & S.cin

R.cout & S.cout & cout

R.cout & S.cout & cout

The tree is trivial

The implementation is difficult!What if, after R.nin and S.nin, it happensthat R.nout but S.cout? Deadlock? (dealt with exceptions)


Negotiations 18

Speculation local extra work in anticipation it may

need later Two or more transactions can be

attempted concurrently take the one that succeeds first compensate all the others alternatives must be independent each

other and with no interaction

Concurrent Waiting (Parallel Pick)


Negotiations 19

nin & R.nin & S.nin

R.nout &S.cout &nout

cin & R.cin

R.cout & cout

Concurrent Waiting (Parallel Pick)

R.cout &S.nout &nout

cin & S.cin

S.cout & cout

R.cout &S.cout &cout

R.nout &S.nout

S.cin

S.cout & nout

cin & R.cin

R.cout & cout

R.cin

R.cout & nout

cin & S.cin

S.cout & cout

non-determinism


Negotiations 20

The Pi-Calculus Approach The pi-calculus is the most famous

calculus for (name) mobility Similar to join

many receivers on the same channel hiding (x) and binding input prefix x(y).P

instead of def xyP in … Similar to CCS (with value passing)

outputs carry values xy inputs have (bound) arguments x(y)


Negotiations 21

Compensation Primitives Asynchronous pi-calculus

P ::= 0 | xy | x(y).P | (x)P | !P | P|P Additional primitives

done – successful termination of transaction abort – internal failure context(P,Q,R) – Process P with exception

handler Q and compensation R Some structural laws

P | done = P abort | abort = abort context(xy|P, Q, R) = xy | context(P, Q, R)


Negotiations 22

Handling Failures Compensations are remembered after commit by

attaching them to on-failure processes of outer contexts context(P|context(done,Q’,R’), Q, R) context(P, R’|Q,

R) context(abort, Q, R) Q

This allows for Establishing abstract equivalences

e.g. if P is abort-free, then P is equivalent to any context(P,Q,R) Formal encoding and comparison with other calculi

extended processes can be “compiled” in the pi-calculus


Negotiations 23

Extending Compensations Standard approach

Compensations associated with primary activities of LRTs

When required, all compensations of successful activities are executed (in reversal order)

If savepoints are reached (committed choices), then compensations are no longer required and can be forgotten

StAC (Structured Activity Compensation) In the spirit of Sagas

More general mechanisms (concurrent and non-atomic activities)

Multiple compensations (selective / alternative)


Negotiations 24

Business Process Beans Business Processes

model activities that are useful to the business

must be composable hierarchy of abstractions

IBM’s BPBeans Application hierarchy of nested components

bottom level: primitive Java beans components activities act on a global set of shared variables

composed via the Application Builder for Components (ABC) tool


Negotiations 25

StAC Syntax P ; P (sequential composition) P | P (parallel composition) par i in S do i.P (generalized parallel comp.) if C then P else P (conditional) (early termination) {P} (termination scoping) P P (compensation pair) [P] (compensation scoping) (accept) (reverse)


Negotiations 26

Sequential and Concurrent Activities

P ; Q P is executed first. When P completes, Q is

executed associative

P | Q associative

par i in S do i.P used for generating many concurrent instances

uniquely indexed by i e.g. par i in 1..10 do i.P

creates 10 distinct concurrent instances of P


Negotiations 27

Early Termination

termination is limited by scoping brackets e.g. {P;;Q} ; R

first executes P, then terminator prevents Q from being executed, but being termination limited within brackets, then R will be executed

also concurrent activities are terminated maybe not immediately, but at a later stage

either prematurely or at completion e.g. {(P;;Q) | S} | R

the termination causes S to terminate (not R, which is outside the scoping)

Termination scoping can be nested


Negotiations 28

Compensations I P Q

P is the primary task Q is the compensation task for P First the primary task is executed, when

completed, the compensation task is remembered for later use (in reversal)

executes available compensations e.g. (P Q) ;

executes P and remembers Q, then reverse by executing Q e.g. (P1 Q1); (P2 Q2);(P3 Q3);

executes P1 then P2 then P3 then Q3 then Q2 and finally Q1


Negotiations 29

Compensations II e.g. ((P1 Q1)|(P2 Q2)|(P3 Q3)) ;

executes P1, P2 and P3 concurrently, and then compensates with Q1, Q2 and Q3 concurrently

Invoked compensations are then cleared e.g. (P Q) ; ; is the same as (P Q) ;

forgets all currently remembered compensations

(committed choice) e.g. (P1 Q1) ; ; (P2 Q2) ;

executes P1 then P2 and finally Q2 (Q1 is not performed because it has been removed by the accept operation)


Negotiations 30

Compensations III Compensations can be nested

e.g. (P (P1 Q1) ) ; executes P and remembers (P1 Q1), then on reversal

executes P1 but remembers Q1 for later use Square brackets delimit the scope of the accept

and reverse operators Restrictions in BPBeans

nested compensations are not allowed each level in the hierarchy overrides lower levels

(as if P was modeled by [P;]) concurrent activities have separated

compensation scopes (as if P|Q was modeled by [P]|[Q])


Negotiations 31

Multiple Compensations Aim: to allow processes to remember

several simultaneous compensation tasks Individual tasks can then be accepted or

reversed Facilitate reuse of processes

Language extension P i P (indexed compensation pair) i (indexed accept) i (indexed reverse)


Negotiations 32

Selective and Alternative Compensations

Selective compensations reversals select some activities to be

compensated for, while preserving the compensations for other activities

Alternative compensations several alternative compensations are

attached to the same activity and the reversal picks one of these alternatives for invocation and forget the others


Negotiations 33

StAC vs Other Models Sagas

non hierarchical and purely sequential compensations invoked on system failure assumption of perfect compensation

Nested transactions compensations invoked on system failure rigid scoping multiple compensations are not allowed

ConTracts single compensations implicit accept and reversal


Negotiations 34

Recap We have seen Different approaches to the formal

modeling of compensations Difficulties Advantages Mismatching Basis for implementations


Negotiations 35

References Notes by T. Hoare, C. Fournet, A.

Gordon, L. Bocchi, C. Laneve, G. Zavattaro

Extending the concept of transaction compensation (IBM System Journal 41(4), 2002, pp. 743-758) M. Chessell, C. Griffin, D. Vines, M. Butler,

C. Ferreira, P. Henderson

Documents

Formal Models for Distributed Negotiations A Calculus of Compensations