[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: some thoughts on composing Business transaction cohesions
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-
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC