[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
BTW, I'm happy to continue this discussion, but the previous email is just a heads-up that a) my responsiveness will be much impaired over the next couple of weeks, and b) I think the BTP list (or private email) is a more appropriate discussion forum. Mark. ---- Mark Little, Chief Architect, Transactions, Arjuna Technologies Ltd. www.arjuna.com ----- Original Message ----- From: "Mark Little" <mark.little@arjuna.com> To: "Haugen Robert" <Robert.Haugen@choreology.com>; "Newcomer, Eric" <Eric.Newcomer@iona.com>; "WS-CAF" <ws-caf@lists.oasis-open.org> Cc: <business-transaction@lists.oasis-open.org> Sent: Monday, December 01, 2003 10:06 AM Subject: Re: [ws-caf] discussion on approaches for web services/ business transaction > Robert, I get the distinct feeling we are going round in circles. You have > yet to prove that a single protocol is suffice for all situations. BP > doesn't say that it should be used in all situations and that isn't the case > for WS-TXM. > > Sorry for the brief response, but I have to prepare for the WS-CAF > face-to-face and I suspect all of this discussion is out of scope for that > TC. > > Mark. > > ---- > Mark Little, > Chief Architect, Transactions, > Arjuna Technologies Ltd. > > www.arjuna.com > > ----- Original Message ----- > From: "Haugen Robert" <Robert.Haugen@choreology.com> > To: "Mark Little" <mark.little@arjuna.com>; "Newcomer, Eric" > <Eric.Newcomer@iona.com>; "WS-CAF" <ws-caf@lists.oasis-open.org> > Cc: <business-transaction@lists.oasis-open.org> > Sent: Sunday, November 30, 2003 10:15 PM > Subject: RE: [ws-caf] discussion on approaches for web services/ business > transaction > > > > > > > There are good reasons for having specific protocols and > > > > > against generic ones > > > > Sure. Tightly-coupled internal transactions... > > > Now who's being extreme - this is certainly *a* reason > > > but is neither necessary nor sufficient. > > > > I'll get a little more extreme below...and even claim that WS-TXM makes > > the case for a generic protocol. > > > > > > > and on occassion vice versa. > > > > Loosely-coupled external transactions, especially spanning different > > > > companies. > > > Same as above. > > > > Consider the case of participants (not coordinators) in loosely-coupled > > external transactions. > > > > If I have a generic protocol, I can develop generic participants and > > [enrol|enlist|register] them in any business transaction. > > > > In other words, those participants would be freely composable. > > > > If I don't have a generic protocol, then I need either different > > participants for each protocol or adapters-with-mappings for each > > protocol. > > > > The participants would not be freely composable. > > > > > > You could propose a protocol to be included in WS-TXM > > > > (even BTP I suppose) that accomplished the things you want to see. > > > > I think even BTP is too complicated for the generic participant. I > > don't see any cost-effective justification for a loosely-coupled > > participant to care whether the business transaction is atomic, or > > cohesive, or whatever. Coordinator, yes; participant, no. > > > > I know the argument about wanting more guarantees about participant > > behavior, but if it's externally undetectable behavior (e.g. Isolation), > > you can't enforce the guarantees anyway. > > > > ** Rash Claim ** > > > > Actually, WS-TXM has its own attempt at a generic protocol: BP. > > Describing interposition between subdomains, the WS-TXM-BP spec says: > > > > "Each domain is represented by a subordinate coordinator that masks the > > internal business process infrastructure from its parent. Not only does > > the interposed domain require the use of a different context when > > communicating with services within the domain (the coordinator endpoint > > is different), but each domain may use different protocols to those > > outside of the domain: the subordinate coordinator may then act as a > > translator from protocols outside the domain to protocols used within > > the domain. > > > > "For example, a domain may be implemented entirely using the OASIS BTP > > with the interposed coordinator responsible for mapping BP protocol > > messages into BTP's atom or cohesion messages and vice versa. Another > > domain (possibly in the same overall business process) may use the OMG's > > Object Transaction Service (OTS) and therefore provide an interposed > > coordinator to translate between the BP model and the OTS. The important > > point is that as far as a parent coordinator in the BP hierarchy is > > concerned it interacts with participants and as long as those > > participants obey the BP protocol, it cannot determine the > > implementation." > > > > In which case, assuming the BP protocol could work as described, then it > > is a universal protocol. So either WS-TXM has its own proof of the > > feasibility of a universal protocol, or WS-TXM-BP won't work as > > advertised. > > > > I think BP is too complicated and contains too many sub-protocols to be > > a good candidate for a generic protocol, but that's beyond the arguments > > for and against the concept and on to the more-interesting discussion of > > what makes a good generic protocol. > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]