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