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

RE: What does FAF mean?

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>
Message-ID: <029c01c65365$f3ba1a20$800101df@deolali>


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 GMT

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