[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Issue 016: WS-C: ReplaceParticipant
I see your point on wanting to move it up into the coordination spec as I look at it more. - Dan -----Original Message----- From: Mark Little [mailto:mark.little@arjuna.com] Sent: Wednesday, December 14, 2005 7:24 AM To: Marchant, Dan R. Cc: ian_robinson@uk.ibm.com; alastair.green@choreology.com; peter.furniss@choreology.com; ws-tx@lists.oasis-open.org 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]