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

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

I agree that this could work (and with recover it should work even if 
the failure happens prior to the start of the termination protocol). 
However, the registered issue is deliberately aimed at the WS-C 
specification: is this something that we want to make generic and 
support within the coordination framework, rather than repeat within 
each referencing specification? I suggest that it is, if WS-C is meant 
to be the "generic coordination infrastructure service" that we believe 
it should be.

Mark.

Ian Robinson wrote:

>
>
>As you say, section 9 of WS-AT deals with this situation. I believe the
>text is already appropriately worded. Essentially, the registered EPR is
>good until it isn't; if the registered EPR becomes "stale" in some way then
>the ReplyTo EPR is the means by which the EPR can be "refreshed". There is
>deliberately no requirement to replace the registered EPR with the ReplyTo
>EPR - this allows an implementatoin to log the registered EPR and to
>continue to use it throughout the transaction and across any failures.
>The following sequence illustrates how EPR replacement is supported:
>
>Participant A registers EPR Pa.
>Coordinator C1 sends Prepare to Pa and it responds Prepared.
>Participant A's environment suffers a disasterous failure and the
>participant is recovered at a different address.
>C1 tries to send commit to Pa but Pa is no longer addressable.
>C1 retries the commit.
>Meanwhile Pa is recovered at Pa' and resends Prepared to C1 with Pa' as the
>ReplyTo MAP.
>C1, having determines that Pa is not responding, replaces Pa with Pa' and
>REsends commit (per the AT state table)
>The transaction proceeds to successful conclusion.
>
>
>Regards,
>Ian Robinson
>STSM, WebSphere Messaging and Transactions Architect
>IBM Hursley Lab, UK
>ian_robinson@uk.ibm.com
>
>
>                                                                           
>             Alastair Green                                                
>             <alastair.green@c                                             
>             horeology.com>                                             To 
>                                       Peter Furniss                       
>             13/12/2005 19:04          <peter.furniss@choreology.com>      
>                                                                        cc 
>                                       ws-tx@lists.oasis-open.org          
>                                                                   Subject 
>                                       Re: [ws-tx] Issue 016: WS-C:        
>                                       ReplaceParticipant                  
>                                                                           
>                                                                           
>                                                                           
>                                                                           
>                                                                           
>                                                                           
>
>
>
>
>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.
>
>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.
>
>
>
>
>
>
>  
>