[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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] Protocol: WS-BA Section and PDF line number: sections 1, 3.1 and 3.2 Issue type: design Related issues: 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.” |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]