Tom,
The wording:
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
sounds like "any outstanding transactions have been rolled back, and
any transactions already completed have been reversed out".
The old wording was good: it said that the relationship is ended. What
the service does before (or after) it ends the relationship is its
business (or its the subject of a business contract we don't know
about). My point is that BA does not assume that non-participation or
cancellation or withdrawal equal "no enduring effect". I think that the
Microsoft changes imply behaviours which the protocol cannot define.
Another angle on the same wording: who says that the service has to do
anything before it exits? It might just record its exit, and
then clean up or post-process asynchronously.
Yrs,
Alastair
Thomas Freund wrote:
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>
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:
|
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.”
|