Re: [ebxml-bp] Re: ebBP 2/22/2005: Any Protocol Failure Question:section 4.6.8.1 and 4.8.3

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

>Yunker: Let's look at the business case.
>
>AnyProtocolFailure is designed to allow the protocol to catch and orchestrate behavior when the protocol fails.
>
>Any protocol failure includes general exception.  Any un-orchestrated general exception should result in NOF (or other agreed setting aside of the transaction)
>  
>
mm1: Thanks John, I'll take these comments for revisions in the General 
Exception text proposed. I have a question for Dale and Hima though. 
Hima, any concerns?
Dale, do we need to make any changes to the schema in line with 
associating AnyProtocolFailure with GeneralExceptionType? Updated text 
is provided at the end of this email.  I have one final question, 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). Thanks.

>>mm1: 2/22/2005: Today, we discussed this question briefly. How do we
>>separate or compare the AnyProtocolFailure to general exception. There 
>>are actually > 1 questions here. So I will attempt to articulate:
>>
>>   * Any protocol failure is one of the enumeration values of the
>>     ConditionGuardValue list that can apply to a substate (status)
>>     visibility or to condition guard. See Sections 4.6.8.1 and 4.8.3,
>>     that specify guards on transitions.
>>   * General exception is defined but is not part of the BT patterns
>>     defined (as it is unplanned). See Section 4.8.2.3.
>>
>>Therefore, is general exception an 'AnyProtocolFailure' other than the
>>other types specified? I ask this question because the use of the 
>>general exception is not articulated as a guard. ....
>>
>>So we have to answer:
>>
>>   * How do GeneralException and AnyProtocolFailure relate if at all?
>>     One is in the defined transition guards (the latter) and the other
>>     is completely unplanned. ......
>>
mm1: See John Yunker's comment above.

>>   * After answering above question, what schema changes may be
>>     required. Tech spec language will follow.
>>
Updated
======

Section 4.8.2.3
[add at the end of this section]

As an unplanned 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).  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.

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. 
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.