RE: The deep difference between request/response and fire-and-forget

I feel yet another "leaky abstraction" emerging.

IIUC, TCP/HTTP support my "entire response is optional" proposal and
effectively Fire-N-forget.  I'm really against generalizing away from
this awfully common case.

Let's do the thought experiment.  If we have an MEP for
request-optionalresponseenvelope and an MEP for fire-N-forget, then
somebody will have to say which one they want for a wsdl one-way.  In
the case of HTTP, they will have to choose between them.  I guess that
request-optionalresponseenvelope is the default for in-only in wsdl 1.1
and wsdl 2.0.  I would also expect that the HTTP Binding for the MEPs
will be very similar.  They will both put the request property on the
wire and then the FAF mep would be implemented by transitioning from
sending state to the Success state, whereas the r-ore mep would
transition to the sending+receiving state.  

This difference, the specification that the client will or will not wait
for a response is the major difference between the two meps.  And the
reason to have them is so that the sending node can "know" that it
doesn't have to wait.

Is that right?

If that's roughly right, I'll then observe that the choice of the SOAP
MEP is dependent upon the binding.  For a wsdl in-only, the binding
might only support faf.  In the case of HTTP that supports both MEPs,
the designer will be deeply aware of the connection mgmt issues - just
as we are talking about it.  So now we have the knowledge of the binding
affecting which soap mep is used to implement the wsdl in-only.  A leaky
abstraction imo.

Further, let's look at the 2 scenarios where the sender and receiver
"disagree" about which MEP is in use.  In both cases, the receiver does
not intend to respond with an envelope.  

Scenario #1: Sender thinks faf, receiver thinks r-ore.  Sender closes
connection after send.  All good.  Receiver gets message then socket is
closed before it can respond.  It might get confused about whether to
move into the Success or Fail state, but seems that the Success state
for a one-way is the logical place to go.  

Scenario #2: Sender thinks r-ore, receiver thinks faf.  Sender waits for
response.  Receiver closes connection after receiving request and moves
into the success state.  Sender notices that connection has closed.
Sender has choice of moving into the Success or Fail state, but it seems
that the Success state for one-way is the logical place to go.

If you believe that that the Success state is the right place for a
sender and a receiver to goto after a connection close for a one-way,
then there's no need to differentiate between faf and r-ore.  

After this little bit of analysis, it seems that the only reason to have
the 2 different MEPs is specify what a connection close after send
means, specifically what the next state is.  For faf, connection close
after send means Success.  For r-ore that is different than faf,
connection close after send would mean Fail.  

However, I think that we can hit the 80/20 by providing a r-ore mep and
specifying that connection close after send results in Success.

Cheers,
Dave

> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]
On
> Behalf Of noah_mendelsohn@us.ibm.com
> Sent: Thursday, January 12, 2006 3:12 PM
> To: Rich Salz
> Cc: xml-dist-app@w3.org
> Subject: Re: The deep difference between request/response and
fire-and-
> forget
> 
> 
> Rich Salz writes:
> 
> > > A subtle problem occurs if you try to implement true FAF on a
req/resp
> > > protocol like HTTP.  Repeating the sender code from above:
> > >
> > >         s = socket.new(destinationURI);
> > >         s.send(Message);
> > >         // note that client does not wait here
> > >         s.close();
> > >
> > > Depending on the local implementation, I don't think the
> > above obligates
> > > the messaging system to even send the message.
> >
> > I think it does.  It depends on semantics of the API, but I am not
> > aware of any "socket" library that allows a close() to bypass the
> > normal TCP close mechanism, which requires that all bytes in-transit
> > have been received.  Not providing this guarantee (proper TCP
> > connection shutdown) would mean that every TCP-application would
> > have to build its own exit protocol on top of the TCP streams.
> 
> Thanks, I think you're right in the specific case of TCP and HTTP.  I
> actually realized it this morning and then saw your note.  In some
sense,
> this traces to the fact that the TCP streams are reliable and happen
to
> each have a sort of Fire-N-Forget semantic, not just at the API level,
but
> also at the packet level.  The packets that close the connection are,
I
> believe, ordered with respect to those that send the final data.  Even
if
> they are delivered in the wrong order, I expect that the data is in
> general reliably transmitted, unless the network partitions or retries
> fail.
> 
> Having acknowledged that, I should note that the above pseudo-code was
not
> intended to be HTTP/TCP specific, but rather a model for the API that
you
> typically use with Req/Resp.  As you say, what actually happens
depends on
> the semantics of the API (and, I think, the protocol it's driving).  I
> believe that a Req/Resp MEP is best designed to work with a broad
range of
> underlying protocols, and I think it's easy to imagine the design of a
> lightweight req/resp transport that responds to a close by immediately
> suspending further attempts to deliver.
> 
> Bottom line:  I acknowledge that I was wrong about TCP, but I continue
to
> suggest that it would be imprudent to make the entire response
optional in
> you req/resp MEP.  I remain OK with our current plan to make the
response
> envelope optional.  Do I have the facts right now?  I think so.
Thanks.
> 
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
>

Received on Friday, 13 January 2006 00:12:20 UTC