RE: [ws-caf] WS-ACID

["Furniss, Peter" <Peter.Furniss@choreology.com>]

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 ? 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
?

(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)
> >
> >
> 
> 
>