[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: Coordinatorstate 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
+1 781 902 8366
fax: +1 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-spec-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]