Re: [ws-tx] Issue 085 - WS-BA: Protocol messages should be redefinedto provide specific guarantees

[Alastair Green <alastair.green@choreology.com>]

I think there is a fundamental problem with this set of changes.

BA-like activities are not atomic transactions. The nature of participants is cannot be assumed a priori. Participants are very likely not to be generic resource managers, and are much more likely to be chunks of application behaviour.

What Exit or Cancel etc mean is therefore governed by the overall business contract of the parties, is application-specific.

You might have a situation where an exiting party which has indicated that it is completed has to pay a fee to exit. Or it may have to keep business records relating to the abortive interaction.

In other words, the counter-operation to an operation cannot be assumed to be inversion. We cannot assume that the job of the protocol-assisted business transaction is to return the state of parties which engage/withdraw, or are told to withdraw, to the status quo ante.

Parenthetically, these verbal definitions should not attempt to reproduce or overdefine state table declarations, for example -- in which state can a message legally be sent.

Alastair

Ram Jeyaraman wrote:

Thanks Tom,

 

> Should the fault Fault be modified to distinguish between ParticipantCompletion & CoordinatorCompletion (i.e. Completing/Fault only occurs for the latter).

 

I suppose if the coordinator can benefit from such a distinction, it may be useful.

 

The suggested changes to the Exit message description seems fine.

 

From: Thomas Freund [mailto:tjfreund@us.ibm.com]
Sent: Wednesday, August 09, 2006 6:22 AM
To: Ram Jeyaraman
Cc: ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 085 - WS-BA: Protocol messages should be redefined to provide specific guarantees

 

Ram

I would agree with the proposed changes with the following clarifications:

Should the fault Fault be modified to distinguish between ParticipantCompletion & CoordinatorCompletion (i.e. Completing/Fault only occurs for the latter).

Exit

“Upon receipt of this notification, the coordinator knows that the participant will no longer participate in the business activity, and <insert> any pending work was discarded by the participant and <end insert> 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.”

Regards
Tom
"Ram Jeyaraman" <Ram.Jeyaraman@microsoft.com>

"Ram Jeyaraman" <Ram.Jeyaraman@microsoft.com>

07/22/2006 12:47 AM

To	<ws-tx@lists.oasis-open.org>
cc
Subject	[ws-tx] Issue 085 - WS-BA: Protocol messages should be redefined to provide specific guarantees

 

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:
Close

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.”
to
“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.”