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

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

Andrew,

I think your description of the behaviour is accurate.

However, to require that the spec forbids resending register is to make
*all* WS-C-using protocols "vulnerable" to transport glitches (or,
strictly,
all such that don't extend WS-C with their own duplicate detection
mechanism) 

That is clearly a choice for this TC.  It is another way of putting the
question of this issue.

The question is not whether the resulting specification is
interoperable, but
whether it is useful in real situations. Since WS-BA is intended to be 
highly resilient to such failures later on, it would seem perverse to
to make it vulnerable at this point.  Customers will surely complain if
there
is a mysterious window of failure that occasionally trips up their
processes, 
and forces them into exception handling, especially if they find out
why.

Peter



> -----Original Message-----
> From: Andrew Wilkinson3 [mailto:awilkinson@uk.ibm.com] 
> Sent: 19 December 2005 10:17
> To: Alastair Green
> Cc: Ian Robinson; Mark Little; 'Max Feingold'; Peter Furniss; 
> ws-tx@lists.oasis-open.org
> Subject: Re: [ws-tx] Issue 007 - WS-C: Make 
> Register/RegisterResponse retriable
> 
> 
> Alastair,
>  
> > So, introducing participant identifiers will resolve both Issue 007
> > and Issue 014. 
> > 
> > It is a more elegant approach that does not create forced
> > implementation choices that are required to work around its absence 
> > for the duplicate registration problem. It is the only solution that
> > will make BA MixedOutcome or BA Participant Completion registration 
> > workable (at least, the only one thus far proposed).
> 
> I believe that it is possible to create an interoperable 
> implementation of 
> BA Participant Completion without being able to detect duplicate 
> registrations. In the event of a coordinator receiving two register 
> messages for the same participant, either because the 
> register was retried 
> or the transport delivered the message twice, it will expect 
> the receipt 
> of two completed messages. Should one of these messages not 
> be forthcoming 
> the coordinator may opt to complete in failure - sending 
> cancel to the 
> participant from which it has not received a completed message and 
> compensate to the one from which such a message has been received.
> 
> Assuming that the participant implementation has been coded 
> such that it 
> does not retry sending of a register message (and we could 
> mandate this in 
> the spec if needed) what we're coping with here is an error in the 
> transport and, as such, completing in failure is entirely 
> appropriate. 
> What's important is that the outcome is consistent and I 
> believe that the 
> BA state table ensures that this will be the case.
> 
> Andy
>