NEW issue: WS-C: Make Register/RegisterResponse retriable

[Alastair Green <alastair.green@choreology.com>]

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

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL 
THE ISSUE IS ASSIGNED A NUMBER.

The issues coordinators will notify the list when that has occurred.

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 [] WS-C: Remove fault 4.6 AlreadyRegistered
Issue [] WS-C: EPR equality comparison is problematic
Issue [] 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
"WS-C/WS-AT: Is request-reply MEP useful?" in "Related Issues".)

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]"