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

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

Colleen Evans wrote:

>Forwarding for Max.
>Colleen
>
>-----Original Message-----
>From: Max Feingold 
>Sent: Wednesday, December 14, 2005 6:22 PM
>To: ws-tx@lists.oasis-open.org
>Subject: RE: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse
>retriable
>
>After digesting this week's discussion on this topic, I have a few
>observations:
>
>- I cannot think of a protocol that requires idempotent registration.
>WS-AT certainly does not need it.  A conformant WS-AT participant might
>only send a single Register message and report failure to the registrant
>if a timeout or comms failure occurs.  It can also send multiple
>Register messages.  The coordinator will create a new participant
>enlistment for each Register it receives.  The participant simply needs
>to behave correctly[1] by distinguishing its multiple enlistments.
>  
>
You're right. OTS, for example, doesn't place a restriction on 
participant registration either. Speaking purely about transactions, 
with the exception of the Activity Service, I'm not sure of a protocol 
that prevents multiple registrations. If we say that the operation isn't 
idempotent, then we definitely need to remove the fault message though, 
in case retransmissions are attempted for failure situations.

>- One can imagine that different coordination types might have different
>expectations for what it means to send multiple (duplicate) Register
>messages.  Given that Register is scoped to a specific coordination type
>at both the participant and the coordinator, it is not clear that the
>semantics of Register can (or should) be universally constrained to a
>single pattern.
>  
>
I'm happy to punt this up to referencing specifications.

>- A hypothetical coordination protocol that wants to detect duplicates
>should not overload existing WS-Addressing mechanisms.  Instead, it
>should use WS-C extensibility to create specific participant
>identifiers.  Some protocols may need this functionality for
>correctness.  I do not believe that any of the WS-Tx protocols need it.
>  
>
If we don't try to detect duplicate enlistments at this level, then we 
also get round the need for EPR comparisons and don't need to add a new 
participant URI to register either.

Mark.

>...
>
>[1] "Correctly" here means not splitting the transaction tree.  I can
>follow up on this if people are interested in the details.
>
>-----Original Message-----
>From: Peter Furniss [mailto:peter.furniss@choreology.com] 
>Sent: Friday, December 09, 2005 9:54 AM
>To: ws-tx@lists.oasis-open.org
>Subject: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse
>retriable
>
>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]"
> 
> 
>
>
>  
>