Re: [ws-tx] Issue 041 - WS-AT: Invalid events should not cause definedtransitions

[Mark Little <mark.little@jboss.com>]

+1

Peter Furniss wrote:
> I agree that distinguishing circumstances of faults is generally a 
> good thing. Equally, one can also have too much of a good thing :-)
>  
> But the problem with InconsistentInternalState is that the definition 
> in the text doesn't correspond with the use in the state table. 
> Definition says its when the participant cannot fulfil its 
> obligations. That presumably would be apply when a participant has 
> gone prepared but now cannot obey the Commit or Rollback it receives 
> (which sounds suspiciously like a heuristic warning which would be out 
> of charter for this TC).
>  
> But the use in the state tables is that Participant sends it when it 
> receives contradictory messages from the coordinator - sending both 
> Rollback and Commit (in either order). That would seem to be no 
> different from any of the other InvalidState circumstances = "I am 
> receiving messages that should not happen in the state I am now in - 
> either you have sent a message you shouldn't have done or I've made a 
> state transition I shouldn't have done".
>  
> Receiving InvalidState should certainly cause an alert - but it's a 
> pretty serious one, because someone isn't conformant - the parties 
> aren't talking WS-AT any more.
>  
> InconsistentInternalState could be used in other circumstances, 
> aligned with its definition. It might even appear in the state table - 
> perhaps as action triggered from an internal event (which currently 
> appears as N/A, curiously)
>  
>  
> Peter
>  
>
> ------------------------------------------------------------------------
> *From:* Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
> *Sent:* 06 May 2006 01:42
> *To:* ws-tx@lists.oasis-open.org
> *Subject:* RE: [ws-tx] Issue 041 - WS-AT: Invalid events should not 
> cause defined transitions
>
> As a consumer of a fault, I would rather receive a more specific fault 
> such as InconsistentInternalState, since it offer more specific 
> information and helps distinguish from other possible error states. 
> Specifically, upon receipt of an InconsistentInternalState fault, the 
> consumer may send an alert containing the specific cause, which is 
> otherwise not possible, if it receives a more generic fault.
>
>  
>
> Why should this fault be removed?
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
> *Sent:* Tuesday, March 28, 2006 10:25 AM
> *To:* ws-tx@lists.oasis-open.org
> *Subject:* [ws-tx] Issue 041 - WS-AT: Invalid events should not cause 
> defined transitions
>
>  
>
> This is identified as WS-TX issue 041.
>
>  
>
> Please ensure follow-ups have a subject line starting "Issue 041 - 
> WS-AT: Invalid events should not cause defined transitions".
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Peter Furniss [mailto:peter.furniss@erebor.co.uk]
> *Sent:* Monday, March 27, 2006 1:33 PM
> *To:* ws-tx@lists.oasis-open.org
> *Subject:* [ws-tx] New issue: WS-AT: Invalid events should not cause 
> defined transitions
>
>  
>
> Issue name -- WS-AT: Invalid events should not cause defined transitions
>
>  
>
> 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/17311/wstx-wscoor-1.1-spec-cd-01.pdf
> http://www.oasis-open.org/committees/download.php/17325/wstx-wsat-1.1-spec-cd-01.pdf
>
>  
>
> Section and PDF line number:
>
>  
>
> ws-at section 10, lines 503/505
>  coordinator table: Committed/Active, Committed/Preparing
>  pariticipant table: Commit/Active, Commit/Preparing
> ws-at: seciton 6.1, line 371
>
>  
>
> Issue type:
>
>  
>
> Design/Editorial
>
>  
>
>
> Related issues:
>
>  
>
>
> Issue Description:
>
>  
>
> The receipt of a message when the receiver is in a state such that the 
> event cannot occur between correct implementations should not cause a 
> state transition and allow the transaction to complete "successfully".
>
>  
>
> There is no need to distinguish "InvalidState" and 
> "InconsistentInternalState".
>
>  
>
> Issue Details
>
>  
>
> Background
>
>  
>
> InvalidState is defined in WS-Coordinator as being an unrecoverable 
> condition, and in all the cases  where it is a defined response in the 
> WS-AT tables can only occur if one of the implementations is 
> broken/bugged (apart than the volatile Prepared/None case, see 
> separate issue).  Providing a defined state transition, as if the 
> circumstance were expected and could be recovered from is 
> inappropriate.  There can be no graceful completion of the protocol - 
> it has gone fundamentally wrong. This does not preclude an 
> implementation from attempting to tidy up and protecting its own 
> resources, but there should be no required state transition for the 
> implementation. The protocol exchange has gone off the map.
>
>  
>
> The use of InconsistentInternalState to distinguish two cases where an 
> invalid event occurs is unnecessary (and the definition in line 371 
> does not align with the use in the table - it is probably the 
> coordinator that has been sending wrong messages). 
>
>  
>
> The use of InvalidState is appropriate in all cases.
>
>  
>
> Proposed resolution
>
>  
>
> The clearest solution would be to make invalid cells in the state 
> tables empty, for the cells currently shown as InvalidState or 
> InconsistentInternalState, and also for the N/A cells and explain this 
> with text:
>
>  
>
>  "Where a cell is shown as empty
>   
>   - if the row is for an Inbound Event, an WS-C Invalid State fault 
> should be returned. The subsequent behaviour of the implementation is 
> undefined.
>   
>   - if the row is for an Internal Event, event cannot occur in this 
> state. A TM should view these occurences as serious internal 
> consistency issues."
>
>  
>
> Having invalid cells empty makes it significantly easier to read and 
> check the state tables. It becomes much clearer that they are 
> essentially "sparse" and the path through the table can be followed 
> more easily.
>
>  
>