[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] RE: State table intent (was RE: [ws-tx] Issue 036 - WS-AT: Coordinator state machine incomplete)
Peter,
Are you suggesting you would choose to implement
this way unless the spec explicitly forbid it? If so I have to ask the
question if you think the TC is in the advice and tutorial business? I
mean, are we seriously suggesting that we should be offering guidance to
implementors? I think that is a very different proposition than creating
an interoperability spec.
Eric
-----Original
Message-----
From: Peter Furniss <peter.furniss@erebor.co.uk>
To:
Ian Robinson <ian_robinson@uk.ibm.com>; Newcomer, Eric
<Eric.Newcomer@iona.com>
CC: ws-tx@lists.oasis-open.org
<ws-tx@lists.oasis-open.org>
Sent: Wed Jun 14 16:20:42 2006
Subject:
RE: [ws-tx] RE: State table intent (was RE: [ws-tx] Issue 036 - WS-AT:
Coordinator state machine incomplete)
I don't want to overspecify the
internal workings either, but sending a
protocol message is obviously
external behaviour - in fact it's the only
thing that is.
It is
obviously wrong for a participant to do something
like:
...
send
Prepared
(no other protocol
events)
send Committed
Or
indeed
...
send
Prepared
send
Aborted
send
Prepared
send
Committed
send Prepared
If
you don't make the prohibitions I proposed (no state change, no
sending
except as allowed), I don't see how you forbid those behaviours.
Without
those rules, the implementation can claim it internally switched
from
PreparedSuccess to Committing and back again.
A critical part of the text
I proposed was that the states (and internal
events) are abstract - from an
interoperable perspective, the only way
the outsider knows that the
implementation considered itself to be
PreparedSuccess was because it sent
Prepared. But because it did send
Prepared, then the outsider knows it was in
PreparedSuccess and (by my
rule) it can't go to Committing until and unless
it receives Commit.
What the implementation does to get itself into the
Prepared state is
its problem.
You can take an alternative path,
and define the internal events MORE
concretely - which is what OTS does for
example. This may be more
natural, and easier to follow, but avoiding
over-specification can make
it wordy.
Yet another path is to drop
this level of specification altogether -
which is roughly what the TIP rfc
did - and assume its all well-known
transactionality. I'm not quite so sure
its really as well agreed as
people might think - some of the discussions in
Dublin hinged on edge
cases where just assuming all implementations will do
the same thing
would produce implementations which "interoperated" to
exchange the
right protocol messages, but actually failed to deliver atomic
behaviour
of the work if spread across heterogeneous
implementations.
Peter
-----Original Message-----
From: Ian
Robinson [mailto:ian_robinson@uk.ibm.com]
Sent:
14 June 2006 13:57
To: Newcomer, Eric; Peter Furniss
Cc:
ws-tx@lists.oasis-open.org
Subject: RE: [ws-tx] RE: State table intent (was
RE: [ws-tx] Issue 036 -
WS-AT: Coordinator state machine
incomplete)
Eric, I agree.
We do not want to suggest that the
state tables govern all aspect of the
internal behaviour of an implementation
so perhaps we can improve things
a little and clarify what the scope of
"Internal Events" actually means.
As discussed previously, the main body of
the table describes
action/transition in the event that a protocol message is
received by a
protocol endpoint; the "Internal Events" are provided to
illustrate
state transitions and protocol message generation that occurs as
a
result of something other than receipt of a protocol message.
The spec
currently states "Internal events are those that are created
either within a
TM itself, or on its local system."
Perhaps the spec would be clearer if
we stated instead:
The "Internal events" shown are those events, created
either within a TM
itself or on its local system, that cause state changes
and/or trigger
the sending of a protocol message.
Beyond this, Section
10 already clearly states: "These tables present
the view of a coordinator or
participant with respect to a single
partner. A coordinator with
multiple participants can be understood as
a collection of independent
coordinator state machines."
Peter has suggested a modification to this
text that includes the phrase
that Eric commented on below. I agree with
Eric's comment. I suggest we
modify the first paragraph of WS-AT section 10
basde on a part of
Peter's proposed text:
"The following state tables
specify the behavior of coordinators and
participants when presented with
protocol messages or internal events.
These tables present the view of a
coordinator or participant with
respect to a single partner. A
coordinator with multiple participants
can be understood as a collection of
independent coordinator state
machines <addition>, each with its own
state. </addition>."
In summary, I propose a resolution to this
issue as follows:
1. Append the text "each with its own state" to the first
paragraph of
section 10.
2. Replace "Note 2" of section 10 with "The
"Internal events" shown are
those events, created either within a TM itself
or on its local system,
that cause state changes and/or trigger the sending
of a
protocol
message."
Ian
"Newcomer,
Eric"
<Eric.Newcomer@io
na.com>
To
"Peter
Furniss"
13/06/2006 19:13
<peter.furniss@erebor.co.uk>,
<ws-tx@lists.oasis-open.org>
cc
Subject
RE: [ws-tx] RE: State
table
intent
(was RE: [ws-tx] Issue 036
-
WS-AT:
Coordinator state
machine
incomplete)
Peter
- I think that sentence amounts to overspecification. I do not
regard
our spec (or any other interop focused spec for that matter) as
needing to
constrain implementation by stating what one cannot do. I
think the
spec needs to define the expected behavior, what an
implementation should or
must do, but adding such a "must not" is not
necessary and in fact introduces
unnecessary burden on the implementor.
Eric
Ý 781 902 8366
fax:
Ý 781 902 8009
blog: www.iona.com/blogs/newcomer
Making Software Work
Together (TM)
From: Peter Furniss [mailto:peter.furniss@erebor.co.uk]
Sent:
Monday, June 12, 2006 10:58 AM
To: ws-tx@lists.oasis-open.org
Subject:
[ws-tx] RE: State table intent (was RE: [ws-tx] Issue 036
-
WS-AT:
Coordinator state machine incomplete)
I was going to put
something to capture what seemed to be an emerging
consensus at the f-t-f on
some specific changes to the state tables, but
before I do, I'd like to know
if the assertion:
"Although the states and internal events are modelling
abstractions, an
implementation must not make state transitions or send
protocol messages
other than as permitted by these tables"
is
considered true or false.
(of course, if there was an emerging consensus,
it's open to anyone else
to suggest text)
Peter
From: Peter
Furniss
Sent: 08 June 2006 10:57
To: 'Ram Jeyaraman';
ws-tx@lists.oasis-open.org
Subject: State table intent (was RE: [ws-tx] Issue
036 - WS-AT:
Coordinator state machine incomplete) Following the discussion
at the
end of the f-t-f, I believe the first thing we need to get quite
clear
is what the state tables are intended to do - the second being to
make
sure the text makes it clear what that is (if it doesn't currently)
and
the third to make sure the tables correctly deliver their intent
(if
they don't currently).
I believe it was the consensus
that
the tables are to define the externally visible
behaviour on a
single coordinator:participant
relationship
there is a separate Coordinator view state
machine for each
participant (with independent states)
It was also
said that the tables "did not cover all the internal
behaviour"
of an
implementation
Although that last statement is undoubtedly true, I think
it needs a bit
of clarification. In particular, we cannot state that the act
of sending
a message is "internal" - it is obviously externally visible. Thus
any
sending of a message needs to be justified by an entry in the
state
table that permits the sending. In consequence, although states are
in
one sense internal, if the state table is to mean anything,
the
transitions between states have to be regarded as externally
visible.
The actual stimulus both to change state, and to send the message
may be
internal. And of course the state itself is a modelling abstraction -
it
may not really correspond to a value held in the machine (it might
be
implicit in a "program counter" for example).
If we don't regard
the state transitions as external - i.e. we allow
that an implmentation may
make arbitrary transitions that are not
reflected in the state table, then
the table becomes a nonsense. For
example, an implmentation could do the
sequence send Prepare, send
Commit, receive Prepared, send Rollback, send
Commit by asserting that
it had made legitimate (but hidden) internal
transitions thus permitted
such.
Is this the consensus ? If
it is, then I think it would be helpful to
expand the introduction text to
the state tables to say so (if it isn't,
then it is absolutely essential to
expand that introduction to say what
we eventually agree the table scope
is).
I'd suggest adding text at the end of the first paragraph of clause
10 :
The following state tables specify the behavior of coordinators
and
participants when presented with protocol messages or internal
events.
These tables present the view of a coordinator or participant
with
respect to a single partner. A coordinator with multiple
participants
can be understood as a collection of independent coordinator
state
machines <addition>, each with its own state. Although the states
and
internal events are modelling abstractions, an implementation must
not
make state transitions or send protocol messages other than as
permitted
by these tables</addition>.
We may want to
re-arrange or expand that further, especially to explain
more fully what sort
of real events are abstracted by the internal
events.
If we are agreed
that all sending and transitions have to be supported
by the state table, we
then need to make sure all legitimate events are
shown.
If we don't agree,
I will propose deleting the state tables as they are
only
confusing.
Peter
From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
Sent:
28 March 2006 19:17
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] Issue
036 - WS-AT: Coordinator state machine incomplete
This is identified as WS-TX
issue 036.
Please ensure follow-ups have a subject line starting "Issue
036 -
WS-AT:
Coordinator state machine incomplete".
From: Peter
Furniss [mailto:peter.furniss@erebor.co.uk]
Sent:
Monday, March 27, 2006 1:06 PM
To: ws-tx@lists.oasis-open.org
Subject:
[ws-tx] New issue: WS-AT: Coordinator state machine incomplete
Issue name
-- WS-AT: Coordinator state machine incomplete
PLEASE DO NOT REPLY TO
THIS EMAIL OR START A DISCUSSISON THREAD UNTIL
THE ISSUE IS ASSIGNED A
NUMBER.
The issues coordinators will notify the list when that has
occurred.
Target document and draft:
Protocol:
WS-AT
Artifact: spec
Draft:
AT spec cd 1
Link
to the document referenced:
http://www.oasis-open.org/committees/download.php/17325/wstx-wsat-1.1-sp
ec-cd-01.pdf
Section
and PDF line number:
section 10, lines 493 - 510
Issue
type:
Design / Editorial
Related issues:
New issue:
WS-C, WS-AT, WS-BA: Term "Coordinator" overloaded New issue:
WS-AT:
Register/Preparing in coordinator state table problematic
Issue
Description:
The WS-AT coordinator state tables do not provide
explanation of what
the states or internal events are, and do not provide
specification of
the interactions between the completion, volatile and
durable protocols.
Issue Details:
The WS-AT state tables
are described as showing " the view of a
coordinator or participant with
respect to a single partner. A
coordinator with multiple participants can be
understood as a collection
of independent coordinator state machines". In
fact they appear to use
the states and internal events of the multi-lateral
coordinator but
inbound events for a single partner. In the absence of any
explanation,
especially of the internal events, this is confusing (and there
seem to
be some inconsistencies).
There is also little or no
specification in the state tables of the
interactions between the completion,
volatile and durable protocols
(which essentially determine that the
transaction is atomic).
Evidence of multilateralism:
A
bilateral state engine will move from None to Active on receiving
Register.
"Active" thus has to be interpreted as the state of the
multilateral
coordinator.
Receipt of ReadOnly would cause a bilateral state engine
to go from
Active to None - the tables show it as having no effect on the
state.
Lack of protocol interaction
the tables provide no
specification of the volatile-first behaviour -
except perhaps in the
Register/Preparing cell, which is cannot be
harmonised with the rest of the
table (see separate issue)
if "User Commit" is to be interpreted as
Commit on the Completion
protocol (or its non-standardised equivalent), then
a Prepare shouldn't
be sent to a Durable Participant until all the Volatiles
have replied.
The Commit Decision event is presumably meant to
occur when all
participants have replied Prepared or ReadOnly, but according
to the
state table it could occur any time after Prepare has been
sent.
Proposed Resolution:
Create separate tables for the
multilateral and bilateral relationships,
and define what all the states and
events mean.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]