[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] WS-ACID
|
I think absolutely it’s consistent with
our intention, and hopefully explicit statements somewhere along the line, that
we’d be interested in considering a mapping of BTP to WS-CF. Eric From: Green, Alastair
J. [mailto:Alastair.Green@choreology.com] 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?
The WS-CAF TC will accept as input the
WS-Context, WS-Coordination Framework and WS-Transaction Management
specifications [1] published by Arjuna, Fujitsu, 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 J. Green CEO and CTO Choreology Ltd www.choreology.com +44 870 739 0050 +44 870 739 0051 (fax) -----Original Message----- 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 > > >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]