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