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

[<marchadr@wellsfargo.com>]

Looks like this is already mentioned a bit in the WS-AT spec:

"Notification messages are addressed by both coordinators and participants using the Endpoint
References initially obtained during the Register-RegisterResponse exchange. If a wsa:ReplyTo header
is present in a notification message it MAY be used by the recipient, for example in cases where a 
Coordinator or Participant has forgotten a transaction that is completed and needs to respond to a resent
protocol message. Permanent loss of connectivity between a coordinator and a participant in an in-doubt
state can result in data corruption."

- Dan

-----Original Message-----
From: Marchant, Dan R. 
Sent: Wednesday, December 14, 2005 6:43 AM
To: ian_robinson@uk.ibm.com; alastair.green@choreology.com
Cc: peter.furniss@choreology.com; ws-tx@lists.oasis-open.org
Subject: RE: [ws-tx] Issue 016: WS-C: ReplaceParticipant


+1 for using the ReplyTo.

The replyTo could be an endpoint that virtualizes the specific endpoints within the EPR,
creating a cleaner failover and recover scenario.

My 2 cents,

Dan


-----Original Message-----
From: Ian Robinson [mailto:ian_robinson@uk.ibm.com]
Sent: Wednesday, December 14, 2005 6:15 AM
To: Alastair Green
Cc: Peter Furniss; ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 016: WS-C: ReplaceParticipant






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.