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-004
5/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
--------------------------------------