ebBP 3/7/2005: Comment re: Failures and MPC

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

In Tuesday's call, we discussed how failures may be handled. Changes 
have been made in v2.0 and more are anticipated in v3.0.  Comments 
welcome on these changes developed as a result of our discussion.

Business Collaboration and Failures
========================

Section 4.6.6.3
Change from:
Failure to send either signal, when required (by specifying a timeout 
value in timeToAcknowledgeReceipt or timeToAcknowledgeAcceptance), will 
result in the transaction being null and void.

Change to:
Failure to send either signal, when required (by specifying a timeout 
value in timeToAcknowledgeReceipt or timeToAcknowledgeAcceptance), will 
result in the transaction being null and void.  A control failure has 
occurred.
 
Section 4.6.7.1
Change from:
Condition expressions and guards govern the incoming transitions on 
links (FromLink from a parent complexBTA for example). Each of the 
FromLinks can be specified to transition to the CompletionState (Success 
or Failure) as a result of the condition guard value match. Condition 
expressions and variables are described in Section 4.6.8.

Change to:
Condition expressions and guards govern the incoming transitions on 
links (FromLink from a parent complexBTA for example). Each of the 
FromLinks can be specified to transition to the CompletionState (Success 
or Failure) as a result of the condition guard value match. This allows, 
for example, exposing technical
failures. If expected, failures can also be modeled. How it is handled 
is specified by the parties. Condition expressions and variables are 
described in Section 4.6.8.
Expected (choreographed) and unplanned (general exceptions) are 
described further in Section 4.8.2.3.

Section 4.8.2.3, 1
Change from:
The business retry for a RequestingBusinessActivity identifies the 
number of retries allowed in addition to the initial request while the 
time to perform has not been exceeded.

Change to:
The business retry for a RequestingBusinessActivity identifies the 
number of retries allowed in addition to the initial request while the 
time to perform has not been exceeded. The business retry are associated 
with control exceptions such as timeouts.

Section 4.8.2.3, 2 - Add at the end of the section:
More business requirements are being sought to understand needs 
regarding propagation of errors in complex activities such as Business 
Collaboration
involving more than two parties and in a ComplexBTA.