[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
On a couple of points point from Kevin's message > 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. 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) > 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. 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 ?) > 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). 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 ? (probably I'm getting over-excited here :-) Are there any reasons why we shouldn't put an identifier in the Register message, comparable to the one in the Context ? Peter
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]