[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
Hi, Apologies, I should have been clearer about my suggestions. I think it would be in scope to propose rewriting WS-CAF, but I do not recommend it, or think it would be a good use of anyone's time. It would be a way to bring the matter to a vote, that's all. Mark's suggestion is much more positive, that is, about working to ensure a good mapping for BTP to WS-CF, assuming of course that's what Choreology is interested in. Eric -----Original Message----- From: Mark Little [mailto:Mark.Little@arjuna.com] Sent: Friday, November 28, 2003 5:17 PM To: Furniss, Peter; 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 I don't think the concept of "one protocol to rule them all and in the darkness bind them" (apologies to Tolkien) has yet to be proven. However, as we've said a few times, WS-TXM was always intended as a live document for new protocols to be added as and when needed. Rather than re-invent the wheel, it would seem like another approach (which would be in scope, I assume) would be to support BTP within WS-CAF and allow proponents to use that. Mark. >===== Original Message From "Newcomer, Eric" <Eric.Newcomer@iona.com> ===== >Peter, > >Thanks for this, and yes I think I would have to agree the better place for the discussion is the probably the BT email list, assuming that that list is intended for debates on broad, abstract topics. > >I think there are two ways to proceeed that would put your suggestion in scope: > >1) Write a detailed issue, with page numbers, text citations, and proposed new text to clearly illustrate the impact of the suggestion on the current spec drafts >2) Create a new spec draft for consideration as potential input to the WS-CAF TC > >I do not think we really have any way to deal with such a broad and abstract suggestion. We will need something definite and concrete to vote on. > >Eric > >-----Original Message----- >From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] >Sent: Friday, November 28, 2003 12:48 PM >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 > > >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? >> > >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]