[ebbp] 11/30/2004: NOF Summary (as requested 23 Nov)

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

Last week, JJ Dubray asked some questions regarding NOF. We've had many 
extended discussions about NOF previously, although there has been some 
confusion about the applicable patterns, the scope and any boundaries 
ebBP might recommend (or impose).Here is a summary (that at least to me 
is relatively clear). JJ, if you have comments or questions, please 
post. Thank you.

NOF is a choreographed behavior for which you can plan.

    * Can occur after the other business transaction has taken place.
    * NOF is separate from business transaction that initiates/initiated
      the agreement between the parties. Can be used when you have
      conditional acceptance or when you can't tell the contract has
      been formed (i.e. no response received at timeout on time to perform.
    * Party doesn't have control.  
    * Party chooses not to business retry (and you can retry). [1]
    * Conditions preclude you meeting your obligation.  When an offer is
      made and needs to be rescinded as the transaction failed.
    * Defined as a BT pattern already (Notification). It is a message
      not a signal.  The Notification pattern (Chapter 8, UMM, R10)
      talks about the  notification of failed business control and its
      use to supplement other patterns such as Commercial Transaction.
      Therefore we already have the NOF pattern defined, not the
      semantics detailed. [2]
    * At this time, it trading partner specific on how it is used (if at
      all) and handled.
    * NOF doesn't rely on endsWhen.
    * The NOF MAY be used after a timeout occurs (on RA, AA or TTP).

Note: The general exception handles unchoreographed / unplanned events. 
The general exception has not been added to any of the predefined 
business transaction patterns.

[1] NOF MAY occur if a timeout occurs and no/no more retries are 
available (and TTP has not expired). If retries still exist and a 
timeout has occurred, the offeror can choose to retry or NOF.
[2] Actually, the examples in the UMM R10, Chapter 8 and 9, talk about 
general exception (business control failure) by the responder and NOF 
(stop transaction) by requester being actually used in tandem.  
Responder exits a transaction, and uses a business control failure. This 
equates to a Negative RA or AA, or general exception. The requester in 
turn, issues the NOF. The Notification pattern is a formal exchange and 
requires non-repudiation. The responder is responsible to send back an 
RA on the NOF. NOF business document requires a Receipt Acknowledgement. 
A separate communication channel is recommended.

Here was the previous decision: We recognize several criteria and 
business requirements feed into providing a well-defined NOF capability 
and its impact on retries. It has been recommended we separate a logical 
path forward between v2.0 and a subsequent v3.0.  For v2.0, we have 
discussed:

   1. Leveraging the definition of an NOF via the defined BT patterns.
      See Notification pattern (UMM R10, Chapter 8-9).
   2. Retain the business retry count for backward compatibility and
      understanding (although technically it is redundant).
   3. Allow use of a variable to allow specification of the retry count
      (action David Webber with team review). [3]
   4. An NOF may be precluded under some circumstances where an AA is
      required.

*Open*:  If a retry occurs and the response occurs (cross one another), 
how do we achieve a consistent state? This should be defined by the 
parties or we can make a recommendation.

For v3.0:

    * Determine if a simple notification request to a partner be
      sufficient to at times, circumvent an unnecessary NOF. Gather more
      business requirements.
    * Gather more requirements or insight on concepts such as revocation
      of offer (incomplete in R10). Other efforts like UBAC may provide
      guidance in the future.

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

Here are some summaries that explain some of the UMM guidelines, inputs 
from various communities, and historical discussions about how to manage 
the use of NOF. Some revised over time as more information was available 
and understood.
a. Summary 10/4/2004 (Martin): 
http://www.oasis-open.org/archives/ebxml-bp/200410/msg00002.html
10/15/2004 (Martin): 
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200410/msg00086.html 

b. Meeting notes, see Kavi Documents under Meeting Notes for 9/27/2004 
and 10/4/2004:
  9/27: http://www.oasis-open.org/archives/ebxml-bp/200410/msg00000.html
  10/4: http://www.oasis-open.org/archives/ebxml-bp/200410/msg00006.html
  10/11: http://www.oasis-open.org/archives/ebxml-bp/200410/msg00061.html
c. Working session on general exceptions and NOF 9/10/2004:
  Agenda and details: 
http://lists.oasis-open.org/archives/ebxml-bp/200409/msg00065.html
  Session notes: 
http://lists.oasis-open.org/archives/ebxml-bp/200409/msg00057.html
  Distinctions between NOF and exceptions: 
http://www.oasis-open.org/archives/ebxml-bp/200410/msg00011.html
d. Open archives for September and October are found at: 
http://lists.oasis-open.org/archives/ebxml-bp/.
e. General exception parameters: 
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200410/msg00087.html