David, Retries are triggered by the retryInterval expiring before the sending MSH receives an Acknowledgment. It performs this loop retries times before giving up and reporting a DFN to the From Party . If the message is acknowledged then the sending MSH ceases to retry delivery. It's job is done. Sure, it (the MSH) doesn't know whether the message has actually been received by the To Party, or even the MSH belonging to the To Party. That isn't its concern because it (the sending MSH) cannot effect/influence the processing of the message between subsequent MSH nodes should some manner of problem arise. It can only influence or effect the message traffic between itself and the adjacent MSH node in the message path. This is NOT to say that the eBusiness Server, of which an MSH may be a component, might not be very concerned with tracking the progress of the message such that its users (humans) might know more about what is the state of the messages which their enterprise has outstanding with its partners. To this eBusiness Server, a DR and/or a DFN may be very important to this layer of the software for purposes of reporting. This layer of software doesn't concern itself with the physical delivery of the messages (including retries, etc.), it delegates that function to the MSH. The MSH doesn't concern itself with DFN's or DR's received, it merely passes these artifacts/messages up to the eBusiness Server layer (or the application as the case may be) for processing. I sincerely hope that you understand the distinction I am, and have consistently been, trying to draw here. The MSH functionality is merely a cog in the greater wheel of things. The RM protocol is hop-to-hop as the TR&P team agreed in face2face meetings long ago in a galaxy far, far (away about a year ago now). We agreed to the black-box approach, meaning that a receiving MSH takes responsibility for the reliable delivery (and persistence, retries and all that goes with it). The sending MSH does not know, nor does it need to know, what means by which an intermediate MSH node might choose to use to effect that reliable delivery as it has transferred the responsibility to the adjacent MSH node. The relay runner example I gave on the con call a couple of weeks ago applies. The runner of the first leg cannot effect the outcome of the race, he can only observe. He cannot re-run the race or even his leg of it. Cheers, Chris David Fischer wrote: >
> Chris, if DeliveryReceipt is not part of RM then how does the original sender
> know when to Retry (the essence of RM)? The current Retry and RetryInterval
> parameters in CPPA are end-to-end *not* next-hop. Are you saying the From Party
> MSH is not allowed to perform Retries? That won't fly. >
> If you ARE allowing the From Party MSH to perform Retries then there must be
> some trigger. I assume this trigger is DR (if not then what?). If the From
> Party MSH is using lack of a DR for triggering Retries then what is the
> distinction from RM? Just because DR is used for RM does not mean it cannot
> ALSO be used for NRR (double duty). >
> Are we talking past each other due to terminology? Perhaps you are saying RM is
> by definition one hop at a time and if we have the exact same functionality over
> the entire path then we need a new term? >
> Regards, >
> David Fischer
> Drummond Group. > >
