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