Re: [business-transaction] Points for tonight's meeting

[Alastair Green <alastair.green@choreology.com>]

Mark,

1cf301c24936$edcecd50$2204c40f@langley">

I think one of the important points we need to make sure we don't get embroiled in is that of BTP vs WS-C. As a representative of the company that actually started the WSCF effort (from which WS-C and WS-T were spawned) I can say that there is an important difference between coordination and transactionality that makes WS-C an important effort in its own right. It would be relatively easy for us to get dragged into an argument that should not (IMO) be fought and could detract from the main effort: what is the difference between WS-Tx and BTP? So, I'd recommend that from the outset we just talk about WS-Tx and not WS-C - let's not give people more rope than we have to!

Well, I think that coordination-protocol-tree-building should not be called
coordination. WS-T is a "coordination protocol", even in the terms of WS-C.
You have to compare BTP to WS-C+T because that's the functional span that
makes them comparable. BTP incorporates tree-building.

1cf301c24936$edcecd50$2204c40f@langley">

I am trying to persuade the more conservative elements in Choreology to let me announce a

"Choreology Convergence Challenge: £10,000 (cash or specie, ~$15,000) to anyone who can come up with a use case or application scenario that the combination of WS-C+T can support, but that BTP cannot support". I hasten to add that they have not let me do this yet, so this is a conceptual challenge only at this point.

The purpose of this challenge would not be to launch a BTP vs WS-C+T war (which I think would be a truly futile business), but to highlight the need for convergence to provide a single interoperable means of delivering business functionality to customers.

It's an interesting idea, much like the Amazing Randi's attempts to prove (or disprove) paranormal "powers". However, I think it would be all too easy for it to be perverted to become what you say you don't want. Obviously there's nothing that the TC (or anyone outside of Choreology) can do to prevent this, but IMO it's treading a very fine line.

The idea was inspired by your comment that the use cases may drive differences.
I think it is important to establish what these use cases are. My guess is:
they don't really exist. I should have added that the prize would only be
payable in the ersatz $100 bills they sell in wads for a pound, in local
delis in my area of London.

1cf301c24936$edcecd50$2204c40f@langley">

My view is that it makes little sense to have one standard (a) and another standard (square root of a, squared), which express much the same things but in different ways.

I think there is definitely a requirement for a single standard and there just might be one Web Services transactions protocol. However, I'm extremely wary of trying to make WS-Tx look like BTP (or vice versa): if IBM and MSFT wanted to have a BTP protocol then they would have been in at the start. They weren't and refused to participate over the last 12 months. That has to say something (quite loudly) as to their stance on BTP. So any attempt to make WS-Tx look like BTP will probably fail.

If that is true, then I will be the first to abandon any such effort when
it becomes clear. I think that IBM and Microsoft should be encouraged to
cooperate in the attempt to create a single standard.

1cf301c24936$edcecd50$2204c40f@langley">

I personally think our best approach is to look at the core concepts behind WS-C/Tx: that of a generic coordination framework on which (in this case) specific transaction models can be implemented. So, if we can implement BTP on WS-C and have it adopted as *one* of the transaction protocols in the WS-Tx specification (or whatever some amalgam spec. is called), what have we lost?

The lurking argument here is the fundamental notion of the Activity Service:
that there are one, two, many functionally distinct protocols. My point is
that all of the WS-T coordination protocols can actually be reduced to the
one outcome protocol of BTP. If we pretend that BTP, WS-T in all its variants
are "different" coordination protocols then we end up creating multiple standards
for the same functionality. I am fully prepared to believe that is a (quite
likely) outcome. I'd like to give a shot at avoiding such unnecessary duplication
and redundancy.

1cf301c24936$edcecd50$2204c40f@langley">

There are several things about BTP which should not be lost in a convergence effort. Some have already been touched upon: e.g. high respect for participant autonomy, expressed in anticipation of and forewarning of pre- and post-prepare withdrawals. Others are quite useful and important: heavy optimization possibilities through compounding, "one-wire" capability; control capability for a cohesions hub (WS-T BAs lack interoperable control capability, tho' they do, in a rather awkward way, permit cohesions-like capability); ability to bind to multiple carriers and alternate representations (I think you could actually create a WS-T binding of BTP, tho' it would be an oddity).

We need to be very careful about how we approach the "BTP does this and WS-Tx doesn't or does but not very elegantly"! The TC needs to remember that both IBM and MSFT have large customer bases for (long running) transactions, workflow and business-to-business transactions. I presume that what they have produced in WS-Tx fits pretty closely with their existing non-Web Services implementations, making interoperation trivial for them. Any effort to make that interoperation less trivial (despite what we may believe are the merits) will probably fail.

Sorry, but the adaption from the simple provisional/counter/final model of
BTP to the other models being suggested is truly trivial.

1cf301c24936$edcecd50$2204c40f@langley">

I keep coming back to the notion of these domain-specific transaction models and, in the long run, the user market: if we can get BTP into WS-Tx as is and leave the IBM/MSFT Tx protocol in too, then we let the users decide which transaction semantics they want. (The original idea was also that if these transaction protocols didn't suffice, it should be possible for others to implement their own on WSCF.)

Once again: these are not different transaction semantics. All of them use
a two-phase outcome coordination protocol, modulo naming and optimizations.
The unknown possible future variants are not on the table, either as a result
of BTP or of IBM/MS' work. Users can't decide between different semantics:
they can decide to have the same semantics expressed in different languages
or dialects. Put another way: the abstract messages are fundamentally those
described in BTP.

1cf301c24936$edcecd50$2204c40f@langley">

WS-C+T is infelicitous in its complexity, particularly the unnecessary separation between AT and BA, and the similarly unnecessary distinctions between styles of BA.

The TC's been pulled up on BTP's complexity on more than one occassion, so I don't think we can push that argument ;-)

Not at all. Short of wire-watching, no user should ever be able to tell the
difference between these "protocols" (protocol dialects). The accusation
of complexity directed at BTP either boiled down to an argument about how
under/over specified it was (do/don't like state tables) or to the argument
over cohesions, which is implicitly acknowledged by WS-T BA to be a useful
concept. The current WS-T is truly complex (redundant, insufficient reagent)

1cf301c24936$edcecd50$2204c40f@langley">

 

Have a good meeting.
-- 

Alastair Green
CEO, Choreology Ltd

Cohesions 1.0 (TM)
Business transaction management software for application coordination

+44 207.670.1679
+44 207.670.1785 (fax)