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: Christopher B Ferris <chrisfer@us.ibm.com>
- To: ws-tx@lists.oasis-open.org
- Date: Tue, 13 Dec 2005 09:51:46 -0500
Mark writes:
"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."
Not so. Per the resolution to wsrx:i004 [1], the WS-RX
TC took exactly
the opposite position, that the RM spec makes NO claims
on whether or
not the wsa:MessageId will be the same on retransmitted
messages.
This resolution argues exactly the opposite, that
it is not within
WS-RM, or any other, spec's prerogatives to change
the semantics of another
spec as that can have significant implications for
composability.
[1] http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i004
Cheers,
Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295
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]