RE: [issue 6432] - a modest proposal

Doug,
Can we quickly cover what your proposed solution to replace mode really is at the moment, please?
Is it:

a)      Use extensions to EPR and Subscribe and mU headers?  Remember that Mode should fault if it is not a valid mode, so mU would be the thing that allows that functionality.

b)      Use runtime policy negotiation with the policy statements in the NotifyTo EPR.

c)      Some combination of the two approaches.
I am kind of assuming it's a) but I want to make sure before I comment further.
Thanks,
Geoff

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Saturday, May 09, 2009 10:35 AM
To: public-ws-resource-access@w3.org
Subject: Re: [issue 6432] - a modest proposal


This might be true if someone could show why the proposed solution doesn't work for both.  To date, the only consistent complaint about the proposal is that is may require some code changes.  I believe Gil even proposed a challenge [1] to address this type of concern - sadly, no one has taken him up on it.

[1] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0135.html

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.

Bob Freund <bob@freunds.com>
Sent by: public-ws-resource-access-request@w3.org

05/07/2009 08:42 PM

To

Yves Lafon <ylafon@w3.org>

cc

David Snelling <David.Snelling@UK.Fujitsu.com>, Gilbert Pilz <gilbert.pilz@oracle.com>, Asir Vedamuthu <asirveda@microsoft.com>, Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>

Subject

Re: [issue 6432] - a modest proposal







There seems like there is a big-systems use of notification as well as
a small-device market for the same protocol.
The difference seems to be the extent to which negotiation protocols
and additional features might be available.
It sounds like finding a way like this to make both ways possible
might be what is needed.
-bob

On May 6, 2009, at 4:19 PM, Yves Lafon wrote:

