[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 016: WS-C: ReplaceParticipant
Understood, but I raise it now because the suggested solution (which I think is latent but half-hidden in the existing specs) does include the bidirectional capability. Alastair Mark Little wrote: > 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]