[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] WS-ACID
I think WS-CAF is very open to the submission of BTP as adapted to the WS-CF and WS-CTX foundation, as another protocol to plug into the framework. The debate about which one (if any) of the protocols is superior is something that the market, or the customer, can decide given the choice. I do not think the charter of WS-CAF gives the committee the direction to make this choice; the direction is to develop an open framework compatible with multiple protocols. The BTP TC already exists for the purpose of progressing BTP. The WS-CAF TC exists for a different reason. I think we have been very clear and consistent about the interest in receiving a submission of BTP fit into the WS-CAF model. The debate about which protocol is better does not seem relevant since WS-CAF is open to any and all, and we as spec writers do not have the power to determine what the market will accept. If we fit BTP on WS-CF and the market adopts it and not ACID, LRA, or BP, then fine. Eric -----Original Message----- From: Haugen Robert [mailto:Robert.Haugen@choreology.com] Sent: Friday, May 27, 2005 9:48 AM To: ws-caf Subject: RE: [ws-caf] WS-ACID Mark Little wrote: > Haugen Robert wrote: > >But I see that you have actually had the same experience, > that people > >want one transaction protocol to cover many types of participants - > >where the behavioral differences are in the participants, not the > >protocol: > > > No, that talks about transaction bridging within the same model. For > example, JTA-to-WSAT-to-JTA. It's not JTA-to-WSBA-to-WSAT in that > description. Where we've seen that kind of bridging, something like > WS-BP is appropriate. In the more common bridging (homogeneous model) > then something like WS-ACID does this for us automatically > (and WS-AT). With a tweak or two, something like WS-ACID could also bridge WS-BA, and with one tweak (fault on close), something like WS-BA could also bridge WS-ACID. > The text (if you read it all,) explicitly talks about implementation: > how you support multiple protocols is a back-end > implementation choice > and should not be reflected in those protocols. Part of my point here is that they're not really different "transaction models", they are mostly just differences in participant behavior. And all of the different protocols are mostly just different names for the same messages. But I agree that this is the same old argument, and we will not convince each other. Moving ahead, I think the climate of public opinion has shifted since our previous thread on this same topic. A groundswell rises against the complexity and proliferation of WS-* specs. Oracle joins WS-RX TC as sponsor. JSR158 opens another front. I'd prefer one, but don't see how any more than two business transaction specs will survive.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]