W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2006

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

From: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
Date: Fri, 27 Jan 2006 14:46:37 +0100
To: noah_mendelsohn@us.ibm.com
Cc: David Orchard <dorchard@bea.com>, Mark Baker <distobj@acm.org>, "Patrick R. McManus" <mcmanus@datapower.com>, Rich Salz <rsalz@datapower.com>, xml-dist-app@w3.org
Message-id: <43DA243D.4010002@crf.canon.fr>

May I dare a summary? So a FAF MEP would not really be FAF at the HTTP 
(and lower) level, but it would nonetheless provide a useful abstraction 
(and fit well to other transports). The MEP user will not (have to) care 
and the MEP implementor will simply have to obey the HTTP semantics and 
discard the HTTP response.

Am I getting anywhere close to reality?

JJ.

PS. Thanks to Noah, David, Mark, Patrick, Rich (and others I probably 
forget [sic]) for an enlightening discussion.

noah_mendelsohn@us.ibm.com wrote:

>David Orchard writes:
>
>  
>
>>More to the point, I don't see why we'd need an request-optional-
>>soap-response mep AND a f-a-f mep where f-a-f is interpreted as you 
>>suggested on the server. 
>>    
>>
>
>..because when we implement SOAP on true FAF transports like UDP, and 
>maybe some flavors of Jabber (I have to go back and look at that) we'll 
>want the true FAF MEP and probably not the Req/Resp (I.e. because 
>Req/Resp, as we keep reminding ourselves, requires the transport to know 
>how to address responses, which in general UDP does not provide.)  FAF is 
>the natural MEP and should be used on one-way transports;  Req/Resp and/or 
>Response-only (which is more properly named 
>Request/ResponseWithEnvelopeInResponseOnly) are the natural MEPs and 
>should be used on Request/Response protocols like HTTP.
>
>--------------------------------------
>Noah Mendelsohn 
>IBM Corporation
>One Rogers Street
>Cambridge, MA 02142
>1-617-693-4036
>--------------------------------------
>
>
>
>
>
>  
>
Received on Friday, 27 January 2006 13:46:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:21 GMT