[ebBP] 3/28/2004: WI-26-36-52 Control Flow - Notification of Failure[RSD]

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

  Discussion|OASIS.ebBP.WI-26 Control flow and NOF;
Topic;
Point|Combination with WI 36 and 52;

mm1@
This email is two-fold: (1) to further the discussion on Work Items 
26-36 and 52 (all related) and (2) understand how or if to accommodate 
NOF (notification of failure) for v2.0.

Work Item 26: What interactions are handled out of band - address 
notification of failure specifically at a minimum.
Work Item 36: Clarify (if any) differences between NOF and 
AcceptAcknowledgement. Address if so in the specification. Do we need to 
be able to generate NOF
Work Item 52: How will NOF affect TTP?

May also relate to WI 2 (CPPA Negotiation).

Key points:

    * Understand what happens if a NOF occurs. Do we replay
      collaboration or the transaction, and understand which one is failed.
    * Define what state is returned in BPSS when an NOF occurs.
    * Differentiate NOF and Negative Acceptance Acknowledgement
    * How to align when the NOF is out of band [1].
    * Refine the enumerations expressed for the simpleTypes of Success
      and Failure conditions so you don't have a success under a failure
      [2].

[1] RosettaNet defines NOF that is handled out of band (via an alternate 
channel or transfer protocol). This is used for:

   1. Timeouts when waiting for a specific response on a request.
   2. Responder is unable to acknowledge, accept or process request.

Note, that the RosettaNet picture is only an example.

[2] Action as a result of February F2F (Dale Moberg).

@mm1

Point|Author to champion and v2.0 boundaries;

mm1@
I would like to ask for a champion or small team of volunteers to 
address NOF. I will help coordinate. I would ask Dale to follow-up on 
the simpleTypes item above. Others, please let me know. Thanks.

@mm1