[ogsa-wg] BES query

[Mark McKeown]

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