RE: [ebxml-bp] ebBP 3/15/2005: Comments re: AnyProtocolFailure Update (wd 10)

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

Wouldn't we say that success has to be success on all fronts (so it is
"conjunction" of all success flavors) but that a general failure would
be a disjunction of the specific forms of failure (that is, Failure is
either ProtocolFailure and/or BusinessFailure and/or ...). Anyway that
seems plausible to me.



-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@sun.com] 
Sent: Tuesday, March 15, 2005 6:31 AM
To: Steve Capell; ebXML BP; Himagiri.Mukkamala@sybase.com
Subject: [ebxml-bp] ebBP 3/15/2005: Comments re: AnyProtocolFailure
Update (wd 10)

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.