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

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

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
> > >