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: [business-transaction] 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.

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