Re: How many states on each end?

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
--------------------------------------

Received on Tuesday, 4 April 2006 20:50:46 UTC