OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ws-caf] discussion on approaches for web services/ business transaction

Robert, I get the distinct feeling we are going round in circles. You have
yet to prove that a single protocol is suffice for all situations. BP
doesn't say that it should be used in all situations and that isn't the case
for WS-TXM.

Sorry for the brief response, but I have to prepare for the WS-CAF
face-to-face and I suspect all of this discussion is out of scope for that


Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.


----- Original Message -----
From: "Haugen Robert" <Robert.Haugen@choreology.com>
To: "Mark Little" <mark.little@arjuna.com>; "Newcomer, Eric"
<Eric.Newcomer@iona.com>; "WS-CAF" <ws-caf@lists.oasis-open.org>
Cc: <business-transaction@lists.oasis-open.org>
Sent: Sunday, November 30, 2003 10:15 PM
Subject: RE: [ws-caf] discussion on approaches for web services/ business

> > > > There are good reasons for having specific protocols and
> > > > against generic ones
> > > Sure. Tightly-coupled internal transactions...
> > Now who's being extreme - this is certainly *a* reason
> > but is neither necessary nor sufficient.
> I'll get a little more extreme below...and even claim that WS-TXM makes
> the case for a generic protocol.
> > > > and on occassion vice versa.
> > > Loosely-coupled external transactions, especially spanning different
> > > companies.
> > Same as above.
> Consider the case of participants (not coordinators) in loosely-coupled
> external transactions.
> If I have a generic protocol, I can develop generic participants and
> [enrol|enlist|register] them in any business transaction.
> In other words, those participants would be freely composable.
> If I don't have a generic protocol, then I need either different
> participants for each protocol or adapters-with-mappings for each
> protocol.
> The participants would not be freely composable.
> > > You could propose a protocol to be included in WS-TXM
> > > (even BTP I suppose) that accomplished the things you want to see.
> I think even BTP is too complicated for the generic participant.  I
> don't see any cost-effective justification for a loosely-coupled
> participant to care whether the business transaction is atomic, or
> cohesive, or whatever. Coordinator, yes; participant, no.
> I know the argument about wanting more guarantees about participant
> behavior, but if it's externally undetectable behavior (e.g. Isolation),
> you can't enforce the guarantees anyway.
> ** Rash Claim **
> Actually, WS-TXM has its own attempt at a generic protocol: BP.
> Describing interposition between subdomains, the WS-TXM-BP spec says:
> "Each domain is represented by a subordinate coordinator that masks the
> internal business process infrastructure from its parent. Not only does
> the interposed domain require the use of a different context when
> communicating with services within the domain (the coordinator endpoint
> is different), but each domain may use different protocols to those
> outside of the domain: the subordinate coordinator may then act as a
> translator from protocols outside the domain to protocols used within
> the domain.
> "For example, a domain may be implemented entirely using the OASIS BTP
> with the interposed coordinator responsible for mapping BP protocol
> messages into BTP's atom or cohesion messages and vice versa. Another
> domain (possibly in the same overall business process) may use the OMG's
> Object Transaction Service (OTS) and therefore provide an interposed
> coordinator to translate between the BP model and the OTS. The important
> point is that as far as a parent coordinator in the BP hierarchy is
> concerned it interacts with participants and as long as those
> participants obey the BP protocol, it cannot determine the
> implementation."
> In which case, assuming the BP protocol could work as described, then it
> is a universal protocol.  So either WS-TXM has its own proof of the
> feasibility of a universal protocol, or WS-TXM-BP won't work as
> advertised.
> I think BP is too complicated and contains too many sub-protocols to be
> a good candidate for a generic protocol, but that's beyond the arguments
> for and against the concept and on to the more-interesting discussion of
> what makes a good generic protocol.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]