OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Another thought:

> Thanks for this, but as you say, this discussion largely 
> boils down to a matter of opinion.  

Which is the most useful approach is a matter of opinion, but in which
sense were you using "bridge" ?  Or do you disagree with the distinction
I made ?

Peter
 
> If there are specific issues here for the WS-CAF specs I have 
> to say I still can't either understand or recognize them.  
> 
> I think what we are interested in as a TC are specific 
> suggestions, corrections, amendments etc to the WS-CAF drafts.
> 
> 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?
> > 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]