OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [ebBP] 10/15/2004: Final Recommendations Update on NOF and Exceptions


NOF summary accounts for: community input, use of Acceptance 
Acknowledgement, gaps that may exist in community strategies [1].  NOF 
typically occurs when [2]:

   * Use after timeout occurs (on RA, AA or TTP)
   * Use 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).
   * Occurs when you are not under control (differentiates from general 
exception).
   * NOF doesn't rely on endsWhen.
   * When an offer is made and needs to be rescinded as the transaction 
failed.
   * 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.

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:

   * Leveraging the definition of an NOF via the defined BT patterns. 
See Notification pattern (UMM R10, Chapter 8-9).
   * Retain the business retry count for backward compatibility and 
understanding (although technically it is redundant).
   * Allow use of a variable to allow specification of the retry count 
(action David Webber with team review). [3]

A few v2.0-scoped open questions exist (updated):

    * Could NOF be precluded under some circumstances where an AA is 
required (most often the case)? Answer: Yes.
    * If an NOF is a separate BT pattern in the future, preconditions 
may be required for its use. This may dictate significant constraint on 
the collaboration and the
      implementation. Are the tradeoffs understood and acceptable? 
Answer: Yes, partners agree to its usage.
    * If a retry occurs and the response occurs (cross one another), how 
do we achieve a consistent state? Answer: Still open.

For v3.0:
    * Would a simple notification request to a partner be sufficient to 
at times, circumvent an unnecessary NOF? (Tell calls this a gentle 
reminder). Answer: Consider in v3.0
     in order to 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.

Note that we have learned quite a bit through this process and there is 
more to go in a later version. We have taken some details, done further 
analysis and revised our thinking as even the historical details are 
incomplete, confusing or conflicting.  All-in-all everyone has done a 
great job. I've separated from Exceptions (separate email to be sent). 
Thanks to everyone. Continue please to send details as they will be 
important to v2.0 and for later versions.

[1] Such as RosettaNet not using AA. We've received feedback that the 
RosettaNet definitions need revision and interpretation in 
implementations differ. Therefore, we will continue to work 
collaboratively with that community. Inputs also received from financial 
services, telecomm, and retail.
[2] Consistent with inputs from JB Clark, Yunker, and UMM R10 Chapters 8-9.
[3] Action to David Webber still open

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]