[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]