[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 – 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] 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 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] 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] 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: Section and PDF line number: section 10, lines 493 - 510
Design / Editorial
New issue: WS-C, WS-AT, WS-BA: Term "Coordinator"
overloaded
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 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).
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]