Re: Reference Parameters - using them

I may be missing something here but ...

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

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.

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

Again, I've probably missed something basic here, but as far as how one
would actually use ref params, the case of baking a subscription ID into
a subscription management EPR as a reference parameter is certainly
well-accepted.

Pete Hendry wrote:

>
>
> Is there a set of scenarios that the current ReferenceParameters
> actually addresses?
>
> It is an option to point to WS-Context but the way I see it is that
> every man and his dog is going to implemetn WS-Addressing (or have
> done already) but WS-Context is a different matter. It is not such a
> high priority and so interoperability with it will be patchy for some
> time to come. The functionality I mention is an every day requirement
> and WS-Addressing had the ideal opportunity to provide a solution in a
> mechanism it provides. Without addressing this scenario
> ReferenceParameters become limited to a small niche of problems (very
> small in my opinion).
>
> As Marc says, each implementation is going to come up with a
> proprietary mechanism to support the server sending dynamic reference
> parameters to the client and (the really proprietary part) the client
> using those parameters in the next request. Even if it is something as
> simple as the server adding a wsa:From EPR or even a wsa:ReplyTo and
> the client using the parameters in that. Even though this uses wsa
> headers, the interpretation by the client would be proprietary and not
> interoperable.
>
> Even if it is a note I'd like to see this addressed somewhere and at
> the same time or soon after the WS-Addressing spec goes to final
> status. As I say, it is a problem WS-Addressing seems designed to
> solve and until I really started to use addressing I didn't realise
> what a hole this is.
>
> Pete
>
> Marc Hadley wrote:
>
>> I agree that this is a missed opportunity. As is clear from Conor's 
>> message, users of Addressing will end up designing multiple
>> solutions  to the problem. As I suggested earlier, perhaps we need a
>> more  visible pointer to WS-Context in the specification or,
>> alternatively,  a WG note could specify a standard WS-Addr based
>> mechanism ?
>>
>> Marc.
>>
>> On Sep 29, 2005, at 9:36 AM, Pete Hendry wrote:
>>
>>>
>>>
>>> Good to know I'm not the only one thinking this. The problem I see 
>>> is the usefulness of AddressingParameters is seriously degraded in 
>>> the current design. I see almost no useful scenarios for their use 
>>> in their current state. I'm sure people can come up with plenty 
>>> that they may use them for, but as I said the most common case (I'd 
>>> go so far as to say that it is probably the main use I would have 
>>> for them) is not supported which is a big loss.
>>>
>>> Pete
>>>
>>> Marc Hadley wrote:
>>>
>>>
>>>> On Sep 28, 2005, at 7:35 PM, Pete Hendry wrote:
>>>>
>>>>
>>>>>
>>>>> Related to David's examples for i057, I was wondering about what 
>>>>> I  would consider the most common use-case for reference 
>>>>> parameters -  the server wanting the client to return context in 
>>>>> the next  request. It seems to me the current design of reference 
>>>>> parameters  are only useful for
>>>>>
>>>>> a) fixed value data - i.e. not session-like data
>>>>> b) the client asking the server to pass back information using 
>>>>> the  replyTo header
>>>>>
>>>>> Consider the (common?) scenario where a client logs into a 
>>>>> server.  The server then creates a "session" in which it has 
>>>>> customerKey and  shoppingCartId values it wants the client to 
>>>>> pass back in each  subsequent request. These are opaque as the 
>>>>> client does not have to  know what the customerId or 
>>>>> shoppingCartId are to work, it just has  to include them as-is. 
>>>>> ReferenceParameters seem the ideal vehicle  for this but where 
>>>>> would the server specify these parameters?
>>>>>
>>>>
>>>>
>>>> This is the kind of use case I had in mind when I raised issue 15
>>>> [1],  the group didn't want to go there and we settled on pointing 
>>>> to WS- Context instead[2]. Mebbe we need to add something to the  
>>>> specification along these lines rather than just in the issue  
>>>> resolution in the issues list ?
>>>>
>>>> Marc.
>>>>
>>>> [1] http://www.w3.org/2002/ws/addr/wd-issues/#i015
>>>> [2] http://lists.w3.org/Archives/Public/public-ws-addressing/
>>>> 2005Jan/ 0180
>>>>
>>>>
>>>>
>>>>> They are not fixed values and will change for each 
>>>>> "conversation"  so they cannot just be specified in the WSDL with 
>>>>> fixed values.  They have to be parameterized somehow to allow the 
>>>>> server to set  the actual session values and pass them to the 
>>>>> client to be  included in the next request.
>>>>>
>>>>> Is this beyond the scope of reference parameters? In (my  
>>>>> understanding of) their current form they are of little use. It 
>>>>> is  unlikely you would want to publish fixed values within 
>>>>> parameters  in WSDL (or any other static mechanism) and less 
>>>>> likely that the  client would start the session information that 
>>>>> could be contained  within them.
>>>>>
>>>>> Pete
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---
>>>> Marc Hadley <marc.hadley at sun.com>
>>>> Business Alliances, CTO Office, Sun Microsystems.
>>>>
>>>>
>>>>
>>>
>>>
>>
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> Business Alliances, CTO Office, Sun Microsystems.
>>
>>
>
>

Received on Friday, 7 October 2005 15:43:43 UTC