Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable

[Mark Little <mark.little@jboss.com>]

Doug, I thought that was still an ongoing discussion in the TC? If it 
was resolved, then maybe we should be looking at a similar solution here 
then?

Mark.


Doug Davis wrote:

>
> Mark - double check the RX specs - they _don't_ say anything about 
> messageID.
> And this was done on purpose.  WSA owns that field and applying any 
> semantics beyond
> what WSA says is a bad idea. That's why RX defined their own way to 
> uniquely identify
> a message that didn't include WSA msgID.
> thanks,
> -Doug
>
> Mark Little <mark.little@jboss.com> wrote on 12/13/2005 08:34:14 AM:
>
> >
> >
> > 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
> > > > >
> >