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

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

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

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

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