Re: [issue 6432] - a modest proposal

Geoff,

As I said before, please show me a specific message (in XML) using Mode. 
I will show you the same message without Mode. We can then compare and 
contrast.

- gp

On 5/12/2009 9:57 AM, Geoff Bullen wrote:
>
> Thanks Gil,
>
>  
>
> Based on the information below, let us look at the following example:
>
>  
>
> The event source has implemented four different extensibility points 
> A, B, C, D.
>
> The event source has only validated (via interop testing) two possible 
> combinations: A,B,C and A,B,D.
>
> These are the only two combinations supported by the event source.
>
>  
>
> If mode is used, one can easily create two modes RED = A,B,C and BLUE 
> = A,B,D and the client can simply send this mode, along with any 
> required information, to the event source for processing.
>
>  
>
> Without mode, there are a number of interesting situations:
>
> 1)      What if the client does not send mU headers and sends elements 
> A,B,C,D? ( Can you ignore some of them?)
>
> 2)      What if the client does send mU headers and sends elements 
> A,B,C,D?  (Does must understand = must use?)
>
> 3)      What if B required no information to be sent from the client 
> to the event source (only the fact that the client wants to use B)?  
> Does that mean you would have to create an empty element B, just to 
> send something?  Or use an mU header?  Using mode, both RED and BLUE 
> infer B, no need to send an empty element at all.
>
> 4)      The event source, without mode, now seems to have a much more 
> complicated task of trying to figure out if the client wants RED, BLUE 
> or if it's a fault situation -- illegal combination?  For example, 
> without mode, the combination A,B would have to be seen as illegal.  
> With mode = RED, the event server could use the default values for C 
> and proceed.
>
> 5)      Without mode, would the combination B,C be legal or illegal?
>
> 6)      Think of the documentation that the event source will generate 
> in order for the client to understand what is supported.  It will 
> almost certainly talk about RED mode and BLUE mode and point out what 
> is required to support both.  The natural extension to this is for the 
> client to simply select RED or BLUE when doing the subscribe.
>
> 7)      Gets more complicated if A is only a partial implementation 
> and A (with one setting) supports RED and A (with a different setting) 
> supports BLUE.
>
> 8)      There are probably more...
>
>  
>
> The point is, as has been stated many times, you can always find a way 
> to solve any problem with any of the solutions proposed, but some 
> solutions are better at handling certain situations than others.  Mode 
> is better at handling grouping cases where there is a small number of 
> supported configurations which contain groups of characteristics.  
> Other ways are better at handling the opposite case, where the event 
> source supports a variety of characteristics that can be combined in 
> different ways.  It seems that we should support both options.
>
>  
>
> --Geoff
>
>  
>
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Monday, May 11, 2009 5:25 PM
> *To:* Geoff Bullen
> *Cc:* Doug Davis; public-ws-resource-access@w3.org
> *Subject:* Re: [issue 6432] - a modest proposal
>
>  
>
> Geoff,
>
> I believe I can speak for those of us who would like to eliminate the 
> Delivery element and the Mode attribute.
>
> 1.) Use the extensibility that already exists in Subscribe and the 
> various EPRs to express your extensions. For example, request an 
> extension by adding a child element to Subscribe.
>
> 2.) If necessary (and it's important to note that it is not always 
> necessary), accompany the extension with a SOAP mU header that 
> indicates that an extension is being used.
>
> 3.) Use WS-Policy assertions to indicate which extensions are 
> supported by an Event Source. These policies assertions can be 
> attached to WSDLs and retrieved by the normal mechanisms for obtaining 
> a WSDL (HTTP, WS-Mex), or they may be retrieved directly via WS-MEX, 
> or they may be retrieved via some other mechanism.
>
> - gp
>
> On 5/11/2009 12:02 PM, Geoff Bullen wrote:
>
> Doug,
>
> Can we quickly cover what your proposed solution to replace mode 
> really is at the moment, please?
>
> Is it:
>
> 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.
>
> Use runtime policy negotiation with the policy statements in the 
> NotifyTo EPR.
>
> 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> 
> [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 
> <mailto: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 <mailto:dug@us.ibm.com>
> The more I'm around some people, the more I like my dog.
>
>
> *Bob Freund <bob@freunds.com> <mailto:bob@freunds.com>*
> Sent by: public-ws-resource-access-request@w3.org 
> <mailto:public-ws-resource-access-request@w3.org>
>
> 05/07/2009 08:42 PM
>
> 	
>
> To
>
> 	
>
> Yves Lafon <ylafon@w3.org> <mailto:ylafon@w3.org>
>
> cc
>
> 	
>
> David Snelling <David.Snelling@UK.Fujitsu.com> 
> <mailto:David.Snelling@UK.Fujitsu.com>, Gilbert Pilz 
> <gilbert.pilz@oracle.com> <mailto:gilbert.pilz@oracle.com>, Asir 
> Vedamuthu <asirveda@microsoft.com> <mailto:asirveda@microsoft.com>, 
> Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" 
> <mailto:public-ws-resource-access@w3.org> 
> <public-ws-resource-access@w3.org> 
> <mailto: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" 
> <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" 
> <http://www.w3.org/2005/08/addressing/anonymous> and
> >>>>>> "http://www.w3.org/2005/08/addressing/none" 
> <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/. . ." 
> <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
> >
> >
>
>

Received on Tuesday, 12 May 2009 20:09:15 UTC