How many states on each end?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

How many states on each end?

David Hull
Technically, one consequence of the differing view of whether the exchange completed successfully is that the receiver may remain in the "init" state regardless of which state the sender goes to.  E.g.,
  • I send a UDP packet, the receiver's gateway is down.  I transition to success, the receiver hears nothing and stays in init.
  • I try to send a UDP packet, but my gateway is down.  I get a no route to destination error and go to failure.  Naturally, the receiver hears nothing.
There may be a subtlety here.  The sender knows when it's going to try to send a message.  We could model this by making "init" an "idle" state and transitioning to "sending" when actually trying to send a message.  The receiver, on the other hand, doesn't know anything's happening until it actually starts to happen, so its "init" state is more like "listening".  Once a message starts coming in, it either comes in or it fails to, but we could insert "receiving" analogously to model the receiver becoming aware that something is coming in.

Whatever subtlety there is here is also present in the request-response MEP, and the request-response MEP does indeed include intermediate states; Init is different from sending on the request side and receiving on the response side.  This distinguishes "I'm idle" from "I'm sending a request" and "I'm waiting for a request" from "a request is now coming in."  It's a bit confusing that the Init -> Sending condition is given as "unconditional" as opposed to "Start sending request message," but the distinction is still there.

The question is, who wants to know this distinction?  From the point of view of determining whether the MEP succeeded, or whether anything happened at all, three states on each end are enough.  In practice, there will always be some sort of timeout ensuring that one does not stay in the "sending" or "receiving" state indefinitely, and regardless, we don't want to make a pronouncement while still in those states.  In other words, if I get to "receiving" I will always go to either "success" or "failure" and if I don't, I simply stay in "init" as described above.

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.

Normally I'd tend toward the "request-response is that way for a reason" school of thought, but while that's almost certainly true, I've seen (and done) enough pushback against the request-response state machines to want to re-examine them.
Reply | Threaded
Open this post in threaded view
|

Re: How many states on each end?

noah_mendelsohn

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





Reply | Threaded
Open this post in threaded view
|

Re: How many states on each end?

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

[hidden email] 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
--------------------------------------





  

Reply | Threaded
Open this post in threaded view
|

RE: How many states on each end?

David Orchard
In reply to this post by David Hull

+1 to Noah.  If we can get rid of much if not all of the state machines,
excellent.  You can see in the new one-way MEP and with my old proposals
for request-response how much easier the MEPs are with simplified state
machines.

I produced a version of the one-way that kept the state machine ONLY to
continue the state machines from the request-response MEP as that seemed
the right thing to do editorially, and shouldn't be interpreted as a
pro-keeping the stance from me.

Cheers,
Dave

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
On

> Behalf Of [hidden email]
> Sent: Tuesday, April 04, 2006 1:51 PM
> To: David Hull
> Cc: [hidden email]
> Subject: 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
> --------------------------------------
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

RE: How many states on each end?

David Orchard
In reply to this post by David Hull

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: [hidden email] [mailto:[hidden email]] On Behalf Of David Hull
Sent: Tuesday, April 04, 2006 2:16 PM
To: [hidden email]
Cc: [hidden email]
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

[hidden email] 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
--------------------------------------
 
 
 
 
 
  

 

Reply | Threaded
Open this post in threaded view
|

RE: How many states on each end?

noah_mendelsohn

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" <[hidden email]>
04/05/2006 04:25 AM
 
        To:     "David Hull" <[hidden email]>, <[hidden email]>
        cc:     <[hidden email]>
        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: [hidden email] [mailto:[hidden email]] On
Behalf Of David Hull
Sent: Tuesday, April 04, 2006 2:16 PM
To: [hidden email]
Cc: [hidden email]
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


[hidden email] 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
--------------------------------------