RE: How many states on each end?

Sorry for the belated reply.  I'm going through back email.  Just to be 
clear, my main point was that I'm unconvinced that trying to explicitly 
model the asynchrony of streaming in separate states is a win.  If we have 
state machines, I'm tempted to have them just describe the simple 
non-streaming case, with sender and receiver machines separate in the case 
where we're describing R/R or something similar.  We can then say in 
prose:  note that either the outbound or inbound logic can stream, so the 
receiver of a message may begin processing while the sender is still 
sending.  Similarly (for R/R and R/OR), a responder may begin to send its 
response while still reading and processing the tail of its input.  Note, 
however, that certain SOAP faults cannot be reliably detected until some 
or all of the input message is received.  I think we need to keep the 
existing warnings that to avoid deadlock, particularly in such streaming 
scenarios, receivers must make forward progress in consuming inbound 
messages, and in particular when streaming a requestor cannot in all cases 
defer receipt of a response until all of a (potentially long) request is 
sent.  I believe that last subtlety is correctly covered in the Req.

Anyway, to summarize my main points:

* Probably:  get the streaming logic out of the state machines, thus 
greatly simplifying them
* Maybe: for some or all of the new MEPs, drop the state machines.

More for reasons of minimizing change to stable Recs than because I love 
the existing state machines, I would not substantially change the state 
machines for R/R or Resp-only in conjunction with adding 202 support.  I 
can almost certainly live without a formal state machine for one-way, if 
that's the group's preference.  Thanks.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"David Orchard" <dorchard@bea.com>
04/05/2006 04:25 AM
 
        To:     "David Hull" <dmh@tibco.com>, <noah_mendelsohn@us.ibm.com>
        cc:     <xml-dist-app@w3.org>
        Subject:        RE: How many states on each end?


I disagree that "a state machine is about the same size as a less formal 
description" is a useful assertion to make.  The thing to look at is "what 
is relevant".  What needs to be expressed that a state machine would 
satisfy.  It turns outs, much of what is expressed is not needed, either 
by senders or receivers. 
 
I tend to agree that a uniform description of one-way, request-response 
and other variants would be nice.  That's why I wanted the state machines 
removed from request-response.  However, I'd rather do the one-way MEP in 
a simpler way and sacrifice "consistency".  Especially as I don't think 
that MEP framework as it stands has done much to foster MEP development, 
considering that we are formally working on a one-way MEP in 2006 and SOAP 
1.2 binding framework was formally standardized 3 years earlier in 2003. 
 
Cheers,
Dave
 

From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org] On 
Behalf Of David Hull
Sent: Tuesday, April 04, 2006 2:16 PM
To: noah_mendelsohn@us.ibm.com
Cc: xml-dist-app@w3.org
Subject: 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
--------------------------------------

Received on Sunday, 16 April 2006 17:20:43 UTC