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




Furniss, Peter wrote:

>The documentation relationship of the things is not at issue. Separate
>documents for separate protocols is generally the current direction of
>things (and historically, different standards groups have gone different
>ways in splitting and lumping).
>
>The point is, why these three ? 
>
We're not saying there are three. What we are saying is that there will 
(probably) be at least two: one for interoperability with existing TP 
systems, and one for long duration interactions. What we agreed in New 
Orleans was that the first of these we would address would be WS-ACID.

>Are each useful separations AS PROTOCOLS
>from
>each other, addressing different requirements that cannot be met by use
>of
>each other or by some other arrangement of functionality. Given the 
>range of function of the set, is there a need for more than one protocol
>?
>  
>
Yes. Without opening up the discussion again (I keep coming back to this 
point: we were quorate at New Orleans and voted to take this approach), 
it appears that the majority of the industry (including those players 
not within this TC) agree from experience and customer input, that the 
approach of protocols-per-problem-domain is the right one. We've seen 
the almost complete failure of adoption of any other approach time and 
time again, for many reasons (technical included).

But, we're not ruling out a binding to BTP for those vendors who 
strongly believe that it is the right approach. I fail to see how this 
is a bad compromise, since it gives all parties what they want. Since 
we'll probably be defining a conformance statement for CAF/TXM that says 
(and I paraphrase): "you don't have to support all protocols to be 
conformant", it also means that a vendor who is only interested in, say, 
the BTP binding, can support that to total exclusion of the other protocols.

Mark.

>(not entirely exact comparison: there is one IP, and for a long time
>there were only two general-purpose transport protocols on it. All sorts
>of higher uses
>could have invented their own equivalents to UDP and TCP, but didn't.
>Eventually the range of applications expanded beyond that (e.g. VOIP).
>Is the range of function covered by the input TXM set analogous to 
>transport requirements of Telnet to SMTP, or does it range wider (c.f.
>DNS and VOIP))
>
>Peter
>
>  
>
>>-----Original Message-----
>>From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] 
>>Sent: 26 May 2005 13:55
>>To: Martin Chapman; Green, Alastair J.; Mark Little; ws-caf
>>Subject: RE: [ws-caf] WS-ACID
>>
>>
>>I don't consider whether the models/protocols are in one spec 
>>or three to be a technical issue.  I think we are happy to 
>>debate the merits of the various models at the upcoming face 
>>to face.  My understanding is the decision was made during 
>>the previous F2F to separate the content, not change it.  
>>Whether or not it makes the discussion easier or more 
>>difficult is certainly a matter of opinion but I would say 
>>the more substantive issues relate to the content rather than 
>>the form of the specs.
>>
>>I believe we also said during this week's call that we'd 
>>start the discussion on WS-TXM etc. during the next concall.  
>>Email debate on them is of course fine in advance.
>>
>>But I don't think that was meant to reopen the decision about 
>>splitting up the spec(s).  My understanding was the 
>>discussion would start from where we are following the 
>>results of previous F2F.
>>
>>Eric
>>
>>-----Original Message-----
>>From: Martin Chapman [mailto:martin.chapman@oracle.com] 
>>Sent: Thursday, May 26, 2005 8:34 AM
>>To: 'Green, Alastair J.'; 'Mark Little'; 'ws-caf'
>>Subject: RE: [ws-caf] WS-ACID
>>
>>Alastair,
>>
>>TXM is just a collection of different TX models. There is no 
>>real design philosophy that binds them aside from 
>>being built on context and CF. Hence the decision to separate 
>>and let them have independent existence. So lets 
>>debate/design each one based on the goals each is trying to achieve. 
>>
>>Cheers,
>>  Martin.
>>
>>    
>>
>>>-----Original Message-----
>>>From: Green, Alastair J. [mailto:Alastair.Green@choreology.com]
>>>Sent: Thursday, May 26, 2005 10:34 AM
>>>To: Mark Little; ws-caf
>>>Subject: RE: [ws-caf] WS-ACID
>>>
>>>
>>>Hi Mark,
>>>
>>>I think that we should take a step back. Why are there three
>>>specs in the WS-TXM family? Are they actually needed, or the 
>>>right ones? What are we trying to achieve/what are the 
>>>underlying requirements? This is very major phase of work, and 
>>>not one to be rushed at.
>>>
>>>The history of this TC is that a review of fundamental
>>>principles/model/architecture has usefully led to 
>>>simplification towards the genuinely general, both with 
>>>Context and WS-CF.
>>>
>>>I would like to propose a full discussion of the model and
>>>principles behind the current WS-TXM input documents and their 
>>>separation of powers at the face to face. I think I am right 
>>>in saying that you have raised, for example, the question as 
>>>whether WS-TXM BP is useful as an independent spec.
>>>
>>>In my view the WS-TXM specs as they stand are a very
>>>complicated way of achieving a set of fairly-well understood 
>>>goals. They also raise a couple of interesting new ideas (or 
>>>at least not so generally accepted ideas).
>>>
>>>If WS-TXM is to be a useful competitor to WS-BA/AT then it
>>>should be helpfully different (better, simpler, more functional etc).
>>>
>>>If WS-TXM is heading for the fate of WS-Reliability, then it
>>>might be more apposite to seek emulation, rather than 
>>>competition -- i.e. get the capitulation over with quickly, 
>>>and provide some helpful additional features that the WS-TX TC 
>>>will be able to take note of as it spits and polishes the 
>>>      
>>>
>>BA/AT specs. 
>>    
>>
>>>Per se, I have no objection to a legacy-adaption spec which
>>>enables OTS vendors to respray the wire in XML colours, but I 
>>>think we are jumping ahead too fast.
>>>
>>>Parenthetically, it seems that the difference between ACID and
>>>AT is the difference between OTS and OLE-Tx. 
>>>
>>>Heuristics are quite traditional, and I suspect the lack of
>>>heuristics wouldn't survive an open standardization of 
>>>      
>>>
>>WS-AT, if/when.
>>    
>>
>>>Alastair
>>>
>>>Alastair J. Green
>>>CEO and CTO
>>>Choreology Ltd
>>>68 Lombard Street
>>>London EC3V 9LJ
>>>www.choreology.com
>>>
>>>+44 870 739 0050
>>>+44 870 739 0051 (fax)
>>>+44 795 841 2107 (mobile)
>>>
>>>
>>>-----Original Message-----
>>>From: Mark Little [mailto:mark.little@arjuna.com]
>>>Sent: 25 May 2005 20:29
>>>To: ws-caf
>>>Subject: [ws-caf] WS-ACID
>>>
>>>Ignoring the differences in WS-Context and WS-CAF that may impact
>>>WS-ACID, does anyone have any issues with the protocol or 
>>>      
>>>
>>model as it 
>>    
>>
>>>currently stands?
>>>
>>>I can summarise the differences between it and traditional ACID
>>>transactions if needed. If you're looking for major 
>>>differences between 
>>>WS-ACID and WS-AtomicTransaction then they probably come down to: 
>>>WS-ACID uses a synchronization protocol, whereas WS-AT uses 
>>>volatile 2PC
>>>
>>>for "volatile" pre/post commit processing, and WS-AT doesn't support
>>>heuristic outcomes (there's an "protocol violation" error 
>>>message which 
>>>isn't quite useful enough).
>>>
>>>Mark.
>>>
>>>--
>>>Mark Little
>>>Chief Architect
>>>Arjuna Technologies Ltd
>>>(www.arjuna.com)
>>>
>>>
>>>      
>>>
>>
>>    
>>

-- 
Mark Little
Chief Architect
Arjuna Technologies Ltd
(www.arjuna.com)



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]