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

arc Hadley wrote:
> On Jan 12, 2006, at 8:55 PM, [email protected] 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" <[email protected]>
>> 01/12/06 07:11 PM
>>
>>         To:     <[email protected]>, "Rich Salz"
>> <[email protected]>
>>         cc:     <[email protected]>
>>         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: [email protected] [mailto:xml-dist-app- [email protected]]
>>
>> On
>>
>>> Behalf Of [email protected]
>>> Sent: Thursday, January 12, 2006 3:12 PM
>>> To: Rich Salz
>>> Cc: [email protected]
>>> 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.
> 
>