[ogsa-wg] BES query

[Tom Maguire]

It is a correct use of ReferenceParameters.  That is not to say that
other uses are incorrect.

Tom

Mark McKeown <zzalsmm3 at 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 at man.ac.uk                     Manchester Computing
> +44 161 275 0601                    University of Manchester
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> On Wed, 31 Aug 2005, Tom Maguire wrote:
>
> >
> > Mark McKeown <zzalsmm3 at nessie.mcc.ac.uk> wrote on 08/31/2005 09:53:39
AM:
> >
> > >
> > > 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
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
> > >
> >
> >
>