Re: Reference Parameters - using them

If you're after session semantics, then you should look at WS-Context 
[1]: it's a cleaner model for sessions [2] and works with WS-Addressing 
"as is". It's also about to become an OASIS standard.

[1] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-caf
[2] 
http://www.orablogs.com/pavlik/archives/The-Session-Concept-in-Web-Services.pdf

Mark.


Marc Hadley wrote:

> On Oct 7, 2005, at 11:42 AM, David Hull wrote:
>
>>
>> I may be missing something here but ...
>>
> I don't disagree with anything in your post but I think you missed  
> the issue. The point is that WSN had to invent a new mechanism to  
> say: "send future requests about this notification here". Earlier in  
> the thread Conor described his <EndpointReferenceUpdate> header that  
> is used to accomplish something similar. I, and I think Pete agrees,  
> think it would be better if there was a standard mechanism defined  
> within WS-A to accomplish this kind of thing. This would be analogous  
> to cookies in HTTP where the server has the ability to say "next time  
> you contact me, include this new opaque data in the request".  
> Reference parameters have been compared to HTTP cookies but WS-A  
> lacks this simple but important capability unless you extend it.
>
> Is that any clearer ?
>
> Marc
>
>> 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.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
>
>

Received on Monday, 10 October 2005 11:56:47 UTC