[ogsa-wg] BES query

Mark McKeown zzalsmm3 at nessie.mcc.ac.uk
Tue Sep 13 04:47:26 CDT 2005 

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 at 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 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
> > > >
> > >
> > >
> >
>
>

More information about the ogsa-wg mailing list