Max described to this group why explicit participant ids are not required
to resolve this issue [1], and indeed why they do not help [2].
I think we all agree that the specs do at least need to make a statement on
responsibility for the handling of duplicate messages. This note proposes a
concrete resolution to issue 007.
Start of concrete proposal >>>>>>>>>>>>>>
Changes to WS-Coordination
Add the following to WS-C, after line 307 (at the end of section 3.2):
"A Registration service is not required to detect duplicate Register
requests and may treat each Register message as a request to register a
distinct participant.
A participant MAY send multiple Register requests to a Registration
service. For example, it may retry a Register request following a lost
RegisterResponse, or it may fail and restart after registering successfully
but before performing any recoverable work.
If a participant sends multiple Register requests for the same activity,
the participant MUST be prepared to correctly handle duplicate protocol
messages from the coordinator. One simple strategy for accomplishing this
is for the participant to generate a unique reference parameter for each
participant Endpoint Reference that it provides in a Register request. The
manner in which the participant handles duplicate protocol messages depends
on the specific coordination type and coordination protocol."
No changes are required to WS-AT
The state table already illustrates the correct behaviour for the 2 cases:
lost RegResp. Should allow forward progress. See "participant view"
state table for handling of duplicate protocol messages:
[event=Prepare, state=PreparedSuccess] -> "Resend Prepared"
[event=Commit, state=None] -> "Send Committed"
reinfection after failure. Should cause failure. See "participant view"
state table for participant handling of protocol messages for an
unknown/forgotten activity:
[event=Prepare, state=None] -> "Send Aborted"
Changes to WS-BA
One correction and one clarification required in WS-BA:
(i) Correction: In Appendix B, Table C3 "CoordinatorCompletion - protocol
messages received by Participant", change cell [event=Complete, state=None]
from "Ignore/Ended" to "Send Fault/Ended",
(ii) Clarification: Add the following text after line 218 (description of
the "GetStatus" message):
"A coordinator that is waiting for a participant to initiate the
BusinessAgreementWithParticipantCompletion might use this message to
confirm that the participant is in one of the expected states:
"wsba:Active" or "wsba:Completed". If the participant has failed and
forgotten the activity the Status response will be "wsba:Ended", which must
be treated by the coordinator as a failure condition.
End of concrete proposal >>>>>>>>>>>>>>
Discussion on rationale for WS-BA changes:
For BA, CoordinatorCompletion
lost RegResp. Should allow forward progress. See "participant view"
state table for handling of duplicate protocol messages:
[event=Complete, state=Completed] -> "Resend Completed"
[event=Close, state=Ended] -> "Send Closed"
reinfection after failure. Should cause failure. See "participant view"
state table for participant handling of protocol messages for an
unknown/forgotten activity:
[event=Complete, state=None] -> Needs to result in a fault message
response. See (i) above.
For BA, ParticipantCompletion
lost RegResp. Should allow forward progress.
See (ii) above.The coordinator will have a duplicate Participant
registered and will timeout waiting for the "wsba:Completed". It may
react to this by sending a wsba:GetStatus to the duplicate Participant,
and will receive a staus of "wsba:Completed". Further considerations are
identical to CoordinatorCompletion.
reinfection after failure. Should cause failure.
See (ii) above. The coordinator will have an orphaned Participant
registered and will timeout waiting for the "wsba:Completed". It may
react to this by sending a wsba:GetStatus to the orphaned Participant,
and will receive a staus of "wsba:Ended", since the orphan has no
knowledge of the activity.
[1]
http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200512/msg00223.html
[2]
http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200601/msg00049.html
Regards,
Ian