Mark/Doug,
I suspect some tooling and the WS-A spec coincide in frowning upon
constraints over message id values (like imposing same values over a
sequence of retries).
They are meant to be unique per message, and doubtless some layered-off
WS-A implementations take that seriously: they generate an id every
time WS-A is used in formulating a message.
The WS-A spec may not say much about message ids, but it says enough
for my liking:
1) You don't have to have a message id. Nota bene.
2) If you do it's supposed to be unique per message.
We should use retries with enough identity in the EPR or the message at
the TX level to allow dup elimination. Same principle as other
duplicate-eliminating exchanges in these specs.
Alastair
Doug Davis wrote:
Mark Little <mark.little@jboss.com> wrote on
12/13/2005 08:40:19 AM:
>
>
> Doug Davis wrote:
>
> >
> > See http://wsi.alphaworks.ibm.com:8080/interop/index.html
> >
> > I don't see any mandate that msgID be the same on retries,
nor
do the
> > Tx specs say that.
>
> You're right: one was an implementation choice and the other is
what
> causes the issue Alastair raised ;-)
>
> > This becomes an implementation issue. If your Tx code is very
close to
> > your WSA code then
> > its very possible that a retry of a Tx message (resent by Tx
logic and
> > not WSA or transport
> > logic) could have the same msgID. However, that's an
implementation
> > choice. Some may
> > view Tx as a layer on top of WSA and therefore when Tx
initiated
the
> > resend it may not have
> > control over the msgID - it is delegated to WSA.
>
> Agreed, but I'm trying to stay clear of implementation. We can say
> within the specification that retries of protocol messages MUST
use
the
> same wsa:messageID. How that happens is an implementation choice.
We may
> want to define this only on some message interactions, but that's
secondary.
I agree we don't want to mandate an implementation
choice - so keep in mind
that not all Tx implementations have control over
WSA'a msgID. So, while
technically I agree with you that Tx _can_ mandate
the same msgID I think
that's mandating an implementation choice - which
would be bad.
> > In this case however we're talking about
retry of a Register which I
> > don't believe was
> > even part of the interop event.
>
> We were, but I'd taken the leap that if it's a problem in one
case,
it
> may be a problem elsewhere and if we can fix it once "for all
time" then
> we should.
Maybe. Some of the retries can be done at the
Tx spec level (like what to
do for dup Prepares regardless of the WSA value),
and the Tx spec does
cover this already. I believe that Register
is a bit of a different beast
since I don't think its as easy to represent it in
the state tables
w/o getting into dup msg detection. Dup-Prepares
didn't need that kind of
logic.
> > And in this case its not clear if we're talking about a Tx
> > initiated retry or a transport-level retry. If its Tx then
I don't
> > believe the spec can mandate
> > anything about the msgID (see above).
>
> I think it can. See WS-RX for examples - you were involved with
them
;-)
RX avoided this.
> > If its a transport level retry then I'm wondering
> > where did that retry logic come from since all I see below Tx
is WSA
> > and SOAP and neither
> > of those require a retry and therefore the retry semantics
(if
any)
> > are non-interoperable/undefined.
>
>
> Mark.
>
> >
> > thanks,
> > -Doug
> >
> >
> >
> > *Mark Little <mark.little@jboss.com>*
> >
> > 12/13/2005 07:12 AM
> >
> >
> > To
> > Doug Davis/Raleigh/IBM@IBMUS
> > cc
> > ws-tx@lists.oasis-open.org
> > Subject
> > Re: [ws-tx] Issue 007 - WS-C: Make
Register/RegisterResponse
retriable
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Doug, one of us is remembering incorrectly and without access
to the doc
> > I can't say who yet.
> >
> > Mark.
> >
> >
> > Doug Davis wrote:
> >
> > >
> > > Mark,
> > > If I'm remembering correctly the retries didn't
require
the
> > > wsa:messageID to be
> > > the same each time. The duplicate detection was done
at the tx
> > > protocol level
> > > not at the WSA level - meaning the protocol knew how to
deal with
> > > multiple
> > > Prepare messages - not multiple messages with the same
msgID.
Those are
> > > two very different things.
> > > thanks
> > > -Doug
> > >
> > >
> > >
> > > *Mark Little <mark.little@jboss.com>*
> > >
> > > 12/13/2005 05:36 AM
> > >
> > >
> > > To
> > >
ws-tx@lists.oasis-open.org
> > > cc
> > >
> > > Subject
> > >
Re: [ws-tx] Issue 007 - WS-C: Make
> > Register/RegisterResponse retriable
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > BTW, to your point of ease: the interop scenarios we had
to do in
> > > January/February this year had many situations requiring
timeouts and
> > > retries. I certainly can't say I canvased everyone
present,
but I didn't
> > > get the impression that that aspect was considered too
much
of an
> > > implementation headache.
> > >
> > > Mark.
> > >
> > >
> > > 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.
> > > >>>>
> > > >>>> 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.
> > > >>>>
> > > >>>> 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@arjuna.com>
wrote on 12/12/2005
> > 03:20:16 PM:
> > > >>>>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >>>>>>> > There are multiple
ways
of making the operation idempotent.
> > > Using WS-A
> > > >>>>>>> > semantics is one and
IMO
is probably the easiest way of
> > > doing it: it
> > > >>>>>>> > goes back to
traditional
Retained Results RPC mechanisms of
> > > the late
> > > >>>>>>> > 1980's, where
idempotency
was imposed at the comms level. If
> > > we try to
> > > >>>>>>> > do it higher up the
stack,
within the actual implementation,
> > > then we're
> > > >>>>>>> > going to have to
address
the issue of EPR comparisons: how
> > > can I ensure
> > > >>>>>>> > this is the same
operation
if I can't determine that the
> > > parameters are
> > > >>>>>>> > identical?
> > > >>>>>>> >
> > > >>>>>>> > So, I think we're
agreed
that it needs to be idempotent. But
> > > >>>>>>> > until/unless we
address
EPR comparisons, I think the WS-A
> > > retry route
> > > >>>>>>> > gets my vote.
> > > >>>>>>> >
> > > >>>>>>> > Mark.
> > > >>>>>>> >
> > > >>>>>>> >
> > > >>>>>>> > Christopher B Ferris
wrote:
> > > >>>>>>> >
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>
> > > >>
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > > That
is one way, the other is to make the Register
> > > message idempotent.
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > > Seems
to me that Register SHOULD be idempotent. It is
> > > much simpler to
> > > >>>>>>>>>> > >
simply
process
> > > >>>>>>>>>> > > the
Register
as if it had never been received...
> > makes the
> > > >>>>>>>>>> > >
implementation
of the client
> > > >>>>>>>>>> > > a bit
simpler.
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > > I
also think that the "AlreadyRegistered" fault is
> > > probablematic. It
> > > >>>>>>>>>> > >
doesn't
reflect
> > > >>>>>>>>>> > > back
the CoordinationProtocolService EPR that the
> > > RegisterResponse
> > > >>>>>>>>>> > >
message
does.
> > > >>>>>>>>>> > > So,
from
the perspective of the registrant, it ISN'T
> > > registered if it
> > > >>>>>>>>>> > >
doesn't
receive the
> > > >>>>>>>>>> > >
RegisterResponse
message since it doesn't know the
> > > >>>>>>>>>> > >
CoordinationProtocolService
> > > >>>>>>>>>> > > EPR.
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > > From
the perspective of the registration service,
> > > overlaying the
> > > >>>>>>>>>> > >
previous
registered
> > > >>>>>>>>>> > > EPR
is
effectively an idempotent operation, and the
> > > response can be
> > > >>>>>>>>>> > > the
same
as if
> > > >>>>>>>>>> > > it
didn't
have the registration beforehand.
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > > IMO,
making the operation idempotent makes the
> > > implementation much
> > > >>>>>>>>>> > >
simpler
and
> > > >>>>>>>>>> > > more
robust in the long run.
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
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>*
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
12/12/2005
11:36 AM
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > > To
> > > >>>>>>>>>> > >
ws-tx@lists.oasis-open.org
> > > >>>>>>>>>> > > cc
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
Subject
> > > >>>>>>>>>> > >
Re: [ws-tx] Issue 007 - WS-C: Make
> > > Register/RegisterResponse
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>
> > > >>>
> > > >>>> retriable
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
Actually
I'll retract this. As Kevin just reminded me,
> > > we're using
> > > >>>>>>>>>> > >
WS-Addressing
anyway, so surely lost messages and
> > > retries can be coped
> > > >>>>>>>>>> > > with
at that level: using the same wsa:MessageID for
> > > example, should
> > > >>>>>>>>>> > > sort
this.
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > > Mark.
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > >
> > > >>>>>>>>>> > > Mark
Little wrote:
> > > >>>>>>>>>> > >
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>
> > > >>>
> > > >>>>>>>>>>>>>
>
> > I think this makes proposal makes sense.
> > > >>>>>>>>>>>>>
>
> >
> > > >>>>>>>>>>>>>
>
> > Mark.
> > > >>>>>>>>>>>>>
>
> >
> > > >>>>>>>>>>>>>
>
> >
> > > >>>>>>>>>>>>>
>
> > Peter Furniss wrote:
> > > >>>>>>>>>>>>>
>
> >
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>
> > > >>>>
> > >
>>>>>>>>>>>>>>>>
> > >> This is hereby declared to be ws-tx Issue 007.
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Please follow-up to this message or ensure the
> > > subject line starts
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>>>>> > > Issue
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>
> > > >>>
> > >
>>>>>>>>>>>>>>>>
> > >> 007 - (ignoring Re:, [ws-tx] etc)
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> The Related Issues list has been updated to
> > > show the issue numbers.
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Issue name -- WS-C: Make
> > > Register/RegisterResponse retriable
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Owner: Alastair Green
> > > [mailto:alastair.green@choreology.com]
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Target document and draft:
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Protocol: Coord
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Artifact: spec
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Draft: Coord spec working draft uploaded
> > > 2005-12-02
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Link to the document referenced:
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>>>>> > >
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>
> > > >>>
> > > >>>>
> > >
http://www.oasis-open.org/committees/download.php/15738/WS-Coordination-
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> 2005-11-22.pdf
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Section and PDF line number:
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> WS-Coordination spec, Section 3.2
> > > "Registration Service" l. 294
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Issue type: Design
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Related issues:
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Issue 008 - WS-C: Remove fault 4.6
> > > AlreadyRegistered
> > >
>>>>>>>>>>>>>>>>
> > >> Issue 014 - WS-C: EPR equality comparison is
> > > problematic Issue
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> 009 -
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> WS-C/WS-AT: Is request-reply MEP useful?
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Issue Description:
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Register/RegisterResponse should be retriable
> > > exchange
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Issue Details:
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> [This issue stems from Choreology Contribution
> > > issue TX-20.]
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Section 9 of WS-AT defines the WS-Coordination
> > > exchanges
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
CreateCoordinationContext/CreateCoordinationContextResponse
> > >
>>>>>>>>>>>>>>>>
> > >> Register/RegisterResponse
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> as request-reply exchanges.
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> (Whether this request reply MEP should be used
> > > at all in the WS-TX
> > >
>>>>>>>>>>>>>>>>
> > >> specs is addressed in a separate issue: see
> > > "Issue 009 -
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> WS-C/WS-AT:
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> Is request-reply MEP
> > >
>>>>>>>>>>>>>>>>
> > >> useful?".)
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Substantively, it may be particularly
> > > misleading to think of the
> > >
>>>>>>>>>>>>>>>>
> > >> Register/RegisterResponse
> > >
>>>>>>>>>>>>>>>>
> > >> exchange as a request-reply pattern. The
> > > implication of using this
> > >
>>>>>>>>>>>>>>>>
> > >> pattern is that there is a simple one message
> > > in, one message out
> > >
>>>>>>>>>>>>>>>>
> > >> exchange. The presence of a fault
> > >
>>>>>>>>>>>>>>>>
> > >> (AlreadyRegistered) as a potential response to
> > > Register hardens
> > >
>>>>>>>>>>>>>>>>
> > >> that implication.
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Current behaviour would lead to service being
> > > informed it has
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> already
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> registered a
> > >
>>>>>>>>>>>>>>>>
> > >> Participant, when it has in fact simply
> > > succeeded in registering a
> > >
>>>>>>>>>>>>>>>>
> > >> Participant. Superficially, the
> > >
>>>>>>>>>>>>>>>>
> > >> AlreadyRegistered fault could simply be
> > >
>>>>>>>>>>>>>>>>
> > >> viewed as being unnecessarily verbose: the
> > > reaction of the
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> service to
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> the fault at run-time must be to treat
> > >
>>>>>>>>>>>>>>>>
> > >> it as uninteresting, i.e. as equal in effect
> > > to a successful
> > >
>>>>>>>>>>>>>>>>
> > >> registration.
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> In fact there is a deeper problem. Consider
> > > the following scenario:
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> A Coordination Service (CS) creates a
> > > Coordinator (C) for a new
> > >
>>>>>>>>>>>>>>>>
> > >> atomic transaction (AT), and emits a
> > > CoordinationContext (CC).
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> The CC is transmitted to an application
> > > service (AS). AS
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> (logically)
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> creates a P which sends Register (R) to the
> > > Registration
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> Service (RS)
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> EPR for AT, embedding the EPR for receipt
> > >
>>>>>>>>>>>>>>>>
> > >> of protocol messages outbound from C to P (CP
> > > EPR).
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> The RS, on receiving Register, creates an EPR
> > > for inbound protocol
> > >
>>>>>>>>>>>>>>>>
> > >> messages from P to C (PC EPR), and embeds this
> > > in the
> > >
>>>>>>>>>>>>>>>>
> > >> RegisterResponse (RR), which it sends to P.
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> AS and P crash before the RR message is
> > > received by P, or the RR
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>>>>> > >
message
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>
> > > >>>
> > >
>>>>>>>>>>>>>>>>
> > >> drops and is never received by P. Either way,
> > > AS (on recovery,
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> or after
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> waiting) causes P to resends R to RS. RS
> > > examines the inbound
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> Register,
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> and determines that it has come from a known P
> > > (see "Related
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > >
>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> Issues",
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> "WS-C: EPR equality comparison should
> > >
>>>>>>>>>>>>>>>>
> > >> not be relied upon"), i.e. that it is a
> > > duplicate registration.
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Currently, RS replies with an
> > > AlreadyRegistered fault, sent to P. P
> > >
>>>>>>>>>>>>>>>>
> > >> now knows that he is registered with C, but
> > > has never received
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> the PC
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> EPR
> > > (/RegisterResponse/CoordinationProtocolService element).
Any
> > >
>>>>>>>>>>>>>>>>
> > >> further retries of P send R to C will result
> > > in the same situation.
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> C will never be able to receive messages from
> > > P. P will never
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> become
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> Prepared. The transaction will eventually
> > > collapse through timeout.
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Therefore, the Register/RegisterResponse
> > > exchange must tolerate
> > >
>>>>>>>>>>>>>>>>
> > >> duplicates. If a Register message is delivered
> > > more than once
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> (either
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> by the transport, or through comms-failure- or
> > > recovery-induced
> > >
>>>>>>>>>>>>>>>>
> > >> retry) then the Registration Service should
> > > respond on each
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> occasion
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> with a RegisterResponse containing the same PC
> > > EPR, to ensure
> > >
>>>>>>>>>>>>>>>>
> > >> reliable completion of the EPR exchange that
> > > permits the subsequent
> > >
>>>>>>>>>>>>>>>>
> > >> coordination protocol to operate correctly.
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> NOTE.
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> This change brings the R/RR exchange in line
> > > with the behaviour of
> > >
>>>>>>>>>>>>>>>>
> > >> the CreateCoordinationContext/...Response
> > >
>>>>>>>>>>>>>>>>
> > >> exchange. There is a difference. R/RR is
> > > likely to be
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> implemented as
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> a true idempotent operation. CCC/CCCR is
> > >
>>>>>>>>>>>>>>>>
> > >> not: each CCCR embeds a new RS EPR, and a new
> > > /Context/Identifier.
> > >
>>>>>>>>>>>>>>>>
> > >> But each exchange can be harmlessly
> > >
>>>>>>>>>>>>>>>>
> > >> replayed indefinitely, in the event of failure
> > > to receive the
> > >
>>>>>>>>>>>>>>>>
> > >> response message.
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Proposed Resolution:
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> Insert the following text in WS-Coordination
> > > spec, Section 3.2
> > >
>>>>>>>>>>>>>>>>
> > >> "Registration Service" immediately following
> > > current l. 294
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >> "[New paragraph]The requester MAY send a
> > > Register message for a
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> given
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> Participant more than once, and the underlying
> > > transport could
> > >
>>>>>>>>>>>>>>>>
> > >> deliver the Register message more than once.
> > >
>>>>>>>>>>>>>>>>
> > >> On receipt of a Register message for a
> > >
>>>>>>>>>>>>>>>>
> > >> given Participant, which has already been
> > > processed
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> succesfully, the
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> Registration Service MUST send to the
> > >
>>>>>>>>>>>>>>>>
> > >> requester a RegisterResponse containing the same
> > >
>>>>>>>>>>>>>>>>
> > >> CoordinationProtocolService element (Endpoint
> > > Reference for
> > >
>>>>>>>>>>>>>>>>
> > >> Participant to Coordinator protocol messages)
> > > as that contained in
> > >
>>>>>>>>>>>>>>>>
> > >> all previous RegisterResponses generated by
> > >
>>>>>>>>>>>>>>>>
> > >> the Registration Service which relate to the
> > > Participant's
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> request to
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
>>>>>>>>>>>>>>>>
> > >> register for this activity.
> > >
>>>>>>>>>>>>>>>>
> > >> [New paragraph]"
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >>
> > >
>>>>>>>>>>>>>>>>
> > >>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>>>>>>>>
>
> >
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>
> > > >>>>
> > > >>>>>>>>>> > >
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>
> > > >>>
> > >
> >
|