Re: Reference Parameters - using them

David Hull wrote:

>I may be missing something here but ...
>
>  
>

Marc's response described the problem very well.

>The OASIS WSN (Notification) standard has two basic uses for EPRs. 
>First, a subscription request includes an EPR saying where to deliver
>notifications for that subscription.  This is a classic example of using
>an EPR analogously to a callback.  Second, the response to a
>subscription request contains an EPR that can be used to manage the
>newly-created subscription (e.g., pause production of notifications,
>cancel the subscription, etc.).   This is a classic example of using an
>EPR as a pointer to the resource.
>
>In either case, the party receiving the EPR doesn't care what reference
>parameters it contains.  All it needs to know is to stuff those
>parameters into the SOAP headers of the outgoing message (or the
>equivalent, if we're not using SOAP).  In the case of the EPR
>controlling the subscription, the [address] may well be the same for
>several subscriptions, with some sort of distinguishing cookie hidden in
>the [reference parameters].  In the case of the destination EPR in the
>subscription request, the EPR might contain anything at all in its
>[reference parameters].
>
>  
>

There is some confusion I think. The argument we are making is not that 
the reference parameter idea is not good, it is that it is not 
transparent on the client when the server wants the client to return 
opaque information to the server. Your example clearly shows this. Your 
service returns a response that contains an EPR that the client is then 
to use. However, what is the mechanism for the client to get this EPR 
from the response and use it - and even to know about it? A proprietary 
one (WS-Notification will describe it). The EPR is functioning outside 
of the WS-Addressing framework.

What I am arguing (and Marc too) is that there should be a means to have 
the client automatically get this EPR and use it - a standard mechanism. 
There should not have to be any code on the client to explicitely take 
this EPR, extract the parameters and put them in the next request (if 
that's what it is doing). One approach may be to allow the response to 
contain a wsa:ReplyTo header also (this would also facilitate the case 
where the logon service is the initial point of contact of a site and 
then the client can be redirected once authenticated using the Address 
field of the ReplyTo in the response - but that's getting a bit ahead of 
myself!).

Consider when the client sends a message to the service. It can include 
a wsa:ReplyTo EPR and the reveiver knows to take the reference 
parameters from that and add them to the response message. There is no 
such standard mechanism (in the WS-Addressing standard anyway) to allow 
the client to know what to send to the server (excluding static EPRs 
defined in WSDL - but unfortunately that approach seems pointless since 
the service can see the WSDL too so why would the client need to include 
parameters from it?). The server can't include an EPR in a WSA header 
that says to the client - return these parameters in your next request 
(which I think is what you are talking about doing with your example).

For most (not all) use-cases I have for reference parameters this is the 
requirement. As an example, any system where the client logs in or is 
allocated a resource could make use of a dynamic EPR mechanism so the 
server returns the session or resource details in the response as an 
opaque reference parameter and the client then automatically uses these 
parameters in the next request.

With the current specification around parameters, each new specification 
(WSN, etc) is going to add its own logic for this functionality. That is 
a shame when it could be inherited from WS-Addressing.

>All this seems harmless (leaving aside the question of whether the
>"stuff the ref params into the headers" model represents a security
>hole).  There is no interoperability problem, since the minter of the
>EPR is essentially interoperating with itself.  More precisely, the only
>parties that care what the [reference parameters] look like are the
>minter and whatever's sitting at the [address] of the EPR.  It's the
>minter's job to know what kind of parameters to use for that particular
>endpoint, but that seems like a fundamental requirement, and
>particularly in the common case where the minter and the recipient are
>the same party, it should be no problem.
>
>  
>

But where the service is the minter, how does it tell the client what to 
send in its next interaction? There is nowhere for the service to put 
the EPR that the client will find it automatically. Sure, a 
specification can say "it will return an EPR as header X or part Y 
containing reference parameters...", but that would be specification 
specific instead of being a standard mechanism of WS-Addressing.

>WSA should allow for all different kinds of reference parameters, from
>some ad-hoc cookie to a WS-Context, to whatever.  
>

Yes it should, but it doesn't. A cookie is a good example of the 
problem. If the server creates a cookie how does it tell the client to 
include it in the next request?

>If you're in a
>situation where you're using WS-Context, you may well want to hand out
>an EPR to an endpoint that needs a particular context attached to
>messages sent to it.  We allow for that.  A WS-Context context could be
>used as a reference parameter.  That doesn't mean that reference
>parameters can only be used with WS-Context.
>
>  
>

This is not part of the argument. Nobody is arguing that you can't do this.

I would just like to avoid having to implement client logic every time a 
new specification comes out with its own way of taking context from a 
reply and sticking it in the next request (with the most likely scenario 
being that each new specification will define where in the message an 
EPR will be with reference parameters in it - so yes, it uses EPRs and 
reference parameters but it is not automatic and not part of 
WS-Addressing how it is encapsulated).

To take the example of visiting a site where you log in and are 
allocated say a session id and a shopping cart id (most likely just a 
session id in real life). How could WS-Addressing be used to handle this 
session id as a reference parameter without having to write custom 
client code for each different such service?

Pete

Received on Saturday, 8 October 2005 03:13:47 UTC