Re: [ws-caf] WS-ACID

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

Green, Alastair J. wrote:

> 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?
>
I've sent this in a separate email, but:

"[snip] 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 [snip]"

I read the minutes and implicitly took that meaning from them. I suppose 
it is possible for those who weren't there to come away with a different 
view. Assuming that everyone else has the same recollection, then maybe 
we should update the minutes?

> 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?
>
Not dead, just postponed so we can concentrate on one at a time: we've 
all got limited bandwidth.

Web Services are as much about interoperability as they are about the 
Web (or internet scale computing). Likewise, Web Services transactions 
need to support interoperability with closely coupled ACID transaction 
systems (such as CICS, ATS, Encina, Oracle etc.) and loosely coupled, 
long duration transactions. From our (and I'm using that as a collective 
term) experiences, seperate protocols for these approaches makes sense. 
That's not to imply that we should only be providing 2 protocols: I 
think the area of loosely coupled, extended transactions is a wide one, 
as can be seen by all of the research that's gone on there over the 
years; so more than one protocol here may be required.

But given that, it seemed obvious to the TC that showing 
interoperability between existing ACID transaction systems was critical; 
start with WS-ACID. We need to convince users that we are not going to 
require them to discard their existing infrastructural investments and 
we are all seeing more need for the solution provided by WS-ACID. For 
example, just in the J2EE space, companies no longer want to be tied to 
a single application server, or they have grown by acquisition and find 
themselves in a heterogeneous environment which they have to support. 
All of this points to the fact that we need to work on WS-ACID first.

> * * *
>
> 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.
>
There was discussion by a quorate TC at New Orleans. The discussion was 
publicised well in advance of the meeting.

> 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.
>
Agreed, and we have started that process with the transaction space. 
After our New Orleans presentation of the protocols, there was 
discussion as to the way ahead. Now that we are moving up the stack or 
protocols, we are moving into more specific (less generic) areas, where 
experience counts. I like to think we're all agreed that Oracle and IONA 
(at least) have enough experience in this area.

> 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?
>
I don't think that's the situation at all. I think it is a case of 
looking at what the market wants (what our users are telling us they 
want and don't want), our past experiences etc. They are all telling us 
that a separation of concerns into different protocols is the approach 
to take. That's certainly why I voted in New Orleans to accept the proposal.

I'm not suggesting that a BTP-like approach should be rules out as *one* 
of the protocols we support. I'm happy to consider a mapping to BTP if 
you think it is a requirement for your customers. I'm just not happy to 
consider it as the only protocol we support. Hence the New Orleans vote.

>
> * * *
>
>
> 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.
>
Great. Let's do that binding and we can say we cover all bases.

> 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.
>
We're not dropping elements. BTP can still be considered: as a binding 
we support.

Mark.

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