RE: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable

["Colleen Evans" <coevans@microsoft.com>]

Forwarding for Max.
Colleen

-----Original Message-----
From: Max Feingold 
Sent: Wednesday, December 14, 2005 6:22 PM
To: ws-tx@lists.oasis-open.org
Subject: RE: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse
retriable

After digesting this week's discussion on this topic, I have a few
observations:

- I cannot think of a protocol that requires idempotent registration.
WS-AT certainly does not need it.  A conformant WS-AT participant might
only send a single Register message and report failure to the registrant
if a timeout or comms failure occurs.  It can also send multiple
Register messages.  The coordinator will create a new participant
enlistment for each Register it receives.  The participant simply needs
to behave correctly[1] by distinguishing its multiple enlistments.

- One can imagine that different coordination types might have different
expectations for what it means to send multiple (duplicate) Register
messages.  Given that Register is scoped to a specific coordination type
at both the participant and the coordinator, it is not clear that the
semantics of Register can (or should) be universally constrained to a
single pattern.

- A hypothetical coordination protocol that wants to detect duplicates
should not overload existing WS-Addressing mechanisms.  Instead, it
should use WS-C extensibility to create specific participant
identifiers.  Some protocols may need this functionality for
correctness.  I do not believe that any of the WS-Tx protocols need it.

...

[1] "Correctly" here means not splitting the transaction tree.  I can
follow up on this if people are interested in the details.

-----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com] 
Sent: Friday, December 09, 2005 9:54 AM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse
retriable

This is hereby declared to be ws-tx Issue 007.

Please follow-up to this message or ensure the subject line starts Issue
007 - (ignoring Re:, [ws-tx] etc)

The Related Issues list has been updated to show the issue numbers.

Issue name -- WS-C: Make Register/RegisterResponse retriable

Owner:  Alastair Green [mailto:alastair.green@choreology.com]

Target document and draft:

Protocol:  Coord

Artifact:  spec

Draft: Coord spec working draft uploaded 2005-12-02
 
Link to the document referenced:

http://www.oasis-open.org/committees/download.php/15738/WS-Coordination-
2005-11-22.pdf
 
Section and PDF line number:
 
 WS-Coordination spec, Section 3.2 "Registration Service" l. 294
 
 
Issue type: Design
 
 
Related issues:

 Issue 008 - WS-C: Remove fault 4.6 AlreadyRegistered
 Issue 014 - WS-C: EPR equality comparison is problematic 
 Issue 009 - WS-C/WS-AT: Is request-reply MEP useful?
 
 
Issue Description:

 Register/RegisterResponse should be retriable exchange
 

Issue Details:
 
 [This issue stems from Choreology Contribution issue TX-20.]
 
 Section 9 of WS-AT defines the WS-Coordination exchanges
  
     CreateCoordinationContext/CreateCoordinationContextResponse
     Register/RegisterResponse
 
 as request-reply exchanges.
 
 (Whether this request reply MEP should be used at all in the WS-TX
specs is addressed 
in a separate issue: see  "Issue 009 - WS-C/WS-AT: Is request-reply MEP
useful?".)
 
Substantively, it may be particularly misleading to think of the
Register/RegisterResponse
exchange as a request-reply pattern. The 
implication of using this pattern is that there is a simple one 
message in, one message out exchange. The presence of a fault
(AlreadyRegistered) as a potential response to Register hardens
that implication.

Current behaviour would lead to service being informed it has already
registered a
Participant, when it has in fact simply succeeded in 
registering a Participant. Superficially, the
AlreadyRegistered fault could simply be
viewed as being unnecessarily verbose: the reaction of the service to 
the fault at run-time must be to treat
it as uninteresting, i.e. as equal in effect to a successful 
registration.
 
In fact there is a deeper problem. Consider the following scenario:
 
A Coordination Service (CS) creates a Coordinator (C) for a new atomic 
transaction (AT), and emits a CoordinationContext (CC).

The CC is transmitted to an application service (AS). AS (logically)
creates 
a P which sends Register (R) to the Registration Service (RS) 
EPR for AT, embedding the EPR for receipt
of protocol messages outbound from C to P (CP EPR).

The RS, on receiving Register, creates an EPR for inbound protocol
messages 
from P to C (PC EPR), and embeds this in the RegisterResponse 
(RR), which it sends to P.

AS and P crash before the RR message is received by P, or the RR message
drops 
and is never received by P. Either way, AS (on recovery, or after
waiting) causes P to 
resends R to RS. RS examines the inbound Register,
and determines that it has come from a known P (see "Related Issues", 
"WS-C: EPR equality comparison should
not be relied upon"), i.e. that it is a duplicate registration.

Currently, RS replies with an AlreadyRegistered fault, sent to P. P now 
knows that he is registered with C, but has never received the PC EPR 
(/RegisterResponse/CoordinationProtocolService element). Any further 
retries of P send R to C will result in the same situation.

C will never be able to receive messages from P. P will never become 
Prepared. The transaction will eventually collapse through timeout.

Therefore, the Register/RegisterResponse exchange must tolerate
duplicates. 
If a Register message is delivered more than once (either 
by the transport, or through comms-failure- or recovery-induced retry) 
then the Registration Service should respond on each occasion with a 
RegisterResponse containing the same PC EPR, to ensure reliable 
completion of the EPR exchange that permits the 
subsequent coordination protocol to operate correctly.
 
NOTE.
 
This change brings the R/RR exchange in line with the behaviour of the 
CreateCoordinationContext/...Response
exchange. There is a difference. R/RR is likely to be implemented as a 
true idempotent operation. CCC/CCCR is
not: each CCCR embeds a new RS EPR, and a new 
/Context/Identifier. But each exchange can be harmlessly
replayed indefinitely, in the event of failure to receive the 
response message.


Proposed Resolution:

Insert the following text in WS-Coordination spec, Section 3.2 
"Registration Service" immediately following current l. 294

"[New paragraph]The requester MAY send a Register message for a given 
Participant more than once, and the underlying transport could deliver 
the Register message more than once.
On receipt of a Register message for a
given Participant, which has already been processed succesfully, the 
Registration Service MUST send to the
requester a RegisterResponse containing the same 
CoordinationProtocolService element (Endpoint Reference for 
Participant to Coordinator protocol messages) as that 
contained in all 
previous RegisterResponses generated by
the Registration Service which relate to the Participant's request to 
register for this activity.
[New paragraph]"