[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2 Retry with Delivery Receipt
Dan, Let's break this into two pieces -- Automation and Retries. Piece One -- Automation: The automation of Retries is actually an implementation detail. The CPA elements are there to do this. I believe the best (only) practical trigger is DR. IM retries are triggered by the lack of an Acknowledgement and I believe so should end-to-end retries. The spec already calls DR an acknowledgement message and I'm fine with that. How this is done is not really important and I am not asking for any changes in the spec in regards to this. Just leave the spec alone. Piece Two (the important part) -- Retries: The important part is the ability to retry. Whether this happens from automated retries or from DFN (I am using this to mean a failure from an IM back to the Sending Party MSH on lack of an Ack) or strictly manual is not really relevant. The important part is that we MUST be able to recover from failure. This does not mean the IM is unreliable. The IM may perform its task perfectly and send the DFN back to the Sending MSH. What then? At some point we must retry -- whether immediately or after a fix. I must *strongly disagree* that this retry is a new message with a new MessageId. This will produce undectable duplicates at the Receiving MSH and thus unusable systems from the customers point of view. Even the idea of waiting for TTL to pass won't really work because TTL does not apply after the message is passed to the application. This is Important. We MUST allow retry of the original message or we have a broken spec in regards to multi-hop (single-hop is fine). The fix for this is RetryCount in Via. Regards, David Fischer Drummond Group. -----Original Message----- From: Dan Weinreb [mailto:dlw@exceloncorp.com] Sent: Thursday, September 13, 2001 11:55 AM To: chris.ferris@sun.com Cc: david@drummondgroup.com; ebxml-msg@lists.oasis-open.org Subject: Re: T2 Retry with Delivery Receipt Date: Thu, 13 Sep 2001 11:48:33 -0400 From: Christopher Ferris <chris.ferris@sun.com> > The only problem is that the addition of multi-hop interferes with end-to-end > retries (duplicates) which, as we have seen, is a fundamental functional > requirement under all circumstances when a Delivery Receipt is requested but not > received. You're asking for retries on top of retries. What happens when the end-to-end retries are exhausted and there is still no delivery receipt? Do we add retries of retries of retries? What happens when they fail? Do we add yet another layer? What David is asking for is perfectly sensible *if* you your failure model states that IM's are unreliable, e.g. that an IM might accept a message, and then silently forget it. In that case, the end-to-end retries exist for a specific purpose: to harden the system against the possibility of flaky IM's. There would be no need to add another layer unless there is some additional, distinct failure mode to be taken care of. Why not focus on what you perceive as an omission in the spec, that an intermediary has certain obligations w/r/t reliable delivery. Let's address that by adding text that fully sets out what the responsibilities of an intermediary are not only w/r/t RM but w/r/t routing and any other oddities of an intermediaries role that is clearly distinct from that of an endpoint. I think David's position is that we can't do that, because there are hosts/entities out there that (a) must participate as ebXML MS IM's, and (b) that are unreliable. The question is whether there's a use case demonstrating this. I'd like to focus on the specific use case that you cited in the call, where an MSH uses an EDI/INT gateway. Is there an ebXML MSH at the To Party or do they simply have an EDI/INT server? MSHA -> IMSHGW -> EDI/INTGW -> EDI/INTB In this case, how does the ebXML delivery receipt get generated? IMO, the EDI/INT Gateway has a responsibility to ensure that the message is safely delivered. How it does this is not the perview of our specification. However, that doesn't obviate the responsibility that the gateway intermediary node assumes. I'd call this a protocol-translating gateway, not an ebXML MS IM at all. I agree that the gateway has to make sure that the message is truly delivered, and then the gateway generates the DR. It's the job of the protcol-translating gateway to create the illusion that the far end is really running ebXML MS. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC