[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: NEW issue: WS-C: Make Register/RegisterResponse retriable
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]"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]