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

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

I disagree that we should preserve the
fault. It doesn't relate back the CoordinationProtocolService
EPR and hence actually has less information
than a RegisterResponse message.

IMO, the fault should be eliminated
and the operation be made idempotent on its own merits, e.g.
without requiring that the sender use
the same wsa:MessageId as any previous transmissions
of the Register message.

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

"Sazi Temel" <sazi@bea.com> wrote
on 12/13/2005 02:36:35 AM:

> Agreed with making Register idempotent; and once the Register 
> idempotent “Already registered” is not a fault anymore, it is just
a
> status/info back to registrant -  IMO it better then replying
with 
> another “Registered” message, carries a bit more info back to registrant.
>  
> .Sazi
>  
> 
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: Monday, December 12, 2005 1:43 PM
> To: Mark Little
> Cc: ws-tx@lists.oasis-open.org
> Subject: Re: [ws-tx] Issue 007 - WS-C: Make 
> Register/RegisterResponse retriable
>  
> 
> 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]"
> >>
> >>
> >>
> >>  
> >>
> >