Re: [ws-caf] WS-ACID

[Mark Little <mark.little@arjuna.com>]

Apologies for not replying to this thread yesterday, but I was 
presenting on WS-CAF at XTECH 2005 (I'll upload the presentation later) 
and had no network connectivity. It also means you may see replies out 
of order now, as I go through my email. It was a day trip: very early 
start, very late finish, so I may just take another 40 winks after this ;-)

Just to clarify what Martin says; at New Orleans it was agreed by the TC 
(by vote) that we would separate out the 3 models (WS-ACID, WS-LRA and 
WS-BP) into their own specifications; furthermore, that we would start 
work on WS-ACID first, though issues against the other models could 
still be raised in preparation for future discussions. It was also 
agreed (again by vote) that the concept of transaction 
"micro-protocols", or more specifically protocols that would be 
targetted at specific use cases and not the "one size fits all" 
approach, would be taken. We mentioned BTP as a possible additional 
protocol which WS-CAF might provide a binding for that would address the 
latter style, if users really saw a need. The TC saw no point in 
reinventing BTP within WS-CAF; it would be like reinventing SOAP or WSDL 
- better to use what is already there if there's a requirement for it.

I think this is entirely consistent with what we've been talking about 
every time transactions have come up in this TC. There have been several 
occassions within prior teleconferences and face-to-face meetings where 
this approach has been discussed. It wasn't until New Orleans that it 
was voted on, however. I think this is a good opportunity to move things 
forward efficiently, rather than getting bogged down in the same old 
discussions.

Mark.


Martin Chapman wrote:

> let me just answer this part:
> "So why are we fixing on the original three inputs in this rigid way?"
> The short answer is because it is in the charter!
> To do differently would require a major rechartering which under the 
> current regime means effectively stopping this tc and writing a new 
> charter.
> We agreed in NO to split the document in three and start with ACID. We 
> made no decision as to when we will start on the other 2.
> Martin.
>
>     -----Original Message-----
>     *From:* Green, Alastair J. [mailto:Alastair.Green@choreology.com]
>     *Sent:* Thursday, May 26, 2005 6:38 PM
>     *To:* Newcomer, Eric; Martin Chapman; Mark Little; ws-caf
>     *Subject:* RE: [ws-caf] WS-ACID
>
>     I'm sorry but this feels like form and procedure are impeding
>     content.
>
>     What exactly did the TC F2F decide about this matter? When I read
>     the minutes it was not clear: did Greg’s motion mean that LRA and
>     BP are dead? Was it passed?
>
>     If I see what has happened since and the responses from Eric and
>     Martin it looks as if some members believe that all three will be
>     discussed. But separately, one after the other? Are the
>     requirements that drove LRA and BP’s inclusion now deemed to be
>     dead and buried, or wrong?
>
>     * * *
>
>     I am uninterested in one document or three (other than ease of
>     use) -- if it makes sense to have three protocols.
>
>     Should there be three? Why should there be three? What are the
>     requirements and purposes of these three? Can they be achieved by
>     one protocol, or two, or three? I think these basic questions
>     deserve a bit more consideration, including e-mail discussion that
>     can be assimilated properly.
>
>     The history of this TC, to repeat, is that a genuine step back and
>     review of principles has simplified and reduced the output
>     relative to the input.
>
>     Technically, there is no reason why the goals of all three of
>     these specs cannot be met by one spec whose overlap of content
>     with respect to the goals of each will be about 95%. But perhaps
>     the TC now longer wishes to accommodate any goals other than
>     XMLization of flat-model OTS, in the transaction arena?
>
>
>     * * *
>
>
>     Let me raise another question, while we are on this subject,
>     measuring against the TC's charter --
>
>     The WS-CAF TC will accept as input the WS-Context, WS-Coordination
>     Framework and WS-Transaction Management specifications [1]
>     published by Arjuna, Fujitsu, Iona, Oracle, and Sun Microsystems
>     on July 28 2003. Other contributions in addition to WS-CAF will be
>     accepted for consideration without any prejudice or restrictions
>     and evaluated on their technical merit, as long as the
>     contributions conform to the goals and scope of this charter.
>
>     The benefits and results of this work will be standard and
>     interoperable ways to:
>
>     Demarcate and coordinate web service activities
>
>     Propagate and coordinate context information
>
>     Notify participants of changes in an activity
>
>     Define the relationship of coordinators to each other
>
>     Recover transactions predictably and consistently in a business
>     process execution.
>
>     Interact across multiple transaction models (such as are used in
>     CORBA, CICS, Enterprise JavaBeans? or .NET environments).
>
>     OASIS BTP is capable, with some slight modifications, of being
>     bound to WS-CAF Context and CF. It would allow you to handle any
>     of the goals specified in the charter -- you can run distributed
>     ACID over it (we do); you can use it to handle nested scope
>     compensations and other models of BPM transactions (we have
>     designed this in great detail and it is on our product roadmap),
>     and you can bridge similar protocols (e.g. WS-AT and WS-BA, or
>     WS-Acid and WS-LRA) using it (we do in the case of the two former).
>
>     So why are we fixing on the original three inputs in this rigid
>     way? Or only one of them?
>
>     I believe that as we now come to the discussion about
>     transactions, we need to precisely evaluate the technical merits
>     of all available inputs. We also need very clear and well-argued
>     (and properly considered) motivations if we are going to make
>     decisions to drop elements laid out in the charter.
>
>
>     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)
>
>     -----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)