Re: [ws-tx] Issue 016: WS-C: ReplaceParticipant

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

Quick comment inline:

Alastair Green wrote:

> Mark,
>
> This is an interesting issue, and dovetails with a couple of questions 
> on the Register/RegisterResponse per se.
>
> The first point is:  we need to make it clear when you have to /stop 
> /retrying Register. You shouldn't send it if you've received 
> RegisterResponse.
>
> If we make R/RR a standard one-way MEP, which I favour, then we can 
> use the notification/terminal notification nomenclature to state this.
>
> Then we come to your address replacement issue per se.
>
> In BTP we ended up with a message, REDIRECT, which either the Superior 
> (Coordinator) or Inferior (Participant) could send to the other, 
> saying: this is entity Foo, please send my messages to this new 
> address. To do this one needs an identity, so one can say: "I am Foo". 
> If you have a Coordinator identifier and a Participant identifier, 
> then this is easy.
>
> However, I think we already have this (bidirectional) feature in the 
> WS-AT and WS-BA protocols in another form, albeit somewhat tucked away.
>
> In Section 9 on use of WS-A Headers, it is stated that a non-terminal 
> notification has to have a reply-to address. I presume (there is no 
> statement on this, and that needs fixing, for sure) that this field 
> only makes sense if I am trying to redirect subsequent traffic. In 
> other words, I send a standard message but qualify it with the added 
> semantic: "I've moved". If the receivers sees this, I assume they 
> should overwrite the old EPR they have, and continue as normal.
>
> Such an address replacement means that redirection is accomplished as 
> a by-product of recovery-driven replay of messages, or because the 
> load balancer has done a reshuffle -- it doesn't really matter why.
>
> This is neat, because it avoids having to communicate identifiers for 
> redirection (they are still needed for the original register as per 
> other discussions).
>
> Therefore, I believe that this issue could be resolved by 
> supplementing and expanding the  WS-Coord  spec's statements on  MEPs, 
> types of messages etc, with a statement that a non-terminal 
> notification reply-to should supplant the previously held EPR for the 
> next and subsequent messages in the conversation, and we're done.
>
> It is probably obvious, but I see no very good reason why redirection 
> (address replacement) should be limited to the Participant end.

Yes, as we did with WS-CF too, the coordinator can obviously fail and 
recovery elsewhere, necessitating participant updates. However, I didn't 
want to register that as an issue until I determined the view of the TC 
on this issue.

Mark.

>
> Alastair
>
>
> Peter Furniss wrote:
>
>>This is hereby identified as ws-tx issue 016
>>
>>Please follow up to this message or otherwise ensure your subject line
>>starts "Issue 016 - " 
>>	(after any Re:, [ws-tx] etc)
>>
>>
>>Issue name -- WS-C: ReplaceParticipant
>>
>>Owner: Mark Little [mailto:mark.little@jboss.com]
>>
>>Target document and draft:
>>
>>Protocol:  Coord
>>
>>Artifact:  spec / schema
>>
>>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 
>>
>>
>>Issue Type
>>
>>Design
>>
>>Issue Details
>>
>>In order to coordinate long running interactions, it is necessary to 
>>tolerate failures and recovery situations within the scope of an 
>>activity (long running activity). Once a participant is registered with 
>>a coordinator,  the current specification implicitly mandates that 
>>recovery requires it to come back up on the same EPR in order that the 
>>coordinator can subsequently drive it through whatever protocol is used 
>>(e.g., 2PC). However, recovery on the same EPR cannot be guaranteed and 
>>is at best an implementation choice. Failure to recover on the same EPR 
>>will ultimately lead to more coordinated activities terminating in a 
>>failure state (e.g., aborting) because participants cannot be reached, 
>>even if they failed and recovered prior to the start of execution of the
>>
>>coordinator's protocol.
>>
>>Proposed Resolution:
>>
>>That we add a ReplaceParticipant operation that allows a registering 
>>service to instruct the coordinator service to replace one EPR with 
>>another EPR. Because EPRs are not currently comparable, a resolution of 
>>issue 7 or 14 is relevant to this issue.
>>
>>
>>
>>  
>>