Point well taken. I agree, this use case would be where the IM is not really an
IM but instead is an end (this sounds like Workflow Routing -- what did you call
it last Spring, "deterministic routing" or something like that) but you are
right, we need to allow for this.
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: [mailto:]On Behalf Of
christopher ferris
Sent: Friday, August 17, 2001 4:45 PM
To:
Subject: Re: T2, Proposed solution for ... Re: SyncReply
andReliableMessagingMethod in QualityOfServiceInfo
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:]
> Sent: Friday, August 17, 2001 9:32 AM
> To:
> Cc:
> Subject: Re: T2, Proposed solution for ... Re: SyncReply and
> ReliableMessagingMethod in QualityOfServiceInfo
>
> Date: Fri, 17 Aug 2001 09:04:29 -0500
> From: David Fischer <>
>
> 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>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
