[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] WS-ACID
BTP has had many years to establish that it is a viable approach to the business transaction space and has failed to attract either customers or established software vendor support. Regurgitating a more or less universally rejected model is unlikely to do anything other than push this TC toward the same irrelevancy that BTP has enjoyed. Contra Alastair, WS-RX has established once and for all that the community is able to converge -- including supporters of WS-Reliability and WS-Reliable Messaging -- on a common forum to advance the Web services stack toward a single, interoperable standard. Convergence of closely related efforts in the transaction space would not be unwelcome. So we can get this out of the way without creating prolonged churn, let's aim to resolve whether the TC should proceed forward with the model embodied in the submitted specifications (providing support for multiple protocols as appropriate for specific domains) by vote at the earliest possible opportunity, ideally before the next f2f. Our position is in favor of the existing approach. Greg Pavlik Web Services Architect Oracle Corporation
--- Begin Message ---Title: Message
- From: "Green, Alastair J." <Alastair.Green@choreology.com>
- To: "Martin Chapman" <martin.chapman@oracle.com>, "Newcomer, Eric" <Eric.Newcomer@iona.com>, "Mark Little" <mark.little@arjuna.com>, "ws-caf" <ws-caf@lists.oasis-open.org>
- Date: Fri, 27 May 2005 00:44:20 +0100
--- End Message ---
The charter:
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.
I submit OASIS BTP as another contribution. It addresses all of the transactional targets of this TC. It does not contradict any of the other charter goals.
What was the decision on Greg’s motion? The minutes are unclear.
Alastair
-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com]
Sent: 26 May 2005 20:52
To: Green, Alastair J.; 'Newcomer, Eric'; 'Mark Little'; 'ws-caf'
Subject: RE: [ws-caf] WS-ACID
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-ACIDI'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)
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]