Formal Models for Distributed Negotiations A Calculus of Compensations

1
Formal Models forDistributed NegotiationsA
Calculus of Compensations
XVII Escuela de Ciencias Informaticas (ECI 2003),
Buenos Aires, July 21-26 2003
Roberto Bruni Dipartimento di Informatica
Università di Pisa
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

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

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

5
Inspiration

• From XLANG
• context P exception E compensation C

failure
normal entry point
compensation exit
normal exit point
compensation entry
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

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
cout
cin
cout
8
Succeed and Fail

• Straight arrows have no effects

nin
nin
nout
cout
cin
cout
9
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

RS
R
S
10
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
• Simultaneous occurrence of joint events

nin R.nin
RS
R
R.nout S.nin
R.cout cout
S.nout nout
S.cout R.cin
S
cin S.cin
R.cout cout
S.cout R.cin
R.cout cout
11
Sequential Composition is Sound for S

• 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

nin R.nin
RS
R
R.nout S.nin
R.cout cout
S.nout nout
S.cout R.cin
S
cin S.cin
R.cout cout
S.cout R.cin
R.cout cout
12
Sequential Composition is Sound

• 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

nin R.nin
RS
R
R.nout S.nin
R.cout cout
S.nout nout
S.cout R.cin
S
cin S.cin
R.cout cout
S.cout R.cin
R.cout cout
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

14
Sequential Choice (Pick)

• 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

15
Sequential Choice (Pick)

• pick R S
• (associative)

S
R
The tree is more informative than the flowchart
16
Parallel Composition (All)

• 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

17
Parallel Composition (All)

• all R S
• Petri netlike flowchart
• (assoc., comm.)

S
R
18
Concurrent Waiting (Parallel Pick)

• 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

19
Concurrent Waiting (Parallel Pick)
nin R.nin S.nin
non-determinism
R.nout S.nout
R.nout S.cout nout
R.cout S.nout nout
R.cout S.cout cout
S.cin
R.cin
S.cout nout
R.cout nout
cin R.cin
cin S.cin
cin R.cin
cin S.cin
R.cout cout
S.cout cout
R.cout cout
S.cout cout
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 x?y??P in
• Similar to CCS (with value passing)
• outputs carry values x?y?
• inputs have (bound) arguments x(y)

21
Compensation Primitives

• Asynchronous pi-calculus
• P 0 x?y? x(y).P (?x)P !P PP
• 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(x?y?P, Q, R) x?y? context(P, Q, R)

22
Handling Failures

• Compensations are remembered after commit by
  attaching them to on-failure processes of outer
  contexts
• context(Pcontext(done,Q,R), Q, R) ? context(P,
  RQ, 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

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)

24
Business Process Beans

• Business Processes
• model activities that are useful to the business
• must be composable
• hierarchy of abstractions
• IBMs 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

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)

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

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

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

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)

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 PQ was modeled by PQ)

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)

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

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

34
Recap

• We have seen
• Different approaches to the formal modeling of
  compensations
• Difficulties
• Advantages
• Mismatching
• Basis for implementations

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