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

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

I think we may need to go back to the original, architectural question
here, then revisit the possible mechanisms once we've decided what
should be.

The original question is really in the issue title - phrasing it as a
question:

	should the Register/RegisterResponse exchange be retriable ?

That is to say, should it be possible to resend Register on behalf of a
particular Participant (that is a single state entity responsible for
some part of the work of a transaction) if the RegisterResponse is not
received, with the eventual result being the same [for some sense of
"same"] as if the original RegisterResponse had been received.

A key element of that is that we are discussing the registration of a
single participant state entity, and not cases where a service
deliberately wishes to register multiple participants.

The possibility of a retriable register has scarcely come up in earlier
protocols because they mostly assumed a connection-based carrier or
transport, and were expected to abort a transaction if the connection
failed before the commit decision. (I believe all of LU 6.2 SYNCPT, OSI
CCR/TP, OTS, TIP, OLEtx are expected to be "vulnerable" to connection 
failure - I'm open to correction on some of those).

A feature of being connection-based is that it can be assumed a comms
failure on one side will be (sooner or later) reflected as a failure on
the other side. Thus if 
register (or equivalent) is sent to a coordinator and no reply comes
back there is no point in 
sending another one - either the first one got there, and the reply will
come back, or the connection broke and that is sufficient to cause the
transaction to be aborted anyway. 

But the WS-Tx family aren't connection-based in the same way.  WS-AT
explicitly states (ws-at, line 454) that different connections are used
for messages in each direction. So there isn't a single connection that
everything can pass on, and indeed every message could pass on a
different connection. (further, given the generality of SOAP mappings,
there is no reason to assume that a connection failure is even
detectable by the sender, though in the case of http it would be). The
WS-BA case is even stronger, albeit not in normative text (ws-ba, lines
34-40).

Now you *could* perhaps make a WS-AT implementation that was vulnerable
to connection failure, though I'm not sure it gives any simplification
in the implementation. Interoperation requires that you can cope with
new incoming connections, and ignore the closing of old ones. You could 
monitor your own outbound connections and treat an unintended disconnect
as a reason to abort (if you are still allowed to, of course) but it
would seem to be perverse. (I think the only 
circumstance in which this is allowed is if coordinator sees a comms
failure after sending Prepare - all other messages after the
registration are either recoverable or part of aborting
anyway)


It is against this background that we should consider whether WS-C
should make Register/RegisterResponse retriable. To say that it
shouldn't would seem to be 
deliberatly importing connection-failure vulnerability to an environment
where 
it is no longer needed.

Of course, that's not to say a WS-AT participant-side would be required
to resend Register if it doesn't get a RegisterResponse back (on a
different connection) or doesn't see an http 200 on the outbound
connection. It is impossible to require self-initiated behaviour of a
non-persisted entity (because it can just say "oh, I 
crashed, didn't you notice ?").
 
------------------------
So, back to mechanisms. Can we make Register retriable at reasonable
cost ?

I have yet to see any argument against putting a participant identifier
on the 
Register. Although the coordinator is not allowed test EPRs for
equality, the participant must always be able to extract and combine
various fields that will make an unambiguous identifier (it can do it
other ways too, but the 
EPR must always contain at least sufficient - the problem that disallows
others to test is that it may contain other stuff)

The alternative of trying to make multiple registrations for what is in
fact 
the same participant work would seem to cause considerable
complications. For atomic 
cases, the coordinator may not mind - it just sees two (or more)
registrations and they must both be committed (or rolledback). But Max's

> "The participant
> >simply needs to behave correctly[1] by distinguishing its multiple
> >enlistments.

is very questionable, because it will receive two Prepare's (say), both
delivered 
to the same EPR, but must reply to different coordinator endpoints, one
given on 
the succesful RegisterResponse, one on the lost one. As in Alastair's
diagrams sent earlier today, it would have to use the Reply-To EPR (in
which case, why not use that anyway and get rid of the RegisterResponse
altogether) [this is completely impossible for coordination protocols
where the first message is participant to coordinator - see Alastair's
diagram 3]

Gosh, this has ended up rather long (and will probably now cross with
other messages saying the same thing or rendering it out of date)

Peter

> -----Original Message-----
> From: Mark Little [mailto:mark.little@jboss.com]
> Sent: 15 December 2005 16:50
> To: Max Feingold
> Cc: ws-tx@lists.oasis-open.org
> Subject: Re: [ws-tx] Issue 007 - WS-C: Make 
> Register/RegisterResponse retriable
> 
> 
> 
> 
> Colleen Evans wrote:
> 
> >Forwarding for Max.
> >Colleen
> >
> >-----Original Message-----
> >From: Max Feingold
> >Sent: Wednesday, December 14, 2005 6:22 PM
> >To: ws-tx@lists.oasis-open.org
> >Subject: RE: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse

> >retriable
> >
> >After digesting this week's discussion on this topic, I have a few
> >observations:
> >
> >- I cannot think of a protocol that requires idempotent
> registration.
> >WS-AT certainly does not need it.  A conformant WS-AT
> participant might
> >only send a single Register message and report failure to the
> >registrant if a timeout or comms failure occurs.  It can also send 
> >multiple Register messages.  The coordinator will create a new 
> >participant enlistment for each Register it receives.  The 
> participant
> >simply needs to behave correctly[1] by distinguishing its multiple
> >enlistments.
> >  
> >
> You're right. OTS, for example, doesn't place a restriction on
> participant registration either. Speaking purely about transactions, 
> with the exception of the Activity Service, I'm not sure of a 
> protocol 
> that prevents multiple registrations. If we say that the 
> operation isn't 
> idempotent, then we definitely need to remove the fault 
> message though, 
> in case retransmissions are attempted for failure situations.
> 
> >- One can imagine that different coordination types might have
> >different expectations for what it means to send multiple 
> (duplicate)
> >Register messages.  Given that Register is scoped to a specific
> >coordination type at both the participant and the coordinator, it is 
> >not clear that the semantics of Register can (or should) be 
> universally
> >constrained to a single pattern.
> >  
> >
> I'm happy to punt this up to referencing specifications.
> 
> >- A hypothetical coordination protocol that wants to detect
> duplicates
> >should not overload existing WS-Addressing mechanisms.  Instead, it
> >should use WS-C extensibility to create specific participant 
> >identifiers.  Some protocols may need this functionality for 
> >correctness.  I do not believe that any of the WS-Tx 
> protocols need it.
> >  
> >
> If we don't try to detect duplicate enlistments at this
> level, then we 
> also get round the need for EPR comparisons and don't need to 
> add a new 
> participant URI to register either.
> 
> Mark.
> 
> >...
> >
> >[1] "Correctly" here means not splitting the transaction
> tree.  I can
> >follow up on this if people are interested in the details.
> >
> >-----Original Message-----
> >From: Peter Furniss [mailto:peter.furniss@choreology.com]
> >Sent: Friday, December 09, 2005 9:54 AM
> >To: ws-tx@lists.oasis-open.org
> >Subject: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse 
> >retriable
> >
> >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-Co
ordination
> >-
> >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]"
> > 
> > 
> >
> >
> >  
> >
>