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

[Mark Little <mark.little@jboss.com>]

I think this makes proposal makes sense.

Mark.


Peter Furniss wrote:

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