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

[Kevin Conner <Kevin.Conner@jboss.com>]

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