Re: Reference Parameters - using them

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.