- From: Doug Davis <dug@us.ibm.com>
- Date: Fri, 15 May 2009 18:02:36 -0600
- To: public-ws-resource-access@w3.org
- Message-ID: <OFB7C7092A.0E0EF60E-ON852575B7.0083A87A-852575B8.00003F02@us.ibm.com>
You're asking the wrong question. No one is doubting that people can use
WS-Eventing today in the most basic of pre-canned cases. But how many of
those vast numbers of implementations, you claim are out there, can add in
support for any additional (existing WS*) feature today without needing
some additional spec to make the link between Eventing and that
"composible" feature? Zippo!
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.
Geoff Bullen <Geoff.Bullen@microsoft.com>
Sent by: public-ws-resource-access-request@w3.org
05/15/2009 07:03 PM
To
Doug Davis/Raleigh/IBM@IBMUS
cc
Gilbert Pilz <gilbert.pilz@oracle.com>, "public-ws-resource-access@w3.org"
<public-ws-resource-access@w3.org>
Subject
RE: [issue 6432] - a modest proposal
> Its only easy and works in the most simple, basic, non-extensbile,
limiting, non-future-looking,
put-your-customer-into-a-tiny-box-and-throw-away-the-key cases.
Doug,
I assume the above comment is directed at the many partners who have
successfully implemented, tested and interop?ed with Eventing (using mode)
in the real world, using the scenarios they require to do business. There
are currently 100?s of different implementations and millions of users
successfully using Eventing with ?mode?. There is no justification for
any of the above statements.
To turn things around, how many implementations of your proposed method
for Eventing are there at present? How much interop testing has there
been? Where is the proof that your proposal works in an interoperable way
for Eventing scenarios?
BTW: No one is suggesting that RM should be a mode, Doug.
Regards,
Geoff
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, May 14, 2009 5:47 PM
To: Geoff Bullen
Cc: Gilbert Pilz; public-ws-resource-access@w3.org
Subject: RE: [issue 6432] - a modest proposal
> Mode allows a way to ?select? from among a set of conflicting
alternatives easily
Its only easy and works in the most simple, basic, non-extensbile,
limiting, non-future-looking,
put-your-customer-into-a-tiny-box-and-throw-away-the-key cases. :-)
Take your example and pretend that WS-RM was invented after "Blue" Mode
URI and people want to use it with the Blue Mode. If both sides support RM
it should work right? Nope, using your method it won't because no one has
defined a new Mode URI. This gets back to one of my biggest problems with
Mode, its not scalable or composible unless there's some governing
authority willing to define all possible Mode URIs for all possible
combinations of extensions. Not gonna happen - or if it does I pitty the
people who will be willing to wait for that "totally non-political body"
to ever agree on which combinations are "valid". ha! Which means people
who use Mode will either be stuck with a pre-canned list of URIs/features
that will never be extended in any timely fashion, or everyone will
develop their own set of URIs and we'll have no interop. Neither of which
is very appealing.
Any new feature/extension will (or should) define something like Policy so
it can be advertised, this means that it'll automatically work with any
WS* spec that uses Policy to indicate what's supported. This means that
this new feature will automatically be able to be used with WS-E. Back to
the RM example - that TC is closed, who will define the Mode URI to
indicate that RM should be used to send the Notifications? Or that it can
be composed with Wu's Proxy feature? Or that RM can be composed with
anything? Its an interop and usability nightmare waiting to happen.
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.
Geoff Bullen <Geoff.Bullen@microsoft.com>
05/14/2009 07:53 PM
To
Gilbert Pilz <gilbert.pilz@oracle.com>
cc
Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org"
<public-ws-resource-access@w3.org>
Subject
RE: [issue 6432] - a modest proposal
Thanks for your feedback Gil,
> By your definition below ("The event source has only validated (via
interop testing) two possible combinations: A,B,C and A,B,D") the above
would be an invalid request.
Yes it would be invalid, but it would also be an impossible request to
make if you used mode, since mode only allows you to specify one such
option in a message. So one of the things that mode provides is an easy
mechanism to support mutually conflicting alternatives. If you add
optional elements (options available to all modes) to the mix it gets even
more complicated. Without mode, the code itself will need to work out what
options have been specified, determine if they are conflicting and if so
cause some kind of new fault (?conflicting options??) to occur.
Mode allows a way to ?select? from among a set of conflicting alternatives
easily.
--Geoff
From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
Sent: Thursday, May 14, 2009 12:10 PM
To: Geoff Bullen
Cc: Doug Davis; public-ws-resource-access@w3.org
Subject: Re: [issue 6432] - a modest proposal
Comments inline . . .
On 5/13/2009 2:46 PM, Geoff Bullen wrote:
Gil,
So what would this mean:
Example 1)
Header]
<som:UseBlue mustUnderstand="1"/>
<som:UseRed mustUnderstand="1"/>
[Body]
<wse:Subscribe>
<wse:NotifyTo>{some EPR}</wse:NotifyTo>
<som:Blue/>
<som:Red/>
</wse:Subscribe>
It depends upon the semantics defined by the authors of the Red and Blue
extensions. By your definition below ("The event source has only validated
(via interop testing) two possible combinations: A,B,C and A,B,D") the
above would be an invalid request.
And is the above different to:
Example 2)
Header]
<som:UseBlue mustUnderstand="1"/>
<som:UseRed mustUnderstand="1"/>
[Body]
<wse:Subscribe>
<wse:NotifyTo>{some EPR}</wse:NotifyTo>
</wse:Subscribe>
Again it depends upon how the extension authors defined these extensions.
If the extension is indicated solely by the presence of som:Blue or
som:Red in the Subscribe request, then the above request is different in
that it has not been extended. I would note that the creator of this
request is being foolish in that they are indicating that the receiver
must understand two extensions, neither of which are are actually needed
to process the request.
- gp
Thanks,
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
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
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] 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
>
>
Received on Saturday, 16 May 2009 00:03:23 UTC