OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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