[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
See my long mail. If you need a mechanism for handling crashes, then reuse that mechanism to handle transients. Your counterpart doesn't know, and shouldn't care how the situation arose. Alastair Mark Little wrote: > > > Doug Davis wrote: > >> >> Mark - Couple of comments... >> >> Mark Little <mark.little@arjuna.com> wrote on 12/13/2005 05:04:36 AM: >> >> > Doug, I think we can state whatever we like about wsa:MessageID >> > semantics in the case of timeouts and retries. We did that in the >> > interoperability scenario documents. >> >> I believe it would be up to WSA to define wsa:MessageID's semantics >> not WSTX. > > WSA is deliberately trying to be as general as possible, so although > discussions about the use of wsa:messageID have come up during the > working group, very little normative text appears in the current > specification. > > However, that doesn't prevent referencing specifications from imposing > their own rules. So, for example, WS-RX is taking the same approach as > mentioned here: retries MUST have the same wsa:messageID. That doesn't > prevent us from doing likewise. > >> The interop[1] did not say anything about messageID aside from >> when it needed to be there, per WSA rules. Nothing about what it >> looked like on retries. Nor do the Tx specs. >> >> [1] http://wsi.alphaworks.ibm.com:8080/interop/index.html > > OK. > >> >> > The only issue with wsa:MessageID being used in this case is that, >> > without requiring persistent structures, it isn't going to work in the >> > case of crash failures. So if we assume that the scenario outlined in >> > the original issue (registration response message is lost because the >> > receiver has crashed, subsequently comes back and can't >> re-register) is >> > valid, using wsa:MessageID won't help. >> > >> > So we have at least two classifications of failure scenario: >> > >> > transient failures: wsa:MessageID would work and I believe it's the >> > right mechanism to use. >> > >> > crash failures: wsa:MessageID won't work unless we mandate that >> > implementations persist their message structures, which isn't a good >> > idea IMO. Adding a unique participant identification to the >> registration >> > message, as Peter suggests in a different issue, would solve this, but >> > there are other solutions too. The advantage of Peter's option is that >> > it may be needed to resolve another issue. >> > >> > In general, all of our messages are going to have to cope with >> transient >> > failures. So I'd prefer to use wsa:MessageID across the board for >> that. >> >> It all depends on who initiated the retry. If its a transport level >> thing, >> then sure. But if its some layer on top of WSA (like Tx might be >> implemented >> by some) then you can't count on that kind of control. > > You can if we define it within the specification. IMO it makes more > sense to tolerate volatile failures, such as message loss, in this way > simply because we can tackle it once to cover all relevant messages. > Now of course it may not help us in all interactions unless we mandate > wsa:messageID, but that's a separate issue. > > Mark. > >> >> > For crash failures, at least in this case, I'd like to suggest we >> take a >> > look at what we did in WS-CAF with the WS-Coordination Framework >> > specification. There's a recoverParticipant operation that essentially >> > lets you replace one registered EPR with another EPR and returns the >> > protocol-specific EPR that you'd get from register. I think if we're >> > going to tolerate crash failures, and by that I mean try to prevent >> them >> > from aborting/cancelling inflight transactions unnecessarily, we need >> > such a mechanism in general. Of course that could be the scope of a >> > different issue, but I'd rather not solve the crash failure case >> here in >> > an ad hoc manner if we agree that it's something we need to solve more >> > generally. >> > >> > Mark. >> > >> > >> > Doug Davis wrote: >> > >> > > >> > > One thing that concerns me about using the wsa:MessagID is the >> assumption >> > > that you'll use the same messageID on each retry. Can the Tx >> spec really >> > > require this? Other specs (like WSA) which are infrastructural can >> > > probably make >> > > this kind of requirement (if they need to), but I always viewed >> Tx as >> > > sitting on top >> > > of these infrastructural layers and not so much as being part of >> them. >> > > Implementations >> > > will vary on this view but I wouldn't think Tx would want to mandate >> > > this kind of choice. >> > > thanks, >> > > -Doug >> > > >> > > >> > > >> > > *Kevin Conner <Kevin.Conner@jboss.com>* >> > > >> > > 12/12/2005 06:29 PM >> > > >> > > > > To >> > > Christopher B Ferris/Waltham/IBM@IBMUS >> > > cc >> > > Mark Little <mark.little@arjuna.com>, ws-tx@lists.oasis-open.org >> > > Subject >> > > Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse >> retriable >> > > >> > > >> > > >> > > > > >> > > >> > > >> > > >> > > >> > > Christopher B Ferris wrote: >> > > > I'm not sure that using ws-a messageId is the easiest... it >> means that >> > > > impls need to remember messageId >> > > > which can get onerous. >> > > >> > > Something extra will have to be remembered in any case. The >> advantage >> > > of the messageId is that it already has comparison rules which an >> EPR >> > > does not. That is not to say that they can't be compared (see >> below). >> > > >> > > > The WS-A WG avoided the issue of EPR equivalence mostly because of >> > > issues >> > > > related to use of >> > > > EPRs to identify something. IMO, in that spirit, EPR comparison >> becomes >> > > > one of comparing the >> > > > <Address> element which comes down to URI equivalence issues which >> > > can go >> > > > in a number of >> > > > directions... the namespace URI approach (straight string >> > > comparison) or >> > > > the approach which normalizes the URI >> > > > first before comparing. >> > > >> > > The identity associated with an EPR is more than just the address >> > > element though, a comparison will tell you that it uses the same >> > > endpoint but not that the EPRs are identical. For example, we >> add an >> > > instance identifier element which is used by the endpoint to >> identify >> > > the respective instance and multiplex accordingly. >> > > >> > > As far as the current register message is concerned there are three >> > > identifying elements. >> > > - The From (or ReplyTo) EPR >> > > - The ParticipantProtocolService EPR >> > > - The messageID >> > > >> > > The From (or ReplyTo) EPR is unlikely to be unique enough to >> identify >> > > the participant but, even if it was, this would require storing more >> > > than a message id. It would also require rules for EPR comparison. >> > > >> > > The ParticipantProtocolService EPR will uniquely identify the >> > > participant but, once again, requires rules for EPR comparison. >> > > >> > > The message ID should uniquely identify the message exchange but >> within >> > > what context? >> > > >> > > The August 2005 WS-Addressing spec does not define a means of >> comparing >> > > EPRs but it does not prevent it. We have the option to define EPR >> > > structure and/or rules for comparison within WS-C. >> > > >> > > The spec also states that the message ID should be 'an absolute >> URI that >> > > uniquely identifies the message'. What it doesn't state is the >> context >> > > within which this holds true, whether this is intended to be >> global or >> > > within the context of the sender. >> > > >> > > After all this there appear to be three choices >> > > - use the message ID as the identifier and require it to be >> > > globally unique (comparison rules already exist). >> > > - define a structure for the EPRs to make them globally unique >> > > and rules to make them comparable. >> > > - Change the request so that it includes a unique identifier >> associated >> > > with the EPR. >> > > >> > > My initial opinion was that the message ID already does the job >> so why >> > > do we need another mechanism? We could easily use this to handle >> > > retransmission issues. >> > > >> > > Having clarified my thoughts while writing this response I now >> believe >> > > that the second or third choice would be preferable. The only >> question >> > > now would be whether the EPR should remain totally opaque (the last >> > > choice) or whether we should have a mechanism to associate an EPR >> with a >> > > participant (the second choice). >> > > >> > > Kev >> > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]