RE: Choreology initial submission to OASIS BT TC

[Peter Furniss <peter.furniss@choreology.com>]

Dean,

Thank you very much for your comments, and apologies for not replying
sooner. At first I wasn't on the mailing list, then didn't like my own first
reply.


I read Choreology's initial submission and have a couple remarks/comments.

1. Requirement #1: Operation groups with reverse operations.
   For some operations (e.g booking an airline ticket, deposit, withdrawal),
   defining compensation (reverse operations) is pretty straightforward.
   However, how difficult will it be to define compensations for more
complex
   operations especially when they use differing isolation/durability
   levels (e.g. the operation may have done some dirty reads).

Yes, I think it will sometimes be next to impossible to have a guaranteed
compensation. There are various ways of handling/looking at that.

One way is to say just because some operations aren't reversible doesn't
mean we shouldn't have a protocol that allows more flexible
transactions/more consistent applications where the operations are
reversible. If a service offers some operation that cannot be reversed then
it won't (or ought not) offer to support a compensation/reversal mechanism.
It may be involved in the same business activity but whoever included it
must accept that this part of the activity is irrevocable.

Alternatively, it may be that the reversibility is usually possible but may
be imperfect - either the lack of isolation has allowed other changes to be
made that are beyond the stored compensation's ability to sort out, or other
activities have taken the "uncommitted" value at face-value and used that
information elsewhere (possibly making no changes to the data that was
changed by our operation).  Deciding whether such a service can (or should)
claim to support a cohesion protocol is (in my personal view) dependent on
whose the information is and what guarantees/claims/expectations they want
to make about it.  A difference between the inter-business operations BT is
targetting and classic transaction scenarios is that the data may be
primarily "owned" by one partner, not by the inter-business application.
Data accessed by a web-service may "belong" to the provider of the service
(and be used primarily for some other purpose) so the web-service might
qualify its promise of the transient validity of the data (e.g. the web
service may say the item is definitely out of stock when in fact it is only
potentially out-of-stock; internal staff might see the same data as "10
items reserved but not confirmed").


2. Requirements #8 and #9. Is relaxing isolation and durability sufficient
   to capture the consistency requirements for business transactions?
   Are there other parameters?
   The example that is in my head is a simple procurement example.

   A purchaser initiates an order, due to a time out the
   order is cancelled. However it suddenly arrives or the the supplier
   tells the purchaser that the goods were delayed for some reason
   and are now on their way by express delivery, the purchaser then
   decides to proceed with the order - that is, re-instate the
   initial order (compensate for the compensation). By the time the
   purchaser wants to re-instate the order, payment may to the supplier
   may have been cancelled and so payment need to be re-instated.
   Since isolation is relaxed,  the payment may have been canceled by the
   time the order is re-instated.

   Is the scenario a scenario that should be supported by a business
   transaction protocol? Is so, how and how does the requirements
   capture this scenario?


I think this would have to count as something handled at a higher-level -
truly at business process. Your example could potentially recurse
indefinitely - how are they going to decide whether or not the purchase is
complete ? A cohesion protocol can deliver a consistent decision to all the
parties, but if one of them then says the decision should be different, what
was the point or extent of the original decision ?  Real-world examples,
like yours, would in fact have a way of getting resolution, generally
involving escalation to some higher, more abstract or more intelligent
level.

Thanks again for your comments and apologies again for delaying replying. I
hope you'll be taking part in the email discussions, even if we have our
phone meetings in the middle of the night in Australia.

Peter

------------------------------------------------
Peter Furniss
Choreology Ltd

email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
13 Austin Friars, London EC2N 2JX