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

noah_mendelsohn@us.ibm.com wrote:
> Anish Karamarkar writes:
> 
> 
>> For that matter, it is also possible to do R-R over FAF.
> 
> 
> Well, I've tried to make the case several times that this is not entirely 
> true, depending on the reliability and delivery semantics you want.  What 
> I mean is, you don't get req/resp out of merely sending one message in 
> each direction.  The problem is that the Request and the Response are not 
> symmetric, and that r/r usually implies reliability insofar as you are 
> waiting for the response and thus doing low level retries.
> 

I agree that one doesn't get req/resp out of merely sending one 
transport-level message over a transport that is FAF. Perhaps we are 
talking about the same thing here. Not sure.

What I was trying to say was that when we talk about MEP abstractions, 
it is perfectly possible to layer one-way MEP abstraction over 
inherently req-res transports (because the layer that deals with the MEP 
does not see or is aware of the transport level response). Similarly, it 
is also possible to do a R-R MEP over FAF transports such as UDP/SMTP, 
by using additional transport level constructs (or SOAP headers) -- the 
transport binding for the MEP can certainly require 
blocking/retransmission of the transport level messages till a response 
is received.

> HTTP over TCP winds up sending quite a few one way packets at the low 
> level.  Furthermore, Req/Resp usually relies on the underlying transport 
> to keep a session open and to address the response.  UDP, for example, 
> doesn't do this unless you rebuild quite a bit of the equivalent of TCP on 
> top of it.
> 

Agreed.
And if we had a UDP binding for req-response, we would have to build 
stuff on top.

If you are arguing for a "one-way" MEP (which does not require a 
transport level response) regardless of whether we come up with R-O-R 
(not sure if you are) as DavidH is, then I agree. There are lot of cases 
where the underlying transport is a FAF transport and the MEP that is 
required is a 'one-way' MEP without any transport level response. 
Requiring one-way messaging over FAF transport to build mechanisms for a 
transport-level response because all that is available is a R-O-R MEP 
(which requires a transport level response) puts unnecessary burden. I 
tried to make this point during last week's call.

-Anish
--

> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> Anish Karmarkar <Anish.Karmarkar@oracle.com>
> 02/01/2006 02:05 AM
>  
>         To:     Marc Hadley <Marc.Hadley@Sun.COM>
>         cc:     noah_mendelsohn@us.ibm.com, David Orchard 
> <dorchard@bea.com>, Rich Salz <rsalz@datapower.com>, xml-dist-app@w3.org
>         Subject:        Re: The deep difference between request/response 
> and fire-and-forget
> 
> 
> arc Hadley wrote:
> 
>>On Jan 12, 2006, at 8:55 PM, noah_mendelsohn@us.ibm.com wrote:
>>
>>
>>>My preferred approach is:  if we have a true one way MEP, then it's not
>>>supported on HTTP.  Thus there's no tricky choice to be made in 
>>>WSDL.  The
>>>mapping of in-only to HTTP is request/response with no envelope coming
>>>back.  The WSDL-determined code around the binding should in fact 
> 
> ensure
> 
>>>that a 202 rather than a 200 has been received, or else we've got a 
>>>signal
>>>that the server didn't believe it was in-only after all.  My (current)
>>>view is that the one way MEP should be used on protocols like UDP 
>>>that are
>>>inherently fire-n-forget.  It might also be a good match to certain
>>>JMS-like queuing protocols.
>>>
>>
>>I have to confess that this thread has me quite puzzled and I really 
>>don't understand the assertion that you can't support a fire-and- forget 
> 
> 
>>MEP on a request-response based protocol. Even "one-way" APIs  like JMS 
>>can generate error conditions, e.g. javax.jms.Queue.send (Message) can 
>>throw an exception when something goes wrong as can 
>>java.net.DatagramSocket.send(DatagramPacket). It seems to me that 
>>there's little difference to the user between one of these methods 
>>throwing an exception and getting. e.g., a HTTP 4xx or 5xx status  code. 
> 
> 
>>If you want to do fire and forget then just ignore any returned  status 
>>code and/or exceptions.
>>
> 
> 
> I agree. For that matter, it is also possible to do R-R over FAF.
> I seems like I'm in another 'sync apis over inherently async transport 
> vs. async apis over inherently sync transport' discussion. It is clear 
> that one can do either.
> 
> Having said that, I do agree with Noah that we need a true FAF MEP (as 
> opposed to SOAP-req-optional-soap-response MEP) for protocols like UDP.
> 
> -Anish
> --
> 
> 
>>Marc.
>>
>>
>>
>>>>TCP/HTTP support my "entire response is optional" proposal and
>>>
>>>effectively Fire-N-forget.
>>>
>>>I'm not convinced.  Rich and I have agreed that the reason it  doesn't 
>>>work
>>>isn't quite the one I said in my note last night, but I still  believe 
>>>that
>>>HTTP is a request/response protocol, and that it's always good practice
>>>for the receiver of an inbound HTTP request to respond with a  status 
>>>code
>>>(I.e. a response) as opposed to just closing the connection.  Any HTTP
>>>experts want to disagree with me on that?
>>>
>>>Noah
>>>
>>>--------------------------------------
>>>Noah Mendelsohn
>>>IBM Corporation
>>>One Rogers Street
>>>Cambridge, MA 02142
>>>1-617-693-4036
>>>--------------------------------------
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>"David Orchard" <dorchard@bea.com>
>>>01/12/06 07:11 PM
>>>
>>>        To:     <noah_mendelsohn@us.ibm.com>, "Rich Salz"
>>><rsalz@datapower.com>
>>>        cc:     <xml-dist-app@w3.org>
>>>        Subject:        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
>>>>--------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>---
>>Marc Hadley <marc.hadley at sun.com>
>>Business Alliances, CTO Office, Sun Microsystems.
>>
>>
> 
> 
> 
>

Received on Wednesday, 8 February 2006 07:10:08 UTC