Re: T2 Should end-to-end retries be supported in v 1.1 or 2.0?

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

I fundamentally disagree that we need to support end-to-end 
retries over and above adjacent node retries/reliability for 1.1.

If we simply state in the spec what I believe we all understood, that
the deliverySemantics of OnceAndOnly once applies to *all* hops in
a message exchange between parties. Add to this, the change that
Marty has proposed that an MSH SHALL send a DFN to the From Party
in the event that it is unable to safely deliver the message to
the next MSH in the message path (or the application for that matter)
and I think we've covered the bases.

These changes ensure that once a message has
been safely received by an MSH node in the message path, that that
node SHALL assume responsibility for reliably transferring the message
to the next MSH node in the message path or, in the event that
the message is determined by that MSH as unable to be reliably forwarded, 
send a DFN (reliably) to the From Party. 

If the From Party wants a DR, it should simply ask for it as provided
in 1.0.

If we also specify that a DR SHOULD (or SHALL) be reliably delivered
I think that pretty much satisfies reliable delivery. Any failure
that is reported (or failure to receive a DR) needs way more than
a simple (or rather, given the proposal, complex) end-to-end retry
IMO... It is indicative of *serious* problems that probably need
to be resolved external to the systems that no manner of subsequent
retry will solve.

Additionally, this proposal (should the majority deem it prudent
to pursue) needs CAREFUL consideration as to what impact this has on
processing intermediaries. If the intermediaries were merely
and exclusively routing intermediaries, then that might be one
thing. However, I don't believe for a minute that C1 and Ariba
consider themselves as mere routers.

Let's keep it simple. Adding in the complexity of end-to-end
retries is a matter that needs to be carefully weighed against
the stated goals and mantras of the ebXML TR&P project (KISS). 

Cheers,

Chris

"Burdett, David" wrote:
> 
> In a recent email I proposed the following change to support end-to-end
> reliability. Bob Miller thinks this should be a 2.0 change. However you
> could argue that without these changes you do not get true "end-to-end"
> relilability and therefore it is a "bug".
> What do other people think?
> Here are the changes (slightly tweaked) ...
> Change 8
> --------
> Summary: Include automated retry by the original sender (From Party) if no
> Delivery Receipt is returned
> 
> Change 9
> --------
> Summary: Include a "MessageRetryCount" in the NAD (was Via) element in the
> Message Header
> 
> Change 9a
> ---------
> If a To Party receives a message with a retry count that it has not received
> before it resends the message it send in response, e.g. a Delivery Receipt,
> with a new retry count.
> 
> Rationale: There is a need for automated retry by the original sender (From
> party) that sent a message reliably using O&O1 semantics if neither a
> Delivery Receipt nor a Delivery Failure Notification have been received by
> the time they were expected. However, the original sender wants to send the
> **identical** message yet not have it treated as a duplicate by any
> intermediate MSH that has previously received it.
> 
> To solve this problem you can add a "MessageRetryCount" to the NAD which
> indicates to the MSH that even though they have received the message before
> they must still forward it. In this case even if the resend is received
> first and the original appears some time later, the ToParty will be able to
> recognize that the message has already been processed by comparing MessagIds
> only and therefore the original should be ignored.
> 
> However the To Party needs to resend the Delivery Receipt as otherwise the
> original sender will never get the Delivery receipt they are seeking.
> 
> This logic needs to be included in section 10 and will need to include
> another level of RetryCounts/RetryIntervals to work at the end-to-end rather
> than the point-to-point level.
> 
> Product Manager, xCBL, XML Standards
> Solution Strategy, Commerce One
> 4400 Rosewood Drive, Pleasanton, CA 94588, USA
> Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>