[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable
Actually I'll retract this. As Kevin just reminded me, we're using WS-Addressing anyway, so surely lost messages and retries can be coped with at that level: using the same wsa:MessageID for example, should sort this. Mark. Mark Little wrote: > 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]" >> >> >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]