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

[David Fischer <david@drummondgroup.com>]

Bob,

These changes are required to allow multi-hop retries and end-to-end retries to
co-exist.  End-to-end transmission/retries broke when we added multi-hop and
this is the fix.  We originally tried to fix this by adding end-to-end
acknowledgements called DeliveryReceipt but that was not a full fix.  These
changes are needed in v1.1 to fix this bug.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Friday, September 07, 2001 11:54 AM
To: ebXML Messaging (E-mail)
Subject: T2 Should end-to-end retries be supported in v 1.1 or 2.0?


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>