ebBP 3/20/2005: Comment re: State Transitions (was AnyProtocolFailure)wd10/Schema of 2/22

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

Everyone, in Tuesday's call 15 March 2005, we discussed adding more 
descriptive text surrounding the condition guards and state transitions 
for our user community (for technical specification and schema).  Once 
we are comfortable with the updated text, these can be used for schema 
annotation changes. Here are:

    * Technical specification update (as of 20 March 2005)

====================================================================================================================

Section 4.7.1
[add at the end of this section]

The condition guards on state transitions are described in further detail in Section 4.

Section 4.8.2.3
[add at the end of this section]

A general exception is a limited case and distinct type of technical failure, i.e. AnyProtocol Failure).
The involved parties determine if such exceptions are used in order to recognize and handle the possibility of a catastrophic
failure.

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
The values of the enumeration of the state of a business transaction of a condition guard on a transition are:

> For Success
 * Success (Both protocol and business success)
 * ProtocolSuccess: Technical success
 * BusinessSuccess (isPositiveResponse=true or no isPositiveResponse attribute): Specific document(s) received.

> For Failure
 * Failure (AnyProtocolFailure or BusinessFailure): Specific document(s) received.
 * BusinessFailure (isPositiveResponse=false)
 * AnyProtocolFailure: Technical failure other than those specified.
   Note: As previously indicated, General Exception is a distinct case of the technical failure, AnyProtocolFailure.
 * ResponseTimeout: Time to perform exceeded.
 * SignalTimeout: Time to receipt or time to acceptance acknowledge exceeded.
 * RequestReceiptFailure: Technical failure of Receipt Acknowledgement on Request.
 * RequestAcceptanceFailure: Technical failure of Acceptance Acknowledgement on Request. 
 * ResponseReceiptFailure: Technical failure of Receipt Acknowledgement on Response.
 * RequestAcceptanceFailure: Technical failure of Acceptance Acknowledgement on Response.

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.

Two tree diagrams are provided to assist in understanding and using these state transitions, one showing a successful path and 
the other specifies failure.

***tree diagrams [tbd-in work]***

In real-world scenarios, it is anticipated that more than one condition guard MAY occur and the parties involved MAY choose
to monitor them.  Monitoring can continue even if an initial failure or timeout has occured. The affected parties are notified
as soon as possible.

Transitions exist with guards. When more than one condition guard is defined (by the parties), they could
be mutually exclusive or all used.  If not defined, the assumption is all MAY happen. For example, SignalTimeout will occur before 
ResponseTimeout. 

=============================================================================
* Other comments from Dale: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200503/msg00062.html  
* TC meeting minutes 15 March 2005: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200503/msg00064.html  

> Open pending items:
* Webber and Moberg: Two tree diagrams and any additional text desired for success and failure above. See Figure 11 in wd10. These
two diagrams will be in addition to this graphic. See wd 10 under Calendar Documents in Kavi (23 Feb).