OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-tx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-tx] Issue 007 - Revised proposed resolution


The current discussion on 007 has led me to think that the proposed 
resolution I put forward is too narrow.

It would be odd (but legitimate) for a Coordinator to give back a 
different P-to-C EPR when it replays RegisterResponse. If the R/RR 
exchange is replayed then the Participant may have moved, and the 
Coordinator may decide to change its view of which address should handle 
it also.

So both sides should treat the exchange as brand new.

If they both know that they are dealing with the same Participant (it 
has a common identity) then they can swap their internal mappings 
without breaking the transaction tree apart.

This is a strong argument for separating the Participant identity from 
the EPR. The EPR can shift, but the identity does not.

In addition, we need to clearly state when this exchange ends, and 
ceases to be a legitimate activity.

My revised proposed resolution to Issue 007 (R/RR retriable) (which now 
rests on there being a Participant identifier), would therefore read:

Revised 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, 
with the same Participant identifier as a Register message which has 
already been processed successfully (providing that no coordination 
protocol messages have yet been received from the Participant 
concerned), the Registration Service MUST replace its previous record of 
the /Register/ParticipantProtocolService (Endpoint Reference for 
Coordinator to Participant protocol messages) with the value of that 
element in the newly received Register message, and it MUST send to the 
requester a RegisterResponse. The RegisterResponse may contain a 
CoordinationProtocolService element (Endpoint Reference for Participant 
to Coordinator protocol messages), whose value is the same or different 
from those of that element contained in any previous RegisterResponses 
generated by the Registration Service which relate to the identified 
Participant's request to register for this activity.
"If a Register message is received from a Participant which has already 
sent a coordination protocol message to the Endpoint Reference which is 
the value of the /RegisterResponse/CoordinationProtocolService element 
contained in a RegisterResponse message sent before the receipt of the 
Register message, then the Registration Service MUST send an Invalid 
State fault to the requester.
[New paragraph]"

It would also make sense to choose to send an Already Registered fault 
in this latter circumstance (mutatis mutandis in terms of fault 
definition), but this is really no different from the invalid state 
cases that occur in WS-AT and WS-BA, so I would suggest we proceed with 
eliminating Already Registered.

An alternative to this rather cumbersome wording would be to introduce a 
small state table, but that might well be overkill for such a simple 
state machine.

Alastair





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]