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


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]