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

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

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


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


 
----- Original Message -----
Sent: Wednesday, August 21, 2002 6:49 PM
Subject: Re: [business-transaction] Points for tonight's meeting

Mark,
1cf301c24936$edcecd50$2204c40f@langley type="cite">
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.
In just the same way as many transaction protocols do. However, BTP isn't purely about coordination. There are aspects of BTP that may well influence WS-C, but it's at the WS-Tx level that there is more impact.

 
1cf301c24936$edcecd50$2204c40f@langley type="cite">
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 type="cite">


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. 
Agreed and hopefully nothing I said above contradicted this approach.

 
1cf301c24936$edcecd50$2204c40f@langley type="cite">
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.
And this comes back to the distinction between WS-C and WS-T. It is true that WS-T as it currently stands looks similar in some respects to BTP. However, WS-C is not tied to 2PC as WS-T and BTP are. So we shouldn't get into "why BTP is better than WS-C" - that argument won't win.
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 think that where functionality overlaps those aspects should be merged. That was one of the points of the Activity Service: if the protocol already exists, then use it; if it doesn't, then implement it. If WS-Tx atomic transactions are similar to BTP atoms then can the two be made to *be* the same without losing anything. If the answer is yes, then there is no reason for having the two. If the answer is no, then shoe-horning one into the other will look bad (at the very least).
 
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. 
I think that a WS-Tx specification that had multiple functionally disparate transaction "components" (e.g., atomic transactions, business transactions and cohesions) to start with would be a good outcome. (Assuming business transactions and cohesions are not the same thing, with the caveats given about for atoms). I still believe that a WS-Tx in 5 years time will look different to whatever IBM/MSFT produce in a years time and that's one of the key aspects to the extensibility of the whole package.
1cf301c24936$edcecd50$2204c40f@langley type="cite">


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 type="cite">
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.
They are similar but not fundamentally the same. What I am suggesting is a calm and collected approach to trying to merge these two specifications as they exist today. There are differences between the two and I keep coming back to the same thing: why are there differences and we should be willing to admit that such differences (whether because of underlying implementations/investment or not) are valid. To be realistic, neither IBM nor MSFT have to go to a standards body with this. Just look at what they did with SOAP and UDDI. All they have to do is say "let there be light" and WS-Tx will be the standard and will exist as precisely the way they want. But neither should we be timid in our approach to this.
 
One approach would be to look at how BTP can be implemented on WS-C (and in that process feed into WS-C if there are deficiencies - and believe me, from what they published there are!) Then we have a WS-BTP (!) using WS-C and looking at differences similarities becomes easier (we're looking at the same level in the architecture for a start). If there are glaring overlaps then it should be easier to argue for a merge and if there are differences we can have them as another aspect of WS-Tx.
1cf301c24936$edcecd50$2204c40f@langley type="cite">


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)
The argument about BTP complexity is valid as far as users are concerned. It's getting less so because of the Primer. As I said very early on when WS-C/Tx were released: neither of these specifications are fully formed and are more a line in the sand.
 
Mark.
 
----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250
 
 
1cf301c24936$edcecd50$2204c40f@langley type="cite">
 
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)



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


Powered by eList eXpress LLC