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

["Haugen Robert" <Robert.Haugen@choreology.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.

I think the BTP list is more appropriate, too.
I thought you were the one who suggested ws-caf?

> 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.

If you check, I have always been careful to qualify my situation as
"loosely coupled external transactions".

And in my last message below, I focused in even more on participants,
not coordinators.

And you didn't respond to any of my actual message, just fended it off
with a non seq.

I don't know if it's worth continuing our dialog, maybe we should just
do that "agree to disagree" number...

> ----- 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.
> >
>
>