ws-tx message
[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
- From: Doug Davis <dug@us.ibm.com>
- To: ws-tx@lists.oasis-open.org
- Date: Tue, 13 Dec 2005 08:55:17 -0500
I don't think it is still open - no
issue for it anyway.
RX resolved it by defining its own mechanism
- one option is for Tx to do the same.
Peter ( I think ) proposed a new Tx
specific ID - that might the right approach - need to think
more about it.
-Doug
Mark Little <mark.little@jboss.com> wrote on
12/13/2005 08:42:00 AM:
> 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
> > > > > >
> > >
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]