[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
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. 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. 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]