> On Thu, 9 Apr 2009, Bob Freund wrote:
>
>> Would it be too bold to suggest folks consider to move NotifyTo to
>> be a child of Subscribe?
>> that way, then Delivery could be used (as an xs:Any) extension
>> point, used by other specifications to mean anything they want at
>> at cost of merely setting a SOAP mU header on delivery to get the
>> fault behavior.  Of course, the fault would change from
>> modeNotRecognized to SOAP mU Fault, but the other stuff would still
>> work.
>> Is that half-way-ish approach that folks could consider?
>
> The main issue is still the addition of the mU in the default version.
> How about adding a specific mode (like 'anonymous') that would
> trigger the use of the other approach.
> That way we would have the "historic" use of mode, and the new
> version using the same trigger mechanism, allowing old
> implementation to interoperate with newer ones, while keeping a way
> to use the new version in all the cases where the old version would
> not be optimal.
> Would that make sense for both camp ?
>
>>
>> On Apr 9, 2009, at 11:09 AM, David Snelling wrote:
>>
>>> Folks,
>>> I will try this with colour:
>>> <s:Envelope . . .>
>>> <s:Header>
>>>   <wsa:Action>http://www.w3.org/2009/02/ws-evt/Subscribe<wsa:Action>
>>>   <wsa:MessageID>uuid:d7c5726b-de29-4313-b4d4-b3425b200839</
>>> wsa:MessageID>
>>>   <wsa:ReplyTo>
>>>     <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</
>>> wsa:Address>
>>>   </wsa:ReplyTo>
>>>   <wsa:To>http://www.example.org/oceanwatch/EventSource</wsa:To>
>>> </s:Header>
>>> <s:Body>
>>>   <wse:Subscribe>
>>>     <wse:Delivery>
>>>       <wse:NotifyTo>
>>>         <wsa:Address>http://www.w3.org/2005/08/addressing/
>>> anonymous</wsa:Address>
>>>       </wse:NotifyTo>
>>>     </wse:Delivery>
>>>   </wse:Subscribe>
>>> </s:Body>
>>> </s:Envelope>
>>> Red: General SOAP layer.
>>> Green: WSE Application Layer.
>>> Blue: WS-Addressing infrastructure.
>>> OK the important point is that no matter what delivery model I
>>> want to use, I only change blue and red text. The beauty of
>>> Eventing is that the green XML stays the same across all the use
>>> cases we have discussed.
>>> For wse:Push: In the blue NotifyTo EPR include a sensible address.
>>> For wsman:PushWithAck: In the blue NotifyTo EPR include an address
>>> and possibly policy indicating reliable delivery required. This
>>> will means some more stuff will show up in red and possibly orange
>>> (for the reliable messaging) on the delivered messages.
>>> For wsman:Pull: In blue include either an MC special URI or the
>>> actual address of a WS-Notification Pull point.
>>> For wsman:Events: This is the same as wsman:PushWithAck which
>>> affects only the blue, red, and orange XML, but using a format
>>> provided by WS-Management V2.0 in some pink XML.
>>> Notice: No Green XML changes!!!
>>> In fact existing implementations have to change NOTHING in their
>>> semantics. They will need to understand the new namespace and
>>> learn not to look for the Mode attribute. The semantics of
>>> Eventing do not change.
>>> On 08 Apr 2009, at 20:08, Gilbert Pilz wrote:
>>>> I think that, in this context, the term "opaque" might be a red-
>>>> herring. The point is that a URI like "http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=1447d9c0-246a-11de-8c30-0800200c9a66
>>>> " requires neither more nor less understanding at the application
>>>> layer (in this case the component that processes wse:Subscribe
>>>> requests) than a URI like "http://www.w3.org/2005/08/addressing/anonymous
>>>> " or "http://webservice.bea.com/ohai/lolcatz".
>>>> I think part of the problem might be that we are all assuming
>>>> different processing models. Look at the following request and
>>>> tell me how you think it should be handled. If you could be
>>>> somewhat specific about which layer (ws-addr layer, general SOAP
>>>> layer, wse:Subscribe logic, etc.) does/checks what, that would be
>>>> helpful:
>>>> <s:Envelope . . .>
>>>> <s:Header>
>>>>   <wsa:Action>http://www.w3.org/2009/02/ws-evt/
>>>> Subscribe<wsa:Action>
>>>>   <wsa:MessageID>uuid:d7c5726b-de29-4313-b4d4-b3425b200839</
>>>> wsa:MessageID>
>>>>   <wsa:ReplyTo>
>>>>     <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</
>>>> wsa:Address>
>>>>   </wsa:ReplyTo>
>>>>   <wsa:To>http://www.example.org/oceanwatch/EventSource</wsa:To>
>>>> </s:Header>
>>>> <s:Body>
>>>>   <wse:Subscribe>
>>>>     <wse:Delivery>
>>>>       <wse:NotifyTo>
>>>>         <wsa:Address>http://www.w3.org/2005/08/addressing/
>>>> anonymous</wsa:Address>
>>>>       </wse:NotifyTo>
>>>>     </wse:Delivery>
>>>>   </wse:Subscribe>
>>>> </s:Body>
>>>> </s:Envelope>
>>>> - gp
>>>> Yves Lafon wrote:
>>>>> On Tue, 7 Apr 2009, Gilbert Pilz wrote:
>>>>>> WS-Addressing 1.0 - Core defines two "special" URIs;
>>>>>> "http://www.w3.org/2005/08/addressing/anonymous" and
>>>>>> "http://www.w3.org/2005/08/addressing/none". Messages targeted
>>>>>> to either
>>>>>> of these URIs are processed differently from messages targeted to
>>>>>> "normal" URIs such as "http://webserivce.bea.com/. . .".
>>>>> Well, they are different, but unless you know WS-Addressing, or
>>>>> unless you resolve http://www.w3.org/2005/08/addressing/
>>>>> anonymous and find out the relationship between this URI and the
>>>>> WS-Addressing spec.
>>>>> If you resolve http://webservice.bea.com/... you will probably
>>>>> have information about the endpoint, or you may know it in
>>>>> advance from another document. So both URIs are opaque, unless
>>>>> you know their semantic.
>>> Take care:
>>>
>>>   Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
>>>   Fujitsu Laboratories of Europe Limited
>>>   Hayes Park Central
>>>   Hayes End Road
>>>   Hayes, Middlesex  UB4 8FE
>>>   Reg. No. 4153469
>>>
>>>   +44-7590-293439 (Mobile)
>>> ______________________________________________________________________
>>> Fujitsu Laboratories of Europe Limited
>>> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
>>> Registered No. 4153469
>>> This e-mail and any attachments are for the sole use of
>>> addressee(s) and
>>> may contain information which is privileged and confidential.
>>> Unauthorised
>>> use or copying for disclosure is strictly prohibited. The fact
>>> that this
>>> e-mail has been scanned by Trendmicro Interscan and McAfee
>>> Groupshield does
>>> not guarantee that it has not been intercepted or amended nor that
>>> it is
>>> virus-free.
>>
>
> --
> Baroula que barouleras, au tiéu toujou t'entourneras.
>
>        ~~Yves
>
>