business-transaction message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [business-transaction] Re: [bt-spec] WS-X
- From: Alastair Green <alastair.green@choreology.com>
- To: bill.flood@sybase.com
- Date: Sat, 10 Aug 2002 22:31:07 +0100
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.
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?
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.
(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). Let us hope it's only
use is not wstx vs btp. 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.
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
--
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