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] Re: [bt-spec] WS-X



Alastair,

I agree with your points but I should clarify my statement around WS-Context.  My reading of WS-Context lead me to understand that WS-Context provides a generic means of coordinating context, not one specifically tied to WS-Transaction (although they do reference it in their example).  While it is true, in the BTP namespace, the context, is transmitted as well but perhaps a little more focused on the transaction.  In short, BTP could adopt WS-Context as a more generalized means to transmit context of any kind, not just those involving transactions.  One could always do this with an element reference from one context to the other (from the general to the specific context).  Correct me if I'm off base, but isn't this an area where BTP could be amended to play in a consistent fashion with other standards that also involve context?

I appreciate your thoughts and feedback and do hope this discussion is helpful.

Best Regards,

Bill Flood
Sybase






Alastair Green <alastair.green@choreology.com>

08/10/2002 02:31 PM

       
        To:        bill.flood@sybase.com
        cc:        Mark Little <mark_little@hp.com>, business-transaction@lists.oasis-open.org, Mark Potts <mark.potts@talkingblocks.com>, Peter Furniss <peter.furniss@choreology.com>, "Cho, Pyounguk" <pyounguk.cho@iona.com>
        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