[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 016: WS-C: ReplaceParticipant
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. >> >> >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]