ebBP 3/15/2005: Comments re: AnyProtocolFailure Update (wd 10)

["Monica J. Martin" <Monica.Martin@sun.com>]

Based on multiple inputs for this question, I've updated the text regarding general exception and also added a note in the subsequent section (4.8.3). However, through all the discuss, this one question remain unanswered:

====================================================================================================================
Isn't Failure actually an AnyProtocolFailure and Business Failure combined?  This would be consistent with Success which is a Technical and Business Success? Trying to ensure correction of any typos or copy-paste errors (Section 4.8.3).
====================================================================================================================

Please note, I am trying to correct if needed a consistency question between "Success" and "Failure" enumerated business transaction state on the condition guard.  I believe all other questions raised during these interchanges have been answered. Thanks. Comments, as always, welcome.

Updates:
====================================================================================================================
Section 4.8.2.3
[add at the end of this section]

As an unchoreographed event, a general exception MAY result in later actions of the parties that are choreographed. A general exception MAY result in a state transition to a technical failure (AnyProtocolFailure).  Similar to other technical failures such as the Receipt Acceptance Acknowledgement Exceptions, AnyProtocolFailure is designed to allow the protocol to catch and handle behavior when the protocol fails because of technical failure. Note, state transitions and failures are described earlier in Section 4 and in more detail in Section 4.8.3. If a general exception occurs and the party notifies the other with a general exception signal, the parties transition to a known state. Whether further action is required or the technical failure results in any business effect is subject to the agreement of the parties.

Should a general exception not be defined between the parties, i.e. there is no mechanism defined to handle such events, the parties MAY use alternate means or act in line with any agreements between them. 

Under choreographed circumstances, if a party is unable to respond with a choreographed receipt acknowledgement within the time specified, that party SHOULD exit and, if agreed by the parties, the requesting party MAY issue an NOF or a business retry. For the unchoreographed general exception, the parties MAY also agree to subsequent actions that are choreographed. Whether the unchoreographed general exception follows the same path as the known circumstances outlined is unspecified. 

Should a NOF business message be specified by the parties but not sent after an exception, another protocol failure (choreography violation) SHOULD occur. More business requirements are sought to understand, if and when an NOF should be issued, another business transaction may occur after the return to initial state, or subsequent choreographed actions are required.

Section 4.8.3
[add after the bulleted list of enumeration list of transitions]

Each of the defined business transaction states of a condition guard that relate to failures in essence has a handler (or interface).  For example, AnyProtocolFailure defines transition to that handler associated with a techical failure.