Re: [ws-tx] Issue 044 - WS-C: Clarify which endpoint is used to detectduplicate participant registrations

[Alastair Green <alastair.green@choreology.com>]

Max,

Since I raised this issue, the way in which WS-Addressing will be used 
has seemingly stabilized, and in a direction which obviates my concern.

1. The /Register/ParticipantProtocolService (PPS) EPR must always 
contain a unique participant-id, I agree.

2. If [message id]/[relationship] correlation is used to map the RR to 
the R, then it will all work. Other postings on e.g. Issue 030 have not 
raised this as a  strong motivation for using message ids in the WS-C 
exchanges, but is perhaps an underlying assumption that helps to explain 
the divergence of perception about how this will work.

3. If [relationship] correlation is not used, then [reply endpoint] must 
equal or map to the PPS. This is an alternative way of implementing the 
technique. This is where I was coming from.

4. However, 2 and 3 are implementation choices, that do not require 
further spec change. The apparatus is there for both approaches.

I'm happy to resolve the issue with no change, therefore.

Alastair


Max Feingold wrote:
> I thought it was clear that the text was referring to the participant's EPR.  By including a unique identifier in a reference parameter, the participant can determine which individual registration is targeted by subsequent protocol messages from the coordinator.
>
> The naïve way to model this is to think about each individual registration attempt creating its own distinct state machine.  Each unique identifier is used later to route protocol messages to the appropriate state machine.  You can imagine optimizations that would coalesce the state machines, but that's the basic idea.
>
> Unless I'm the only one who thinks the text is clear enough, I'd propose to close this issue with no change.
>
> -----Original Message-----
> From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] 
> Sent: Wednesday, March 29, 2006 1:51 PM
> To: ws-tx@lists.oasis-open.org
> Subject: [ws-tx] Issue 044 - WS-C: Clarify which endpoint is used to detect duplicate participant registrations
>
>
> This is identified as WS-TX issue 044.
>
> Please ensure follow-ups have a subject line starting "Issue 044 - WS-C:
> Clarify which endpoint is used to detect duplicate participant
> registrations".
>
> -----Original Message-----
> From: Alastair Green [mailto:alastair.green@choreology.com] 
> Sent: Wednesday, March 29, 2006 8:19 AM
> To: ws-tx@lists.oasis-open.org
> Subject: [ws-tx] NEW ISSUE: WS-C: Clarify which endpoint is used to
> detect duplicate participant registrations
>
> Issue name -- WS-C: Clarify which endpoint is used to detect duplicate 
> participant registrations
>
> 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:  WS-C
>
> Artifact:  spec
>
> Draft:
>
> WS-C spec CD 0.1 uploaded
>
> Link to the document referenced:
>
> http://www.oasis-open.org/committees/download.php/17311/wstx-wscoor-1.1-
> spec-cd-01.pdf
>
>
> Section and PDF line number:
>
> ll. 317 - 321. Section 3.2, "Registration Service"
>
>
> Issue type:
>
> Design/Editorial
>
>
> Related issues:
>
> None
>  
>
> Issue Description:
>
> Current text from resolution to 007 implies that 
> /ParticipantProtocolService endpoint can be used to detect duplicate 
> registrations.
>
>
> Issue Details:
>
> ll. 317 - 321 read:
>
> "If a participant sends multiple Register requests for the same 
> activity, the participant MUST be prepared to correctly handle duplicate
>
> protocol messages from the coordinator. One simple strategy for 
> accomplishing this is for the participant to generate a unique reference
>
> parameter for each participant Endpoint Reference that it provides in a 
> Register request. The manner in which the participant handles duplicate 
> protocol messages depends on the specific coordination type and 
> coordination protocol."
>
> The sentence beginning "One simple strategy ..." is ambiguous (at best) 
> about which EPR is being referred to. The Register request supplies a 
> /ParticipantProtocolService EPR, and a wsa:ReplyTo EPR. The strategy 
> being discussed here can only work if the WS-A [reply endpoint] has a 
> value that unambiguously identifies (for the registering service) the 
> participant. The PPS EPR is irrelevant.
>
> Further, message ids could be used by the registering service to achieve
>
> the same level of knowledge of duplication.
>
>
> Proposed Resolution:
>
> Option 1:
>
> Replace the sentence beginning "One simple strategy ..." with the 
> following sentence:
>
> "One simple strategy for accomplishing this is for the sender of 
> Register to ensure that the the WS-Addressing [reply endpoint] Endpoint 
> Reference that it provides in a Register request identifies the 
> participant unambiguously from the sender's standpoint."
>
> Option 2:
>
> Replace the sentence beginning "One simple strategy ..." with the 
> following sentence:
>
> "This can be accomplished either by the sender of Register keeping track
>
> of the message ids of Register messages that refer to the same 
> participant, or by the sender of Register ensuring that the the 
> WS-Addressing [reply endpoint] Endpoint Reference that it provides in a 
> Register request identifies the participant unambiguously from the 
> sender's standpoint. Each of these techniques will allow duplicate 
> RegisterResponses which refer to the same participant to be detected by 
> the requester."
>
>
>