- From: Gilbert Pilz <gilbert.pilz@oracle.com>
- Date: Tue, 12 May 2009 13:08:18 -0700
- To: Geoff Bullen <Geoff.Bullen@microsoft.com>
- CC: Doug Davis <dug@us.ibm.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <4A09D732.9030207@oracle.com>
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