OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-models message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: 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-



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC