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


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



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