← Prev in month ← Prev in thread
Next in thread → Next in month →

some thoughts on composing Business transaction cohesions

From
Keith Weir <>
Date
2001-04-03T05:23:01+00:00
ID
Thread
some thoughts on composing Business transaction cohesions
All,

I have been thinking on a slightly different tack for Business

Transactions, and I would like to explore this further while we

discuss models.

Hopefully you will excuse the rather terse description below, and
my

delving into protocol flows.

I have been looking at the behaviour of the items to be composed
into

Business transactions. They typically have a number of states and
valid

transitions between those states.

Look at item A: a part of a business transaction. Valid state transitions

could be:

0 --order--> A1 --confirm--> A2 --deliver--> A3 --paid-> A4

            
A1 --lapse--> A5

            
A1 --cancel--> A5

                            
A2 --cancel--> A5

                                            
A3 --returned--> A5

I'm sure there can be many other states and corresponding transitions,

but these will suffice for discussion purposes.

If we are to be able to effect state transitions on this, it probably

needs a globally unique identifier of some description. As can
be seen

A may autonomously transit from A1 to A5 on order lapse (timeout

waiting for confirmation). We probably need A to have a means of

informing the initiator of this, so perhaps the initiator needs
a global

identifier for items it is collecting to compose into Business

transactions.

Now if we request to confirm the order (A1 --> A2) it is possible
the

order may lapse prior to the confirm being received. When an item

lapses, there is little of practical use the initiator can do with
it

further. It may be possible for the initiator to complete it's

composition with another item from the same (or another) supplier,
and

it should be possible for it to do so.

If the initiator needs A only if B can also be acquired, we need
some

way of composing A and B together in a Business Transaction such
that if

A lapses B can be composed in another BT with A's replacement C.

Similarly if B lapses A may be composed with B's replacement D...

Let us look at some hyothetical protocol scenarios and see how they

develop.

1. Straightforward success case:

I                      
A           B

Begin(Co1)

------[Co1]confirm----->

                       
[A1->A2'] # A2 becomes pending

<----------OK-----------

[Co1(A)]

------[Co1]confirm----------------->

                                   
[B1->B2'] # B2 becomes pending

<----------OK-----------------------

[Co1(A,B)]

------[Co1]commit------>[A2'->A2]

<----------OK-----------

------[Co1]commit------------------>[B2'->B2]

<----------OK-----------------------

 

2. Item B lapsed and has to be replaced with D:

I                      
A           B          
D

Begin(Co1)

------[Co1]confirm----->

                       
[A1->A2'] # A2 becomes pending

<----------OK-----------

[Co1(A)]

------[Co1]confirm----------------->

                                   
[B5] # B has lapsed

<----------Fail(lapsed)-------------

------[Co1]rollback---->[A2'->A1]

<----------OK-----------

[Co1()]

-----------order------------------------------->[0->D1]

<----------OK-----------------------------------

------[Co1]confirm----->

                       
[A1->A2'] # A2 becomes pending

<----------OK-----------

[Co1(A)]

------[Co1]confirm----------------------------->[D1->D2'] # D2
becomes pending

<----------OK-----------------------------------

[Co1(A,D)]

------[Co1]commit------>[A2'->A2]

<----------OK-----------

------[Co1]commit------------------------------>[D2'->D2]

<----------OK-----------------------------------

 

3. Communications failure to item B, decision taken to replace with
D,

   item B recovers

I                      
A           B          
D

Begin(Co1)

------[Co1]confirm----->

                       
[A1->A2'] # A2 becomes pending

<----------OK-----------

[Co1(A)]

------[Co1]confirm----------------->

                                   
[B1->B2'] # B2 becomes pending

<--Fail(comm)- X <-----OK-----------

------[Co1]rollback---->[A2'->A1]

<----------OK-----------

------[Co1]rollback-----------------X

<--Fail(comm)-----------------------

[Co1()]

-----------order------------------------------->[0->D1]

<----------OK-----------------------------------

                                   
Timeout awaiting decision

<-----[Co1]request-status-----------

------[Co1]rollback---------------->[B2'->B1]

------[Co1]confirm----->

                       
[A1->A2'] # A2 becomes pending

<----------OK-----------

[Co1(A)]

------[Co1]confirm----------------------------->[D1->D2'] # D2
becomes pending

<----------OK-----------------------------------

[Co1(A,D)]

------[Co1]commit------>[A2'->A2]

<----------OK-----------

------[Co1]commit------------------------------>[D2'->D2]

<----------OK-----------------------------------

(I wonder if we need protocol support for cancelling B?)

 

4. More interestingly, choose either A or B (B preferred)

I                      
A           B

Begin(Co1)

------[Co1]confirm----->

                       
[A1->A2'] # A2 becomes pending

------[Co1]confirm----------------->

                                   
[B1->B2'] # B2 becomes pending

<----------OK-----------

<----------OK-----------------------

[Co1(B)]

------[Co1]rollback---->[A2'->A1]

<----------OK-----------

------[Co1]commit------------------>[B2'->B2]

<----------OK-----------------------

( either

------cancel----------->[A1-A5]

<----------OK-----------

  or re-use for another cohesion...)

 

                                     
-oOOo-
← Prev in month ← Prev in thread
Next in thread → Next in month →