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

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.

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.

--------------------------------------
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 Friday, 3 February 2006 14:29:11 UTC