Proposal concerning Martin's issues involving business level retry.

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Martin explained his company's decision not to implement business level
retry by saying:

1. The specification was not sufficiently clear about retry to be
unambigusously implemented.
Some readers, for example, interpreted retry count to be the number of
times to retry
after the original send, while others interpreted the count to include
the original. In addition,
it was not clear whether to reset all the timers (TTP, TTA, TTR) , or
just the TTR timer.
Minimally these editorial problems need fixing.

2. Retry needed clarity about how "clean up" or "checkpointing" might
occur to permit retry
to work in a complex choreography (or else it is retry the entire
collaboration.) No variable granularity
of retry was supported, so it was less than useful for Martin's
purposes.

In addition, reliable messaging largely eliminates the rationale for a
business level retry from a standpoint of technical failure. For
business failure, our choreography does permit looping now and perhaps
that is a better and more general way to allow retry, and also control
its effects. Can variables now be made able to handle these counters?

The UMM did have some provision for retry (a legacy of RN heritage
possibly), but BPSS now treats
UMM versions as a repository of potentially useful ideas rather than as
something to align with.
Therefore, we are free to omit an aspect of UMM that confused lower
level RM concerns with business semantics, and instead allow the
choreography to capture business logic using looping when appropriate
for business purposes.

If retry were omitted, then the RNIF 2.0 two-action activity diagram
loses one route to NOF (when max retries reached. We still would need to
address the use of NOF by the Requestor when the Requestor finds itself
unable to process the business Response (and after its Receipt has been
sent). Possibly the Responder could find NOF useful after it has sent
Acceptance Ack but has a technical failure in creating or sending the
Response (Response has been written to disk for sending but then that
disk crashes in unrecoverable way etc.) 

At any rate the use of NOF might be useful in addressing some of
Martin's backend-frontend based misalignments, if those misalignments
can be detected and all parties can be informed of NOF (even the
responder's back end will need to get a NOF sent because it thinks it
sent successfully...)

Residual issues: cleanup/checkpoint, optional paths for entry or
continuation, receipt and response in same message--out of sequence when
processing.

Residual question: why is NOF being said to be a business document
rather than a signal.