Alastair,
I believe the language that Ram is suggesting is neutral regarding the specifics of the "handling" that occurs within the participant for each transactional event.
It merely states the guarantee that whatever "handling" was required has been performed.
Are you suggesting the terms are being overloaded ... e.g. 'compensated' should read 'compensation handling'?
Regards
Tom
Alastair Green <alastair.green@choreology.com>
08/16/2006 05:38 AM |
|
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.”
Tom
"Ram Jeyaraman" <Ram.Jeyaraman@microsoft.com>
07/22/2006 12:47 AM |
|
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.
- 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.
- 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.
- 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.
- 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.
- “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.”
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.
- 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.
- 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.
- 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.
- 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.
“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.”
