[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 016: WS-C: ReplaceParticipant
Yes, but it is specific to the referencing specification (WS-AT in this case). Now maybe that's the right place to put it and that should be one of the things we discuss within this issue IMO. Mark. marchadr@wellsfargo.com wrote: > +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. > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]