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