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

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

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