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

[Doug Davis <dug@us.ibm.com>]

One thing that concerns me about using
the wsa:MessagID is the assumption
that you'll use the same messageID on
each retry.  Can the Tx spec really
require this?  Other specs (like
WSA) which are infrastructural can probably make
this kind of requirement (if they need
to), but I always viewed Tx as sitting on top
of these infrastructural layers and
not so much as being part of them.  Implementations
will vary on this view but I wouldn't
think Tx would want to mandate this kind of choice.
thanks,
-Doug

Kevin Conner <Kevin.Conner@jboss.com>

12/12/2005 06:29 PM

To	Christopher B Ferris/Waltham/IBM@IBMUS
cc	Mark Little <mark.little@arjuna.com>, ws-tx@lists.oasis-open.org
Subject	Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable

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.

Something extra will have to be remembered in any case.  The advantage
of the messageId is that it already has comparison rules which an EPR 
does not.  That is not to say that they can't be compared (see below).

> 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.

The identity associated with an EPR is more than just the address 
element though, a comparison will tell you that it uses the same 
endpoint but not that the EPRs are identical.  For example, we add
an 
instance identifier element which is used by the endpoint to identify 
the respective instance and multiplex accordingly.

As far as the current register message is concerned there are three 
identifying elements.
  - The From (or ReplyTo) EPR
  - The ParticipantProtocolService EPR
  - The messageID

The From (or ReplyTo) EPR is unlikely to be unique enough to identify 
the participant but, even if it was, this would require storing more 
than a message id.  It would also require rules for EPR comparison.

The ParticipantProtocolService EPR will uniquely identify the 
participant but, once again, requires rules for EPR comparison.

The message ID should uniquely identify the message exchange but within
what context?

The August 2005 WS-Addressing spec does not define a means of comparing
EPRs but it does not prevent it.  We have the option to define EPR
structure and/or rules for comparison within WS-C.

The spec also states that the message ID should be 'an absolute URI that
uniquely identifies the message'.  What it doesn't state is the context
within which this holds true, whether this is intended to be global or
within the context of the sender.

After all this there appear to be three choices
  - use the message ID as the identifier and require it to be
    globally unique (comparison rules already exist).
  - define a structure for the EPRs to make them globally unique
    and rules to make them comparable.
  - Change the request so that it includes a unique identifier associated
    with the EPR.

My initial opinion was that the message ID already does the job so why
do we need another mechanism?  We could easily use this to handle
retransmission issues.

Having clarified my thoughts while writing this response I now believe
that the second or third choice would be preferable.  The only question
now would be whether the EPR should remain totally opaque (the last 
choice) or whether we should have a mechanism to associate an EPR with
a 
participant (the second choice).

                
Kev