[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable
Merry Christmas and happy holidays to all! There are a few observations I would like to make on this topic before I head out on vacation. First, it is perfectly possible to implement WS-AT without participant identifiers in a manner that does not prohibit deliberate resends generate undesired transaction aborts. There are two generally interesting cases: one in which the participant has forgotten and is not aware that it is sending a duplicate Register, and another in which the participant has deliberately decided to resend Register. Both can be made to work in an interoperable fashion. I'll send a separate message containing that discussion. Second, I do not believe that anyone in this TC wishes to prohibit the possibility of creating a coordination protocol that relies on participant identifiers or any other mechanism in order to ensure correctness. On the other hand, it seems unwise to me to attempt to enforce a single model for registration for every coordination protocol, regardless of their specific requirements. The design spirit of WS-Coordination, which we applied quite successfully in the last telephone discussion (concerning the appropriate definition and placement of faults), is to include two general sets of mechanisms in WS-C: 1) Those that are used by virtually all protocols 2) Broad extensibility that allows derived protocols to cover their other specific needs. That philosophy, applied to this discussion, would suggest that if a given mechanism is not needed by our current coordination protocols, it is not a good candidate for inclusion in the base specification. Consequently, the participant identifier mechanism is a perfect example of a mechanism that should make use of WS-Coordination extensibility. Any protocol that requires the ability to detect duplicate registrations and uniquely identify participants can simply leverage the open content that is provided in the Register message. I think that the interesting discussion is not whether such a mechanism belongs in WS-Coordination (I think it is pretty clear that it does not), but whether specific coordination protocols need such a mechanism. The ones that do should not be prohibited by WS-C; the ones that don't should not suffer any additional complexity. I believe that is the case with the current language in the specifications, although some editorial language clarifying this freedom may be appropriate (e.g. Ian's suggested text). Third, some odds and ends in response to several previous messages: - AlreadyRegistered was intended mostly for protocols such as WS-AT Completion where duplicate detection is trivial. Given that we have already determined that a RegistrationFailed fault is desirable, we can probably just delete the AlreadyRegistered fault. For protocols that can detect duplicates, the appropriate response for a duplicate registration is likely either a RegistrationFailed fault with a specific reason, a standard RegisterResponse or some protocol-specific message. - Register messages that are duplicated by the transport are not likely to be of concern to a coordination protocol; duplicate detection can be trivially performed at the SOAP layer by filtering on message ids. It's just as easy as filtering on some other identifier, and it's likely that many stacks will already do this. - WS-AT Completion registrations are restricted to a single participant. It is true that adding participant identifiers would allow a completion participant to re-send register. However, Completion participants are (a) unlikely to be recoverable or tolerant of failures and (b) unlikely to be topologically distant from their coordinator. Consequently, I do not sense a strong need to allow the Completion registrations to be re-sent. ________________________________ From: Mark Little [mailto:mark.little@jboss.com] Sent: Sun 12/18/2005 7:24 AM To: Peter Furniss Cc: Max Feingold; ws-tx@lists.oasis-open.org Subject: Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable Peter Furniss wrote: >>A failure to receive a register response could trigger a >>completely new >>register message with a new EPR (on the assumption a retry of >>the first >>attempt caused the already-registered fault to be returned). The only >>problem I can see at present with this mechanism is that >>manufacturing a >>new EPR for the "same" participant may not be feasible in some >>environments. However, that could be seen as an >>implementation problem. >>The advantage would be that no changes to the specification >>are required >>- other than a clarification of the text to call out this possibility. >> >> > >With no change to the current texts, I don't see how you can get >already-registered unless the coordinator does an illegal EPR >comparison. (that is really part of 014 - whatever we specify as the >reaction, there needs to be a sound way of detecting duplicates - no >change is not an option). > > I'm trying to consider the issues in isolation, but I'll admit that's difficult ;-) >But apart from that (i.e. assume we have a duplicate detection means), >and back to >the conceptual point of this issue, why specify that a coordinator >detecting that Register is for the same Participant as as one already >registered must fault with AlreadyRegistered ? Just assume that the >transport, or the sending implementation has caused the duplicate to >turn up, and reply with a RegisterResponse reflecting the Coordinator's >endpoint. > > My intention was to point out that a solution is possible within the scope of the current specification. Whether or not that solution is one we wish to adopt, is the subject of this and other discussions, just as the other proposed solutions have been. >In 95% of cases the EPR's will be unchanged. >If they have changed (which would only be because the endpoint owner >"wanted" to change it), the most recent SHOULD be used for sending by >the peer (not MUST because that would impose complications for some >persistence strategies). > > > > >>>The alternative of trying to make multiple registrations for >>> >>> >>what is in >> >> >>>fact the same participant work would seem to cause considerable >>>complications. For atomic cases, the coordinator may not mind - it >>>just sees two (or more) registrations and they must both be committed >>> >>> > > > >>>(or >>> >>> >>rolledback). But Max's >> >> >>> >>> >>> >>> >>>>"The participant >>>> >>>> >>>> >>>> >>>>>simply needs to behave correctly[1] by distinguishing its multiple >>>>>enlistments. >>>>> >>>>> >>>>> >>>>> >>>is very questionable, because it will receive two Prepare's >>> >>> >>(say), both >> >> >>>delivered to the same EPR, but must reply to different coordinator >>>endpoints, one given on >>>the succesful RegisterResponse, one on the lost one. As in Alastair's >>>diagrams sent earlier today, it would have to use the >>> >>> >>Reply-To EPR (in >> >> >>>which case, why not use that anyway and get rid of the >>> >>> >>RegisterResponse >> >> >>>altogether) [this is completely impossible for coordination protocols >>> >>> > > > >>>where the first message is participant to coordinator - see >>> >>> >>Alastair's >> >> >>>diagram 3] >>> >>> >>> >>> >>I agree all of this is possible and may be sub-optimal in certain >>degenerate situations. However, when weighed against the timeline >>imposed for getting WS-C through to standardisation, it may >>be that the >>"do nothing" approach I mentioned above is the best option. >> >> >> >>>Gosh, this has ended up rather long (and will probably now >>> >>> >>cross with >> >> >>>other messages saying the same thing or rendering it out of date) >>> >>> >>> >>> >>To be honest I don't have a hard stance on any solutions to >>this issue >>at the moment. My only concern is time spent so far and the fact that >>there are other issues to work through that may be equally, or more, >>contentious. I hope we can bring this to a conclusion (a vote) soon. >> >> > >Well, we closed a quarter of the issues list yesterday, and this one is >related to at least two of the others, and the discussion has made good >progress. I think it's a little early to >be worrying about timescales. > > > I disagree that it is too early. Several of the companies on this list have implementations that are already interoperable and, speaking as the representative of one of them, we'd like to get reduce the amount of time this TC takes to standardise. Mark.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]