Agreed with making Register idempotent;
and once the Register idempotent “Already registered” is not a
fault anymore, it is just a status/info back to registrant - IMO it better
then replying with another “Registered” message, carries a bit more
info back to registrant.
.Sazi
From: Christopher B
Ferris [mailto:chrisfer@us.ibm.com]
Sent: Monday, December 12, 2005
1:43 PM
To: Mark Little
Cc: ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 007 -
WS-C: Make Register/RegisterResponse retriable
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]"
>>
>>
>>
>>
>>
>