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 07:56:03 UTC