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

[Doug Davis <dug@us.ibm.com>]

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