Hi Tom, Taking the discussion to the next stage. I have shown a case where ReferenceParameters could be used to provide a mechanism to support locking of WS-Resources, ie using stateful interactions. Now if a service provider gives me a EPR containing ReferenceParameters then I should NOT put that EPR into any sort of public registry where other clients might find that EPR and use it. I cannot tell what the ReferenceParameters are being used for, they could be used to track one of my particular client activities so I don't want any other client to use that EPR and associated ReferenceParameters. In the case of the lock, if the WS-Resource provider was using the ReferenceParameters to track which client has the lock - then putting the EPR into a registry for other clients to find would lead to major problems. Effectively a client should not publicise/share EPRs that contain ReferenceParameters. Therefore I think it is a mistake for WS-Resource providers to use ReferenceParameters to associate a message with a particular piece of state - I think that is why the WS-Addressing WG discourages this use of ReferenceParameters. cheers Mark ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Mc Keown RSS Mark.McKeown@man.ac.uk Manchester Computing +44 161 275 0601 University of Manchester ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Fri, 2 Sep 2005, Tom Maguire wrote:
It is a correct use of ReferenceParameters. That is not to say that other uses are incorrect.
Tom
Mark McKeown <zzalsmm3@nessie.mcc.ac.uk> wrote on 09/02/2005 06:24:09 AM:
Hi Tom, Thanks for the response - just to make I am understanding everything correctly.
ReferenceParameters are used to "facilitate a particular interaction" with an endpoint - Hugo Hass compared them to HTTP Cookies.
Taking an example of a WS-Resource with an associated ResourceProperties document. The WS-Resource could have an endpoint:
<wsa:EndpointReference> <wsa:address>http://vermont.mvc.mcc.ac.uk/<wsa:address> </wsa:EndpointReference>
Now supposing the WS-Resource provider wanted to povide leases for providing a write lock on the ResourceProperties document, to support this the WS-Resource needs to support stateful interactions, ie. the WS-Resource needs to be able to identify which client holds the lease. (Cookies are designed to support stateful interactions over HTTP so we should be able to use ReferenceParameters) The WS-Resource provider could do this by providing a new EPR that contained ReferenceParameters to the client when he requests the lease (other options are WS-Context and WS-Coordintation) - the EPR could look like
<wsa:EndpointReference> <wsa:address>http://vermont.mvc.mcc.ac.uk/<wsa:address> <wsa:ReferenceParameters> <my:Lease>345...56</my:Lease> </wsa:ReferenceParameters> </wsa:EndpointReference>
The client who presents <my:Lease>345...56</my:Lease> in the SOAP Header has the write lock - effectively the ReferenceParameters are used to indentify a client in this case. (Of course some people object to stateful interactions - not as scalable, not as fault tolerent etc, http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)
Once the lease expires the EPR is invalid - the client has to get a new one.
(Another approach is to give each client a different EPR with different ReferenceParameters - then clients don't have to get a new EPR when they request a lease and you can track what each client does, similar to how HTTP cookies can track browsers as they move around a site)
So resolving an EPR could be needed for two reasons: the endpoint has moved (similar to 301 in HTTP ) or the client wants to start a new stateful interaction (similar to deleting your cookies from you browser).
Is this example the correct use of ReferenceParameters?
thanks Mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Mc Keown RSS Mark.McKeown@man.ac.uk Manchester Computing +44 161 275 0601 University of Manchester ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Wed, 31 Aug 2005, Tom Maguire wrote:
Mark McKeown <zzalsmm3@nessie.mcc.ac.uk> wrote on 08/31/2005 09:53:39
Hi Tom,
If so, then a unique AbstractName is needed in order to accurately
resolve
EPRs, especially considering the potential service migration.
I think that AbstractName is certainly one approach to solving this problem. Remember that ReferenceParameters are used to provide information to the RECEIVER(wsa:to) to disambiguate the resource for dispatch.
I am confused by this - according to the WS-Addressing working group ReferenceParameters are designed to support stateful interactions (similar to the use of cookies with HTTP) - not to identify resources. They CAN be used to identify resources but this is not best practice according to the working group.
Ok, so what is confusing you is the use of 'disambiguate the resource for dispatch'. So, change that sentence to: Remember that ReferenceParameters are used to provide required information to the RECEIVER(wsa:to) interaction.
And the spec ultimately wound up saying: [reference parameters] : xs:any (0..unbounded). A reference may contain a number of individual parameters that are associated with the endpoint to facilitate a particular interaction. Reference parameters are namespace-qualified element information items that are required to properly interact with the endpoint. Reference parameters are provided by the issuer of the endpoint reference and are assumed to be opaque to other users of an endpoint refernce. The binding of reference parameters to messages depends upon the protocol binding used to interact with the endpoint - Web Services Addressing 1.0 - SOAP Binding[WS-Addressing-SOAP] describes the default binding for the SOAP protocol.
and additionally says:
2.3 Endpoint Reference Comparison
This specification provides no concept of endpoint identity and
AM: therefore
does not provide any mechanism to determine equality or inequality of EPRs and does not specify the consequences of their equality or inequality. However, note that it is possible for other specifications to provide a comparison function that is applicable within a limited scope.
see http://www.w3.org/2002/ws/addr/wd-issues/#i001 and http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0051
thanks Mark