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

[Mark Little <Mark.Little@arjuna.com>]

Peter, I would hope that you would agree that this is all comes down to 
experiences. The authors of the initial WS-CAF specifications have had 
experience with generic protocols in the field, such as BTP. For example, when 
I was with HP and we had the first commercial BTP implementation, we spent a 
lot of time working in with the process-flow people in Pinewood and they only 
wanted to have strict ACID semantics and associated guarantees from the 
participants. We ended up spending a lot of time defining the necessary BTP 
qualifiers that defined ACID and ensuring the coordinator-to-participant 
protocol upheld the contract.

This was making the generic protocol specific and wasn't trivial. We had to 
agree on the qualifiers for a start and ensure that all services (which could 
have been developed by external vendors) used them. The alternative approach 
was to make the contract between coordinator and participant explicit, i.e., 
through a concrete interface. I've said it before and I'll say it again (and 
it essentially reiterates what Greg Pavlik has said) as a service composer, 
knowing *how* something will react is important, and compensation based 
approaches cannot always give the same guarantees (e.g., timeliness, seeing 
"dirty" data - which could be an unwanted/unexpected debit on my credit card) 
as, say, a traditional TP system.

This is not to say that the principle of "I don't care how something is 
implemented" is wrong, only that it isn't the general case. What we have seen 
time and again is that there is no such thing as the general case. The WS-CAF 
approach epitomises this by allowing us to support different approaches. I 
find it difficult to understand that you can honestly believe that we know 
enough about the current and future requirements on business transactions to 
say with certainty that one protocol is sufficient, especially if it isn't so 
generic as to be entirely abstract.

Alternatively, let's move forward with an approach that supports different 
styles and is backed by the likes of Oracle, Sun, IBM and Microsoft (afterall, 
the argument of general versus specific isn't strictly one just for WS-CAF).

If you do believe in a single protocol then the world already has BTP. We can 
work on integrating it with WS-CAF if there is enough interest, but I don't 
believe that one protocol should be the outcome of WS-TXM. It flies in the 
face of the principles behind WS-CAF and the experiences we have gained. If 
BTP is finalised/adopted/standardised or whatever, then you have your single 
protocol - what benefit is there to defining another? We, as the WS-CAF 
authors, see benefit in the alternate approach, which is not supported in BTP.

Mark.

>===== Original Message From "Furniss, Peter" <Peter.Furniss@choreology.com> 
=====
>Eric,
>
>
>> Thanks for this, but as you say, this discussion largely
>> boils down to a matter of opinion.
>
>True. Either way could work. It is a question of which is most
>
>> If there are specific issues here for the WS-CAF specs I have
>> to say I still can't either understand or recognize them.
>
>Yes, I understand your problem as TC Chair. Given the scope stated in
>the charter as fixed, it is difficult to have this discussion in WS-CAF
>TC. Which is why we've suggested the BT TC list (note, that is not the
>BTP TC, though it tends to get called that) as the place to work out the
>discussion.
>
>> I think what we are interested in as a TC are specific
>> suggestions, corrections, amendments etc to the WS-CAF drafts.
>
>Well, the specific suggestion would be collapse all the TXM variants to
>one, which would probably have the message set of ACID, a slightly
>looser state sequence (to allow for optional prepare etc.), and restate
>the semantics of the messages in a way that allows internal choice in
>how those semantics are implemented.
>
>I wonder if you feel that is in scope ?
>
>(It would apply only to the superior/inferior "outcome" exchanges, not
>the control ones, where there might be different protocols)
>
>
>Peter
>
>> Thanks again,
>>
>> Eric
>>
>> -----Original Message-----
>> From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
>> Sent: Friday, November 28, 2003 10:40 AM
>> To: Newcomer, Eric; Haugen Robert; WS-CAF
>> Cc: business-transaction@lists.oasis-open.org
>> Subject: RE: [ws-caf] discussion on approaches for web
>> services/ business transaction
>>
>>
>> (cross-posted to the BT tc list - apologies for those of you
>> who are on both BT and WS-CAF, but there are a lot who aren't
>> and I believe the recent thread on ws-caf will be of interest
>> to the BT folks)
>>
>>
>> Eric,
>>
>> I don't see how all the WS-TXM protocols can "bridge" in a
>> single sense of the word while following the meta-model that
>> leads to the requirement for multiple protocols.
>>
>> Of course, today, each environment has its own protocol, at
>> least in the sense of the encodings of the messages. It's
>> legitimate to bridge or translate between those where the
>> semantic of the messages is close enough.  The question is
>> what is "close enough".
>>
>> One can argue, as I understand you do, that the transaction
>> models appropriate to particular groups of interacting
>> entities are so different that each model requires a
>> distinguished protocol.
>>
>> One can argue, as I have been, that the particular
>> transaction model doesn't need to be known to each entity,
>> only the responsibilities each entity enters into and thus
>> you can use a single protocol.
>>
>>
>> But if one believes the semantics associated with a protocol
>> are very precisely defined and reflect the overall model then
>> bridging such protocols would be inappropriate. Conversely,
>> if the semantics of protocols are considered to be limited to
>> the inter-party contract then bridging is merely a matter of
>> using the appropriate syntax for the new environment - in
>> which case you only need one protocol for web-services.
>>
>>
>> I suppose you could mean bridging in one of two contradictory
>> senses that wouldn't violate the assumptions you seem to be
>> building on:
>>
>> 	a) WS-ACID could bridge (in the sense of translate)
>> between OTS, MTS, TIP, WS-AtomicTransaction since they all
>> talk about the same transaction model. That's the same target
>> as TIP had - just a way of shipping their messages in a style
>> that is acceptable to the new (WS) environment, and the
>> ability to get inside the TMs (the latter because one of the
>> TMs must be subordinate/open-top to the other). This would be
>> the same as demonstrated in the ACTranS project we were both
>> on - especially the OTS->TIP-MTS gateway.
>>
>> 	b) "bridging" could mean getting a level of consistency
>> between transactional domains, where one wider business
>> transaction typically involves several transactions in each
>> domain, as each domain ensures it is in an internally
>> consistent state before sending messages in the inter-domain
>> protocol. (which is in fact a very common implementation
>> choice within a business transaction). That's a good answer
>> to a customers question "how do I get consistency between my
>> applications using different TMs" but it's not an answer to
>> the question "how do I bridge a transaction from TM A to TM B".
>>
>> The thing is that bridging sense a) doesn't have anything to
>> do with LRA or BP (unless you can find a model-identical
>> protocol) and sense b) doesn't have anything to do with WS-ACID.
>>
>>
>> I still assert that an approach that says a single model must
>> be understood by all the parties and the protocol must be
>> tied one-to-one to the model will not scale, whereas looking
>> only at the service-user:service expectations allows a single
>> transaction protocol that really can bridge.
>>
>> Peter
>>
>>
>> > -----Original Message-----
>> > From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
>> > Sent: 25 November 2003 21:37
>> > To: Haugen Robert; WS-CAF
>> > Subject: RE: [ws-caf] discussion on approaches for web
>> > services/ business transaction
>> >
>> >
>> > Bob,
>> >
>> > Again, I have to apologize for not agreeing that there's an
>> > issue, or perhaps just not understanding that there's an issue.
>> >
>> > The sub-protocols represent existing environments and
>> > potentially new environments that need to be bridged for the
>> > simple reason that all environments (current and potential)
>> > do not use the same protocol.
>> >
>> > The ACID and LRA tranasaction models in WS-TXM are optional,
>> > as is the BP model.  So the ACID and LRA protocols can be
>> > sub-protocols to the BP model, as can legacy protocols, WS-T,
>> > or BTP.  The ACID, LRA, and BP protocols are not required.
>> > They do not replace anything, and are intended as
>> > complementary protocols instead of replacement protocols.
>> >
>> > I'm sorry, but I still do not see the issue.  This is how
>> > WS-CAF is designed.
>> >
>> > Thanks,
>> >
>> > Eric
>> >
>> > -----Original Message-----
>> > From: Haugen Robert [mailto:Robert.Haugen@choreology.com]
>> > Sent: Tuesday, November 25, 2003 12:38 PM
>> > To: Newcomer, Eric; WS-CAF
>> > Subject: RE: [ws-caf] discussion on approaches for web
>> > services/ business transaction
>> >
>> >
>> > Eric Newcomer wrote:
>> > > the point of WS-CAF is to define a protocol complementary to the
>> > > lower level protocols, not a replacement for them.
>> >
>> > I can understand that assertion re WS-Context and WS-CF
>> > (Coordination), but the issue Peter and I and others have
>> > raised is about WS-TXM.
>> >
>> > When I read WS-TXM, I see a suite of new business transaction
>> > protocols: ACID, LRA and BP, where BP itself decomposes into
>> > a suite of sub-protocols.
>> >
>> > How do I correlate the suite of new protocols in WS-TM with
>> > your statement above?
>> >
>>