- From: Vikas Deolaliker <vikas@sonoasystems.com>
- Date: Wed, 29 Mar 2006 11:21:16 -0800
- To: "'Anish Karmarkar'" <Anish.Karmarkar@oracle.com>, "'Xml-Dist-App@W3. Org'" <xml-dist-app@w3.org>
All, Aren't FAF and MEPs are two distinct mechanisms at different layers in abstraction? MEPs is a mechanism for messaging systems (or processor) while FAF is a programming paradigm. You can achieve FAF over any kind of underlying MEP support by your messaging system. Mixing the two can be cause for confusion, IMHO. Vikas -----Original Message----- From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org] On Behalf Of Anish Karmarkar Sent: Tuesday, March 28, 2006 11:56 PM To: Xml-Dist-App@W3. Org Subject: What does FAF mean? At the Cannes F2F I took an action to start a discussion on what Fire-and-Forget (FAF) MEP means. This email is intended to start that discussion. IIRC, this was in the context of whether we need two different MEPs: one-way MEP and FAF; and whether a FAF MEP has no timing issues (how long does the sender have to wait?) compared with one-way MEP. I don't quite see the need for two separate MEPs. A one-way MEP which consists of one SOAP message going from the sender to the receiver with no requirement (in the MEP) for a transport- or SOAP-level message coming back should be sufficient. I'm not convinced that we should construct MEPs with any builtin timing constraints (and any programming API assumptions). It has been mentioned that there are protocols (such as UDP) where typically the "send" API call returns right away (compared to protocols such as HTTP which require a HTTP-level response -- a network round trip -- and therefore take longer for the "send" API call). Given the various constructs available to programmers: multiple threads, multiple processes, system queues, work queues, shared mem etc, this notion of "timing" as it relates to programming APIs is not very relevant. It would also be difficult to quantify these timing differences. Furthermore, it is not quite true that in protocols like UDP the "send" API call always returns right away. This is typically a system call and requires data to be copied to the buffers (which sometime may take longer than excepted -- depending on what else is going on). I would also like to mention that I think one can indeed bind a FAF MEP (or a one-way MEP for that matter) to a protocol such as HTTP . In this case, at the abstract MEP level there is nothing coming back even though there is a HTTP response coming back. Comments? -Anish --
Received on Wednesday, 29 March 2006 19:21:38 UTC