|
----- Original Message -----
Sent: Saturday, August 10, 2002 10:31
PM
Subject: Re: [bt-spec] WS-X
Dear Bill,
I find your analysis of the current (largely
predictable) situation very interesting. We have the WS-Security business as
an unfinished template.
Of course, the most important thing about
WS-C/T (like Web Services as a whole) is that is backed by IBM and Microsoft.
The value of WS for customers will drop radically if the industry titans
manage to reproduce the old CORBA vs. DCOM battles somewhere down the line.
The second most interesting thing is BEA's role.
Yes, this only has value if it doesn't cause fracture. Now, we all know
there are many ways this could happen.
WS-T unfortunately ignores much of what is useful, clarifying and novel
in BTP. This means that several features that reflect some serious collective
examination of the new problems thrown up in a highly autonomous
service-oriented environment are put aside. WS-T also makes a complicating and
unnecessary distinction between "atomic transactions" and "business
activities". I guess we are going to have to rehearse all of those old
discussions about 2PC does not equal 2PL. It seems under-specified. All
in all, a splendid example of the "Not invented here" mindset, in high gear.
But hey, it's the software industry. What's new?
I don't think WS-T is a specification at all, really. It's not well written
for a start. However, if it is intended for a different set of business cases
that BTP does not match or is seen as too complex for, then I don't think we
should be arguing that "my specification is better than yours". Let's embrace it
within a single umbrella of Web Services Transactions (or Business Transaction
Protocols). As you know, I've never believed that a single protocol will be
right for all requirements unless we want to create a hughely bloated
specification. What we need to do, IMO, is support the construction of different
protocols for different requirements/uses cases, if what exists is not
appropriate.
One of your remarks is, I think, somewhat mistaken.
WS-Coordination - This proposal is
unique and stands on its own as a way of setting up "distributed SOAP
transaction servers" - aka a VAN.
WS-Coordination replicates the context creation, propagation, enrollment
and interposition features of BTP (well, apart from the fact that most things
have a different name). The only aspect of WS-C which differs is the ability
to type the context by coordination protocol type, and the implication that
different coordination protocols will use the same coordinator-resource
mutual-awareness scheme.
In pretty much the same spirit as the WS-T specification, WS-C doesn't
convey enough information about the overall intention and model, IMO. If that
were clear then it would be possible to see that Web Services coordination is
not the same as BTP.
(The name "WS-Coordination" is confusing. The specification uses
"coordination protocols" in the way that I would, and just have: namely, to
identify protocols that run between coordinator and participant to create a
coordinated outcome across the participants. Such coordination protocols are
not described by this specification. It would be more accurate to describe
its protocol as WS-Infection or WS-Propagation, or the like.)
I
view the desire to permit multiple underlying coordination protocols as a
harmless eccentricity (reuse before the reuse case).
Again, I think the specifications as they exist don't do themselves
justice. There are use cases, but for some unknown reason these proponents don't
want to mention them!
Let us hope it's only use is not wstx vs btp.
It should not come down to WS-T versus BTP in general. Perhaps for specific
use cases, but certainly not as *the* transaction protocol for Web
Services.
In all other circumstances I suspect that the registration or enrollment
facility will be, de facto, part of the coordination protocol per
se.
From which standpoint, I would argue, it would save everyone a lot
of bother if this idea of a different "coordination" specification was dropped
in favour of a single specification a la BTP, which enables business
transactions for web services and application coordination.
Disagree. Coordination is a fundamental requirement in a lot of different
services/protocols that simply do not need transaction capability at all. OK, we
could say use BTP and ignore the transaction component, but then what's the
point? Why not get the Web Services architecture right in the first place and
have different services/layers that are responsible for specific functionality
and can be re-used in their entirety? For example, a service that just does
context propagation and nothing else could be used in more places than a service
that ties context propagation to transactionality.
I've copied this up to the main list, because I think that the
wider audience deserves to eavesdrop or participate (I hope the
latter).
Yours,
Alastair
Cheers,
Mark.
---------------------------------------------- Dr. Mark Little,
Distinguished Engineer, Transactions Architect, HP Arjuna Labs Email: mark_little@hp.comPhone: +44 191
2606216 Fax : +44 191 2606250
--
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)
|