NEW Issue - WS-BA: Allow Fault response to Cancel message

Protocol: WS-BA

Artifact: spec

Draft: BA specification CD 02

Link to the document referenced:

http://www.oasis-open.org/committees/download.php/18818/wstx-wsba-1.1-spec-cd-02.pdf

Section and PDF line number: lines 216-219; figures at lines 245 and 268; state tables at lines 513 and 528.

Issue type: design

Related issues:

Issue Description:

The specification allows a participant to send a Fault message while in Active state.

Similarly, it is conceivable that a participant may send a Fault message while in Canceling state.

Proposed resolution:

Allow a participant to send a Fault response to Cancel message.

The figures at line 245 and 268 should show a state transition resulting out of a Fault notification from Canceling state.

The message definitions should be modified as follows:

Cancel

Upon receipt of this notification, the participant knows that the work being done has to be canceled. For the next protocol message, the participant should send a Canceled or Fault message. A Canceled message should be sent by the participant if the work is successfully canceled; this also ends the protocol instance. A Fault message should be sent by the participant if the work was not successfully canceled.

Fault

Upon receipt of this notification, the coordinator knows that the participant has failed during the Active, Canceling, Completing or Compensating states; the state of the work performed by the participant is undetermined. For the next protocol message the coordinator should send a Faulted notification. This notification carries a QName defined in schema indicating the cause of the fault.

The state table (line 513) ParticipantCompletion/Participant View/Outbound Events/:

{Fault, Canceling} cell should be: (empty, Faulting)

The state table (line 528) CoordinatorCompletion/Participant View/Outbound Events/:

{Fault, Canceling} cell should be: (empty, Faulting)

ws-tx message