W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2006

RE: How many states on each end?

From: David Orchard <dorchard@bea.com>
Date: Wed, 5 Apr 2006 01:25:57 -0700
Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C0158EA7F@repbex01.amer.bea.com>
To: "David Hull" <dmh@tibco.com>, <noah_mendelsohn@us.ibm.com>
Cc: <xml-dist-app@w3.org>
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.  






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.

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


noah_mendelsohn@us.ibm.com wrote: 

David Hull writes:

	The intermediate states only seem useful if external entities
	to query whether anything is in progress, or conversely if the
	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
	of WSA and fault handling.  However, I would prefer to keep the
	definition minimal and layer finer distinctions on top of it.
	can always define, say, "receiving" and "headers processed"
	and define them as equivalent to "init" for purposes of
	overall success and failure.

The state machines for request/response seem to me at risk of being
detailed in their attempts to explicitly model streaming.  In the case
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
and MAY include the destination address or other binding-specific 
information.    The binding MAY but need not provide error information
the sender in the case that the message is not transmitted successfully.

The binding and its impementation at the sender MAY provide for
of large messages, such that the first part of the message is
in parallel with the preparation of the remainder."   And, if you
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
"This paragraph describes the operation of a receiving node using the
way MEP.  For each received message, the message envelope infoset MUST
made available to the receiver.  Additional binding-specific
such as the destination address, MAY also be made available.  The
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 
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
the ability both to stream and to ignore errors if desired.
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

Received on Wednesday, 5 April 2006 08:27:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:29 UTC