[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
I'm going to forget you suggested that ;-) Mark. Duane Nickull wrote: > Concur. > > Of course if we used WS-RX DA’s like “only once”, “exactly once”…. > (just kidding)… > > Duane > > ******************************* > Adobe Systems, Inc. - http://www.adobe.com <http://www.adobe.com/> > Vice Chair - UN/CEFACT http://www.uncefact.org/ > Chair - OASIS SOA Reference Model Technical Committee > Personal Blog - http://technoracle.blogspot.com/ > ******************************* > > ------------------------------------------------------------------------ > > *From:* Christopher B Ferris [mailto:chrisfer@us.ibm.com] > *Sent:* Monday, December 12, 2005 10:43 AM > *To:* Mark Little > *Cc:* ws-tx@lists.oasis-open.org > *Subject:* Re: [ws-tx] Issue 007 - WS-C: Make > Register/RegisterResponse retriable > > > That is one way, the other is to make the Register message idempotent. > > Seems to me that Register SHOULD be idempotent. It is much simpler to > simply process > the Register as if it had never been received... makes the > implementation of the client > a bit simpler. > > I also think that the "AlreadyRegistered" fault is probablematic. It > doesn't reflect > back the CoordinationProtocolService EPR that the RegisterResponse > message does. > So, from the perspective of the registrant, it ISN'T registered if it > doesn't receive the > RegisterResponse message since it doesn't know the > CoordinationProtocolService > EPR. > > From the perspective of the registration service, overlaying the > previous registered > EPR is effectively an idempotent operation, and the response can be > the same as if > it didn't have the registration beforehand. > > IMO, making the operation idempotent makes the implementation much > simpler and > more robust in the long run. > > Cheers, > > Christopher Ferris > STSM, Emerging e-business Industry Architecture > email: chrisfer@us.ibm.com > blog: http://webpages.charter.net/chrisfer/blog.html > phone: +1 508 377 9295 > > *Mark Little <mark.little@jboss.com>* > > 12/12/2005 11:36 AM > > > > To > > > > ws-tx@lists.oasis-open.org > > cc > > > > 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]