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

[Christopher B Ferris <chrisfer@us.ibm.com>]

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