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

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.

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.