- From: Gilbert Pilz <gilbert.pilz@oracle.com>
- Date: Thu, 14 May 2009 11:38:29 -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: <4A0C6525.4030008@oracle.com>
Geoff,
To *repeat* the arguments I made here:
* http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0012.html
* http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0060.html
* http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0095.html
* http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0115.html
* http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0128.html
and Dave made here:
* http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0050.html
* http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0054.html
and Doug made here:
* http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0016.html
* http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0065.html
* http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0094.html
and which are described by the Wiki page here:
* http://www.w3.org/2002/ws/ra/wiki/Redundant_Extension_Points
1.) Specifying a single mechanism for extending wse:Subscribe simplifies
the task of implementing extensions and promotes interoperability. The
current spec forces the developer to figure out whether an extension is
a "delivery mode" or something else, whether any extending
elements/attributes should be children of wse:Delivery or wse:Subscribe,
which mechanism(s) falls under "ignore not understood" and which
mechanism(s) trigger "fault not understood", etc. To see where this
leads, take a look at Section 7 of WS-Management 1.0
<http://www.dmtf.org/standards/published_documents/DSP0226.pdf>; it
specifies modes with corresponding extensions to Delivery, modes w/out
corresponding extensions to Delivery, extensions to Delivery with no
corresponding mode URI, extensions to Subscribe, etc. This confusion is
unnecessary. An extension is an extension whether you call it a
"delivery mode" or a "subscription attribute" or whatever. Having
multiple extension mechanisms with differing semantics will result in
the kind of interoperability problems that will require a WS-I profile
to solve.*
2.) The Delivery element and its Mode attribute are at odds with the
common state of practice within WS-*. The common state of practice is to
allow attribute and element extensions to both the request and response
messages with the understanding that extensions that are not recognized
will be ignored. Requests to enable/engage extended behavior are
signaled by adding elements and/or attributes to request messages.
Acceptance of extension requests are signaled by corresponding elements
and/or attributes in the response messages. If requester needs to
indicate that an extension must be understood to correctly process the
request, they add a SOAP header with mU=1 to indicate this. Removing
Delivery from wse:Subscribe aligns WS-Eventing with this common practice.
3.) Mode's semantics of "fault if you don't recognize the mode URI" are
not flexible enough to cover the cases in which the Subscriber is
willing to accept the creation of a subscription without the extension.
The common WS-* model (defined in 2 above) covers such cases by omitting
the mU header and indicating acceptance of the extension via a
corresponding extension to SubscribeResponse.
4.) The fact that Mode has a single URI value means that you must create
"extension collections" (your Red/Blue) in order to use it. Normal
extensions (as defined by item 2 above) can represent *either* an
extension collection or an atomic extension. Extension collections *may*
have the benefit of providing some level of interoperability
conformance, but they do so at the expense of requiring some
organization (e.g. the DMTF) to define them and test them. This approach
does not scale outside the realm of vertical market segments like
management.
5.) The Delivery element is inefficient both from an XML perspective and
from a coding perspective. The data bindings of the current
wse:Subscribe for most languages will create an additional class for the
Delivery element. An instance of this class must be instantiated and
initialized before you can send a Subscribe request. On the service end
you need to create an instance of a similar class, unmarshall the XML,
etc. All of this may be worth the cost if Delivery actually performed
some useful function or defined some useful semantics, but it does neither.
6.) To minimize the code changes between WS-Eventing 200603 and
WS-Eventing 1.0 specifications like WS-Management 2.0 *could* re-use the
wse06:Delivery element as an extension to Subscribe message.
- gp
* I assert that, if any of the WS-RA specs require WS-I profiles for
their effective use, we (the WS-RA WG) will have failed.
On 5/12/2009 4:44 PM, Geoff Bullen wrote:
>
> Gil,
>
> This version seems to have no value-add over the original version.
> Can you explain the point of moving the mode from where it is now, and
> distributing its functionality between both the header and an extra
> extension element?
>
> --Geoff
>
>
>
> *From:* public-ws-resource-access-request@w3.org
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of
> *Gilbert Pilz
> *Sent:* Tuesday, May 12, 2009 4:32 PM
> *To:* Geoff Bullen
> *Cc:* Doug Davis; public-ws-resource-access@w3.org
> *Subject:* Re: [issue 6432] - a modest proposal
>
>
>
> Geoff,
>
> Not at all. The equivalent w/out mode would be:
>
> [Header]
> <som:UseBlue mustUnderstand="1"/>
>
> [Body]
> <wse:Subscribe>
> <wse:NotifyTo>{some EPR}</wse:NotifyTo>
> <som:Blue/>
> </wse:Subscribe>
>
> There's no reason why my extensions have to be atomic while your
> extensions get to be collections. That's an orthogonal consideration
> that has nothing to do with the use or non-use of Mode.
>
> - gp
>
> On 5/12/2009 4:13 PM, Geoff Bullen wrote:
>
> Gil,
>
> It is not just a simple case of comparing XML, but let's start here...
>
>
>
> Using the RED/BLUE example discussed below...
>
>
>
> Using mode, we send:
>
>
>
> [Body]
>
> <Subscribe>
>
> <Delivery mode=".../BLUE">
>
> <NotifyTo> ... </NotifyTo>
>
> </Delivery>
>
> </Subscribe>
>
>
>
> The equivalent without mode would be:
>
>
>
> [Header]
>
> <UseA mustUnderstand="1"/>
>
> <UseB mustUnderstand="1"/>
>
> <UseD mustUnderstand="1"/>
>
>
>
> [Body]
>
> <Subscribe>
>
> <NotifyTo> ... </NotifyTo>
>
> <A />
>
> <B />
>
> <D />
>
> </Subscribe>
>
>
>
> Maybe some of the A, B, D elements are actually inside the NotifyTo
> EPR, but it does not matter for this discussion.
>
>
>
> --Geoff
>
>
>
>
>
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Tuesday, May 12, 2009 1:08 PM
> *To:* Geoff Bullen
> *Cc:* Doug Davis; public-ws-resource-access@w3.org
> <mailto:public-ws-resource-access@w3.org>
> *Subject:* 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:
>
> What if the client does not send mU headers and sends elements
> A,B,C,D? ( Can you ignore some of them?)
>
> What if the client does send mU headers and sends elements A,B,C,D?
> (Does must understand = must use?)
>
> 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.
>
> 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.
>
> Without mode, would the combination B,C be legal or illegal?
>
> 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.
>
> 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.
>
> 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
> <mailto: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 Thursday, 14 May 2009 18:39:32 UTC