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

["Mark Little" <mark.little@arjuna.com>]

BTW, I'm happy to continue this discussion, but the previous email is just a
heads-up that a) my responsiveness will be much impaired over the next
couple of weeks, and b) I think the BTP list (or private email) is a more
appropriate discussion forum.

Mark.

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

www.arjuna.com

----- Original Message -----
From: "Mark Little" <mark.little@arjuna.com>
To: "Haugen Robert" <Robert.Haugen@choreology.com>; "Newcomer, Eric"
<Eric.Newcomer@iona.com>; "WS-CAF" <ws-caf@lists.oasis-open.org>
Cc: <business-transaction@lists.oasis-open.org>
Sent: Monday, December 01, 2003 10:06 AM
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
> TC.
>
> Mark.
>
> ----
> Mark Little,
> Chief Architect, Transactions,
> Arjuna Technologies Ltd.
>
> www.arjuna.com
>
> ----- 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
> transaction
>
>
> > > > > 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.
> >
>
>