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

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

Peter Furniss wrote:
> One of the nastiest things protocol standards writers can do to
> implementors is take a
> supporting specification which has some fields that are of only local
> significance and
> start adding semantics to them in a higher specification that have to be
> understood elsewhere.
> 
> An implementation of the supporting spec (WS-A, in this case) can then
> wander along quite
> happily, meeting all the requirements of that spec, then has to be
> re-worked to
> used for something else. 
> 
> Yes, we could add to the EPR semantics, but we would have to be very
> careful.
> ( not saying anyone has suggested carelessness so far)

I totally agree.  I also think we have to be very careful about adding 
this retriable funtionality though ;-).

I do not believe we can enforce an idempotent register message as the 
recovering endpoint may not be successful in obtaining its original 
endpoint (not all endpoints will have a static IP/port).  If we did 
specify that it should be idempotent then we have no mechanism of 
enforcing it as we cannot compare EPRs for equality.

Another issue to be addressed is the participant identifier being suggested.

The current mechanism has the registration service generate an 
identifier for the participant which is only understood within the 
domain of the registration service and its associated protocol handling.

The current suggestion would require an identifier to be generated by 
one domain (the participant) and trusted by a second (the registration 
service).  This would require a globally unique identifier to be created.

If a participant failed to generate a globally unique identifier then 
the registration service would have no way to know if the registration 
it was seeing was a conflicting identifier or not, at least not with 
this message exchange.

> Surely it isn't the endpoint you want to identify, but the participant.
> There could
> be coordination types in the WS-C family that want to know this is the
> same participant, perhaps
> registering with a different protocol. (actually, is there utility in
> knowing that an
> interposed coordinator has registered for both volatile and durable
> WS-AT, even if the 
> EPR's differ ?)

Agreed, but I don't see how this changes any suggestion.  The identifier 
exists somewhere and must be known for retriable register to be possible.

> It must be kept as an absolute rule that ReferenceParameters are utterly
> opaque to anything other than that which is addressed by the Address.
> WS-A has promised its implementors they are opaque; we must respect that
> (and e.g. allow implementors to have different RefParams for the "same"
> endpoint) or we aren't using WS-A. Putting other fields in at the EPR
> extension point would be legitimate, but why are we putting our
> semantics in someone else's space ?

Sorry, not sure why you think ReferenceParameters are the appropriate 
extension point.  Could you clarify?

> Are there any reasons why we shouldn't put an identifier in the Register
> message, comparable to the one in the Context ?

Nope, these were suggested alternatives.

	Kev