RE: What does FAF mean?

We're still trying to figure out where to draw the line.  Part of the 
distinction I'm trying to get to is whether there is, even under the 
covers, any network traffic required >between< nodes before the sender of 
the one way is done.   For example, sending a one way through TCP tends to 
imply connection setup, exchange of flow control packets, etc.  That means 
that to send a message in a manner that uses the protocol in the intended 
manner you might literally have to wait for many seconds.  By contrast, a 
system like JMS or MQ will queue a message locally, on disk if necessary. 
The wait times for doing that should be in milliseconds.  UDP is an 
interesting case.  Anish has pointed out that there is some chance that 
buffers would be full locally and you'd be tempted to wait a bit, but a 
counterargument is that UDP semantics are datagram anyway.  If you don't 
like waiting, then just drop the packet.  The network may well do that 
anyway.

So, I can see arguments on both sides, but I want to keep in mind that 
MEPs are like interfaces on bindings.  If two bindings support the same 
MEP, then there should be a good chance that an application should be able 
to use those two bindings interchangeably.  That's why we took the trouble 
of inventing MEPs.  It's a judgement call, but if one set of bindings may 
require you to hang (or spins of a thread that hangs) while exchanging 
messages with some other node, and another set of bindings is FAF in the 
sense that you never have to do more than store the message locally 
(typically milliseconds), then that seems to me a difference that would 
lead applications to consider the bindings as not substitutable in 
practice.  What's confusing, is that the pattern of envelopes is the same 
in both cases, but the transport-level traffic is quite different.  Note 
that in the case of Response-Only, we chose to explicitly model both 
envelope-level and transport-level communication. 

Also, as David Hull points out, there are some differences in the 
responsibilities of the receivers in the two cases.  On transports like 
TCP, the receiver tends to have a responsibility to open a connection in a 
timely way, to suck up the bytes of the message, etc., or else the sender 
can't progress.  With FAF, the tendency is that the sender progresses in 
any case, at least as seen at the application level.  The receiver has 
responsibilities only insofar as it wants to actually get the message in a 
timely or reliable manner.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Vikas Deolaliker" <vikas@sonoasystems.com>
Sent by: xml-dist-app-request@w3.org
03/29/2006 02:21 PM
Please respond to vikas
 
        To:     "'Anish Karmarkar'" <Anish.Karmarkar@oracle.com>, 
"'Xml-Dist-App@W3. Org'" <xml-dist-app@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: What does FAF  mean?




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 21:42:49 UTC