ws-tx message

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

From: Doug Davis <dug@us.ibm.com>
To: ws-tx@lists.oasis-open.org
Date: Tue, 13 Dec 2005 05:11:57 -0700

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

Follow-Ups:
- Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable
  - From: Kevin Conner <Kevin.Conner@jboss.com>
- Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable
  - From: Mark Little <mark.little@jboss.com>

References:
- Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable
  - From: Mark Little <mark.little@jboss.com>