Re: How many states on each end?

First, I won't lie down in the road if we don't use state machines. 
However,

    * AFAICT a state machine based description is about the same size as
      the less formal description and, as it uses a well-understood
      formal notation, is more precise.
    * The simple three-state machine turns out to compose nicely into
      more complex models.

In particular, the current request-response model falls out [1], and
IMHO makes much more sense, as a composition of simple three-state
senders and receivers.  Cases we don't currently describe, such as the
"split" case where replies are directed to a third party and faults
directly back in the response (or vice versa),  also fall out by the
same derivation. 

Having a formal description for a one-way message by itself is no big
deal.  Having a uniform description of one-way, request-response and
other variants, including choreographies we haven't yet considered,
seems interesting.  See [1] for a detailed writeup.  (Warning: parts of
this document discuss tunneling scenarios that are arguably abusive of
HTTP.  The discussion of state machines does not depend on these.)

OTOH, the state machine description in question is independent of SOAP
and probably exists elsewhere.  If not, anyone who needs it can define
it and assert that it's equivalent to what we come up with.  But then,
it might be better if we made that assertion.

[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/att-0045/01-part

noah_mendelsohn@us.ibm.com wrote:

>David Hull writes:
>
>  
>
>>The intermediate states only seem useful if external entities want 
>>to query whether anything is in progress, or conversely if the node 
>>wants to notify them on transition, but how finely do we want to 
>>slice this?  We could easily add "envelope built" or "headers 
>>processed" or whatever and argue for each of them.  I could 
>>particularly see an argument for "headers processed" in the context 
>>of WSA and fault handling.  However, I would prefer to keep the MEP 
>>definition minimal and layer finer distinctions on top of it.  We 
>>can always define, say, "receiving" and "headers processed" later 
>>and define them as equivalent to "init" for purposes of determining 
>>overall success and failure.
>>    
>>
>
>The state machines for request/response seem to me at risk of being overly 
>detailed in their attempts to explicitly model streaming.  In the case of 
>one-way, I'm not convinced that we need to talk about state machines at 
>all, or to model any of the intermediate states in which a message is 
>partially sent, streaming, or whatever.  It seems to me that the 
>description of the sender is roughly:  the envelope is made available as 
>outboundMessage and a destination is provided.  Why do we need to say 
>anything more than "The sender attempts to transmit the message to the 
>destination.  The sender MUST include in the message the envelope infoset, 
>and MAY include the destination address or other binding-specific 
>information.    The binding MAY but need not provide error information to 
>the sender in the case that the message is not transmitted successfully. 
>The binding and its impementation at the sender MAY provide for streaming 
>of large messages, such that the first part of the message is transmitted 
>in parallel with the preparation of the remainder."   And, if you believe 
>in talking about the timing, which I understand remains controversial: 
>"This binding is not intended for use in situations where completion of 
>the transmission at the sender will require explicit action or 
>acknowledgement (at any level) from the receiver."
>
>I think that's about what we need at the sender.  At the receiver, I would 
>think:
>
>"This paragraph describes the operation of a receiving node using the one 
>way MEP.  For each received message, the message envelope infoset MUST be 
>made available to the receiver.  Additional binding-specific information, 
>such as the destination address, MAY also be made available.  The binding 
>MAY but need not alert the receiver to situations in which a message was 
>known to have been lost due to network failure, lack of available buffer 
>memory, or other binding-specific error.    The binding and its 
>impementation at the sender MAY provide for streaming of large messages, 
>such that the first part of the message is provided to the receiving 
>application in parallel with the reception from the network of the 
>remainder.
>
>I think that's about all we need in place of what would have been the 
>state machines.    It seems simple, declarative, and sufficient to signal 
>the ability both to stream and to ignore errors if desired.
>
>--------------------------------------
>Noah Mendelsohn 
>IBM Corporation
>One Rogers Street
>Cambridge, MA 02142
>1-617-693-4036
>--------------------------------------
>
>
>
>
>
>  
>