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.
>
> I think the BTP list is more appropriate, too.
> I thought you were the one who suggested ws-caf?

I honestly can't remember.

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

I shouldn't do this because I really have to write some slides ;-)

However, ... if you go back through my emails you'll see I have always been
talking about participants in the main anyway. The argument still exists and
is based on our experiences of both approaches: a definite participant
interface that explicitly specifies protocol and semantics has proven better
than *only* having an abstract one. And once again, we're not saying *don't*
have an abstract (neutral, or whatever) message set, only that it shouldn't
be the only protocol that's supported: experience has shown that that
doesn't work and isn't what many in the industry want. (OK, that last part
is subjective, because you can probably say that the people you've talked to
want the opposite, but then that just goes to show that one-size doesn't fit
all!)

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

It wasn't a response, more of an "I'm not ignorning you, but ..."

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

Possibly. I do find it interesting, having been through both paths to get
where we currently are, but I don't see this as a religious discussion like
"Macs versus PCs" ;-) I think that the fact we are having this discussion
shows that there's may not be enough experience to say how things will
evolve over the coming years from a user's perspective, so we need to do
something that doesn't back us (the industry) into a corner from which is
can't extricate itself. Hence the approach WS-CAF or WS-C/T takes makes
sense purely from a pragmatic standpoint.

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