Re: T2, Proposed solution for ... Re: SyncReplyandReliableMessagingMethod in QualityOfServiceInfo

[christopher ferris <chris.ferris@east.sun.com>]

If I have a processing intermediary, duplicate eleimination
may be critical to its operation.

Consider the use case where an intermediary is a marketplace
that has matched a buyer and seller, that takes a "cut"
as it were of the transactions between the buyer and seller.
Basically, the marketplace wants to know when the parties
transact the business 
It would be a bad thing if it counted each retry as a distinct
transaction. It must therefore apply idempotency check on the
messages it processes and then forwards to the next hop in the
message path.

I will add that I feel that in this case, the intermediary is
actually a part of the overall process, while not technically
a part of the buy/sell BP that the two end-node parties share
in common. However, I have heard repeatedly from the likes
of DavidB and DougB that they don't consider themselves as
part of the process.

I think that we need to be *really* careful about treating 
intermediaries as mere pass-through nodes that have no
part in, nor any stake in the reliable messaging aspect.

Cheers,

Chris

David Fischer wrote:
> 
> This sounds interesting but I don't quite understand.  How can we allow
> intermediates to do duplicate elimination yet also allow the ends to retry?
> Wouldn't this mean the retry would get stopped midstream since some Intermediate
> might think it is a duplicate?  The Intermediate needs to let the From Party
> retry to go through even if it is a duplicate because the problem might be
> downstream of that Intermediate.
> 
> Please explain further,
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: Dan Weinreb [mailto:dlw@exceloncorp.com]
> Sent: Friday, August 17, 2001 9:32 AM
> To: david@drummondgroup.com
> Cc: ebxml-msg@lists.oasis-open.org
> Subject: Re: T2, Proposed solution for ... Re: SyncReply and
> ReliableMessagingMethod in QualityOfServiceInfo
> 
>    Date: Fri, 17 Aug 2001 09:04:29 -0500
>    From: David Fischer <david@drummondgroup.com>
> 
>    Intermediate duplicate detection precludes retries by the From Party MSH.
> 
> If we deal with the whole issue of intermediaries by using a layered
> approach, we would not have this problem.
> 
> Consider the analogy with the Internet protocol stack.  TCP (at layer
> 4) is defined to be once-and-only-once.  It's built on IP, which is
> built on link-level (layer 2) protocols.
> 
> The link-level protocols do not promise (in their contract to the
> higher layers) any kind of retransmission of data, but some of them do
> retransmission anyway (going beyond what they promised to do), because
> they are in a good position to retransmit efficiently and the net
> effect is to reduce the amount of retransmission that the higher
> layers have to do, thus increasing net performance.
> 
> Analogously, In the layering of ebXML MS that I and others have been
> suggesting, we should have end-to-end reliable messaging, with the
> IM's not *promising* to be reliable; an IM could drop a message or
> duplicate a message, without breaking its contract.  An IM might do
> duplicate elimination anyway (going beyond what it promised to do) for
> the sake of improving overall performance, but that would be entirely
> invisible to the higher-layer ebXML MS protocol.  And so, intermediate
> duplication detection would *not* preclude retries by the From Party MSH.
> 
> -- Dan
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>