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

[Ian Robinson <ian_robinson@uk.ibm.com>]

Mark Little <mark.little@jboss.com> wrote on 15/12/2005 10:48:50:

>
>
> Ian Robinson wrote:
>
> >
> >
> >Regarding WS-RM, the "scope of work" section of the charter states:
> >
> >"As general principles, these protocols ... must not depend on the
> >availability of reliable message delivery mechanisms outside of these
> >specifications."
> >
> >
> +1
>
> >
> >
> >This issue proposes a change to the semantic of the Register request but
I
> >believe that none is needed. Retrying a Register request because of
network
> >failures is not the only scenario in which a Participant can be
registered
> >multiple times for the same transaction. The important consideration is
> >whether or not the multiple participant instances will behave properly
when
> >they are directed to complete according to the specific agreement
protocol
> >(e.g. AT or BA). And the state tables ensure that they can.
> >
> >
> >
> >If the TC believes clarification is required then I would suggest the
> >following text:
> >
> >A Coordinator is not required to detect duplicate Register messages, but
> >MAY attempt to do so by means that are out of the scope of this
> >specifiction. A registration requester MAY send multiple Register
messages
> >to a Coordinator that does not detect duplicates - for example because
it
> >retried a Register request following a lost RegisterResponse. If a
> >registration requester registers multiple times for the same activity
then
> >the registered Participants MUST be prepared to handle multiple protocol
> >messages from a Coordinator that treats the multiple Register requests
as
> >distinct Participants. There are a number of simple strategies for
> >accomplishing this. For example, the registration requester can generate
a
> >unique ReferenceParameter for each Participant EPR that is passed in a
> >Register request.
> >
> >
> I would agree with this under the following assumption (or maybe
> clarifications are needed): I assume you're implicitly talking about
> removing the fault on multiple participant registrations?

Yes, it makes sense to sort out issue 8 (AlreadyRegistered) first.

Regards,
Ian Robinson
STSM, WebSphere Messaging and Transactions Architect
IBM Hursley Lab, UK
ian_robinson@uk.ibm.com