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