[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable
Very useful to tease these things out. I wasn't at the interop workshop,
but I have a dim memory that this "two ways of doing the same thing"
actually did come up and that they may have been adaptive evolution
towards allowing both to work. If so, then I think this discussion helps
clarify which one is the preferred route.
Alastair
Mark Little wrote:
> Alastair, thanks. I think we've already shown that my recollection of
> the interop. scenarios was wrong ;-)
>
> Mark.
>
>
> Alastair Green wrote:
>
>> Mark,
>>
>> I feel we should be careful about this. I'm sorry, but I'm not smart
>> enough to write you a short letter on this subject. Hopefully someone
>> else will come up with a more succinct way of expressing what follows.
>>
>> The only message exchanges defined to use reply-response and
>> therefore to mandatorily use message id/relates-to in the current
>> specs (WS-AT specifically) are CCC/CCCR, and R/RR. These exchanges
>> are not currently designed to act in an idempotent manner. Indeed, a
>> conformant January 2005 implementation must have responded to a
>> duplicate Register with a Fault/AlreadyRegistered, i.e. behaved
>> non-idempotently, and the issue of retry cannot therefore have arisen.
>>
>> Any retry behaviour in a Jan 2005 implementation that relied upon
>> id/relates-to correlation for /any other exchange /(e.g. the 2PC
>> exchanges) cannot have been interoperable other than by accident or
>> by excessive latitude on the part of its interlocutors.
>>
>> The initiator of an exchange cannot be relied upon to supply message
>> id, and the responder cannot be relied upon to specify the
>> correlation via relates-to, because nothing in the WS-A or WS-TX
>> specs mandates such elements to be present.
>>
>> Indeed, and this goes to the root of the whole discussion, the only
>> way that retriable exchanges were and are possible for e.g. 2PC
>> exchanges, is that the retry was identified as new, or as duplicate
>> (i.e. state-changing or non-state-changing) by virtue of the deemed
>> identity of the message sender. And in WS-TX protocols, that identity
>> is encoded in the EPRs exchanged during registration.
>>
>> This is not a problem, because (/given appropriate
>> Register/RegisterResponse exchanges/) identity comparison is not
>> required for subsequent coordination protocol exchanges.
>> Identification of state can be handled by mapping from an EPR to its
>> associated state. The state machine governs duplicate processing, for
>> any number of retries.
>>
>> Example. Coordinator C for transaction T, Participant P.
>>
>> C emits RS EPR in *CoordinationContext*. P stores RS EPR, keyed by
>> context /Identifier (a unique id for T).
>>
>> P generates C-to-P EPR (EPR for inbound-toParticipant coord protocol
>> messages). P stores CP EPR, which is a unique identifier for the
>> tuple {P, T}, i.e. this Participant for this Transaction, and ensures
>> that the state of {P,T} is accessible, given the value of CP EPR.
>>
>> P sends *Register* to RS EPR, embedding CP EPR.
>>
>> C generates P-to-C EPR (for inbound-to-Coordinator coord protocol
>> messages), and stores CP EPR, keyed by new PC EPR.
>>
>> C sends *RegisterResponse* to P, embedding PC EPR. P stores PC-EPR,
>> keyed by CP-EPR.
>>
>> Coord protocol messages flow. Assume *Prepare/Prepared *(retriable
>> exchange).
>>
>> *Prepare* sent first time to CP EPR. P checks state for that EPR,
>> i.e. for {P, T}, logs, changes state, looks up PC EPR and sends
>> *Prepared* to PC EPR.
>>
>> *Prepared* drops (is not received by C).
>>
>> Retry: *Prepare *sent second time to CP EPR. P uses CP EPR to find
>> state of {P, T}, finds it is Prepared, looks up PC EPR and resends
>> *Prepared* to PC EPR.
>>
>> You can flip this around with BA *Exit/Exited*, if you want to see
>> initiator and responder roles reversed between C and P.
>>
>> Generalizing, for Initiator I and Responder R (which must recognize
>> duplicates).
>>
>> I generates RI EPR, which identifies state of I for R, and stores IR
>> EPR, keyed by its generated RI EPR.
>>
>> R generates IR EPR, which identifies state of R for I, and stores RI
>> EPR, keyed by its generated IR EPR
>>
>> I sends one or more messages to IR EPR (address of R for this exchange)
>>
>> R figures out if message n is a duplicate by checking state of R for
>> I, identified by IR EPR, and then looks up RI EPR using IR EPR as
>> key, to send reply to RI EPR
>>
>> I figures out if message m is already processed by checking state of
>> I for R, identified by RI EPR, etc etc.
>>
>> /Note that there is not a message id in sight.
>> /
>> [The whole of the scheme above, which I believe to be the spec
>> author's design intent, depends on preventing duplicate registrations
>> of P, i.e. C must never have two PC EPRs which it treats as distinct
>> for one P. Back to how to prevent duplicate registrations, on which a
>> separate post.]
>>
>> If the spec authors' intent was to allow two separate parallel
>> mechanisms for identifying actors in such retriable exchanges then
>> they should have explicitly stated that every message has an id, and
>> every reply has a relates-to=<that id>. This is not stated in WS-AT
>> Section 9, and I therefore believe any implementation that relied
>> upon that scheme was interoperable by accident or by private
>> contract, but not by spec conformance.
>>
>> Let us imagine that we do adopt the id/relates-to approach as a
>> result of this discussion. We now have a situation where every
>> exchange has an id. This id must be retained for all retries. This is
>> at least contrary to the spirit of WS-A, if not provably illegal. The
>> message is supposed to be uniquely identified by the id, as I read
>> the WS-A spec:
>>
>> [message id] : IRI (0..1)
>>
>> An absolute IRI that uniquely identifies the message. When
>> present, it is the responsibility of the sender to ensure that
>> each message is uniquely identified. The behavior of a receiver
>> when receiving a message that contains the same [message id] as a
>> previously received message is unconstrained by this specification.
>>
>> This does not seem a good route to follow. Unintentional duplication
>> (more than once delivery by the transport) is one thing; deliberately
>> sending duplicates with the same message ids seems wrong-headed.
>>
>> Finally, why have two ways of doing the same thing? No-one is
>> suggesting we remove EPRs, and they provide a sufficient mechanism in
>> all cases of retriable idempotent messages, except the
>> Register/RegisterResponse exchange, which require additional identity
>> to /correctly form /the bridge or channel. To interoperate two
>> completely different ways cannot be good practice, and certainly
>> complicates implementation and interoperability testing. This is the
>> danger of defining conformance as equalling a 5 x 5 matrix "worked"
>> for 5 implementations. If they all evolve to handle all variants then
>> they can evolve away from the spec and the design intent. A
>> non-conformant feature can spread by excessive tolerance.
>>
>> Alastair
>>
>> Mark Little wrote:
>>
>>> BTW, to your point of ease: the interop scenarios we had to do in
>>> January/February this year had many situations requiring timeouts
>>> and retries. I certainly can't say I canvased everyone present, but
>>> I didn't get the impression that that aspect was considered too much
>>> of an implementation headache.
>>>
>>> Mark.
>>>
>>>
>>> Christopher B Ferris wrote:
>>>
>>>
>>>
>>>>>>>
>>>>>>> I'm not sure that using ws-a messageId is the easiest... it
>>>>>>> means that impls need to remember messageId
>>>>>>> which can get onerous.
>>>>>>>
>>>>>>> The WS-A WG avoided the issue of EPR equivalence mostly because
>>>>>>> of issues related to use of
>>>>>>> EPRs to identify something. IMO, in that spirit, EPR comparison
>>>>>>> becomes one of comparing the
>>>>>>> <Address> element which comes down to URI equivalence issues
>>>>>>> which can go in a number of
>>>>>>> directions... the namespace URI approach (straight string
>>>>>>> comparison) or the approach which normalizes the URI
>>>>>>> first before comparing.
>>>>>>>
>>>>>>> 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@arjuna.com> wrote on 12/12/2005
>>>>>>> 03:20:16 PM:
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>>>>>>> > There are multiple ways of making the operation idempotent.
>>>>>>>>>> Using WS-A
>>>>>>>>>> > semantics is one and IMO is probably the easiest way of
>>>>>>>>>> doing it: it
>>>>>>>>>> > goes back to traditional Retained Results RPC mechanisms of
>>>>>>>>>> the late
>>>>>>>>>> > 1980's, where idempotency was imposed at the comms level.
>>>>>>>>>> If we try to
>>>>>>>>>> > do it higher up the stack, within the actual
>>>>>>>>>> implementation, then we're
>>>>>>>>>> > going to have to address the issue of EPR comparisons: how
>>>>>>>>>> can I ensure
>>>>>>>>>> > this is the same operation if I can't determine that the
>>>>>>>>>> parameters are
>>>>>>>>>> > identical?
>>>>>>>>>> >
>>>>>>>>>> > So, I think we're agreed that it needs to be idempotent. But
>>>>>>>>>> > until/unless we address EPR comparisons, I think the WS-A
>>>>>>>>>> retry route
>>>>>>>>>> > gets my vote.
>>>>>>>>>> >
>>>>>>>>>> > Mark.
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > Christopher B Ferris wrote:
>>>>>>>>>> >
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > 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]"
>>>>>>>>>>>>>>>>>>> > > >>
>>>>>>>>>>>>>>>>>>> > > >>
>>>>>>>>>>>>>>>>>>> > > >>
>>>>>>>>>>>>>>>>>>> > > >> > > >>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> > >
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]