----- 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.comPhone: +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)
|