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

["Peter Furniss" <peter.furniss@choreology.com>]

It isn't necessary to dig into EPR equality if the first solution
proposed for 014 is applied -
add a participant identifier to the Register message. This moves the
identification of the participant
into our protocols, leaving WS-A to get messages to the right place as
intended. As explained in 
014, such an identifier is essential for WS-BA MixedOutcome at least,
and likely useful for other
coordination protocols. It would mean there is an identifier exchange
between coordinator and participant, 
(since the context carries an identifier already), distinct from the EPR
exchange. Which also means the 
relationship can be unambiguously identified from either side.

Peter




> -----Original Message-----
> From: Mark Little [mailto:mark.little@jboss.com] 
> Sent: 12 December 2005 20:27
> To: Christopher B Ferris
> Cc: Mark Little; ws-tx@lists.oasis-open.org
> Subject: Re: [ws-tx] Issue 007 - WS-C: Make 
> Register/RegisterResponse retriable
> 
> 
> I'm no sure if this got through first time.
> 
> I agree that the operation needs to be idempotent. There are 
> a couple of 
> ways we could do that, and the WS-A suggestion is just one, 
> which goes 
> back to the retained results functionality of some RPC 
> mechanisms from 
> the late 1980's: deal with it at the comms level, so the application 
> doesn't have to see the retries. The advantage of this 
> approach is that 
> it doesn't require any semantic information about the operation - 
> relying entirely on the message sequence numbers. If we try the other 
> way of making the operation idempotent, then we'll need to 
> address the 
> EPR equality issue that Alastair raised as well: how can an 
> implementation ensure that the operation is idempotent if it can't 
> determine that the parameters are identical?
> 
> So, I think we're agreed that the operation needs to be 
> idempotent. But 
> in the absence of solving EPR equality, the WS-A approach 
> 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-Coordinatio
> > n-
> > >> 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]"
> > >>
> > >>
> > >>
> > >>  >>
> > >
> >
>