ebBP 2/3/2005: Business Retries and Efficiency Decisions

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Subsequent to a comment received from John Yunker, I propose the 
following additional text to Section 4.8.2.3, as this is an important 
efficiency (wd 06):

FROM:
Generally if a business retry is initiated and a response received, the 
latter can be used. If this occurs, the business partners will be 
responsible for identifying and dealing with duplicate business messages 
(in this case a duplicate request). Duplicate elimination logic SHOULD 
reject the business retry, and possibly resend the business response, 
which would then also be recognized as a duplicate.  The business retry 
for a RequestingBusinessActivity identifies the number of retries 
allowed in addition to the initial request while the time to perform has 
not been exceeded.

TO:
Generally if a business retry is initiated and a response received, the 
latter can be used. If this occurs, the business partners will be 
responsible for identifying and dealing with duplicate business messages 
(in this case a duplicate request). Duplicate elimination logic SHOULD 
reject the business retry, and possibly resend the business response, 
which would then also be recognized as a duplicate. [add] This allows 
the sender to process the original response safely and mitigate the 
overhead to wait for the response to a business retry. This could also 
improve efficiency, lowering the need for backend systems support. 
[end-add]  The business retry for a RequestingBusinessActivity 
identifies the number of retries allowed in addition to the initial 
request while the time to perform has not been exceeded.