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

["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?
> > 
>