Issue 085 - WS-BA: Protocol messages should be redefined to provide spec

This is identified as WS-TX issue 085.

Please ensure follow-ups have a subject line starting "Issue 085 – WS-BA: Protocol messages should be redefined to provide specific guarantees".

From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
Sent: Friday, July 21, 2006 10:44 PM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] NEW Issue - WS-BA: Protocol messages should be redefined to provide specific guarantees

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: sections 1, 3.1 and 3.2

Issue type: design

Related issues:

Issue Description:

It is fundamentally important for interoperability that the BA specification provide a clear definition of the semantics of each protocol message, in order to establish the precise state management guarantees that must be provided by a conformant implementation.

For example, the current definition of Compensated does not indicate that the participant should actually complete its compensation efforts before sending the message. For a participant to return this message, all it has to do is record a compensation request. It is not clear what has happened or will happen to the work that needs to be compensated

As another example, the current definition of the Exit message does not clearly state what happened to the work performed by the participant prior to exiting. Was the work successfully cancelled? Or perhaps no work was performed at all?

Similarly, other protocol messages need to be reviewed to ensure that specific guarantees are provided.

Proposed resolution:

Modify the message definitions as follows:

The coordinator accepts:

Completed

Upon receipt of this notification, the coordinator knows that the participant has successfully completed all processing related to the protocol instance. For the next protocol message the coordinator should send a Close or Compensate notification to indicate the final outcome of the protocol instance. After sending the Completed notification, a participant MUST not participate in any further work under that activity.

Fault

Upon receipt of this notification, the coordinator knows that the participant has failed during the Active, 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.

Compensated

After transmitting this notification, the participant may forget about the activity. Upon receipt of this notification, the coordinator knows that the participant has successfully compensated all processing related to the protocol instance; the coordinator may forget its state about that participant.

Closed

After transmitting this notification, the participant may forget about the activity. Upon receipt of this notification, the coordinator knows that the participant has finalized the protocol instance successfully; the coordinator may forget its state about that participant.

Canceled

After transmitting this notification, the participant may forget about the activity. Upon receipt of this notification, the coordinator knows that the participant has successfully canceled all processing related to the protocol instance; the coordinator may forget its state about that participant.

Exit

“Upon receipt of this notification, the coordinator knows that the participant will no longer participate in the business activity, and any work performed by the participant related to the protocol instance was successfully canceled. For the next protocol message the coordinator should send an Exited notification. This message may be sent by a participant only from the Active or Completing states.”

The participant accepts:

Upon receipt of this notification, the participant knows the protocol instance is to be ended successfully. For the next protocol message the participant should send a Closed notification to end the protocol instance.

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 message. A Canceled message should be sent by the participant if the work is successfully canceled; this also ends the protocol instance.

Compensate

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

Faulted

After transmitting this notification, the coordinator may forget about the participant. Upon receipt of this notification, the participant knows that the coordinator is aware of a fault and no further actions are required of the participant; the participant may forget the activity.

Exited

After transmitting this notification, the coordinator may forget about the participant. Upon receipt of this notification, the participant knows that the coordinator is aware the participant will no longer participate in the activity; the participant may forget the activity.

Further, the following statement in the Introduction section of the specification should be modified from:

“All notifications are acknowledged in the protocol to ensure a consistent view of state between the coordinator and participant.”

“All non-terminal notifications are acknowledged in the protocol to ensure a consistent view of state between the coordinator and participant. A coordinator or participant may retry sending notifications in order to achieve this.”

ws-tx message