- From: Doug Davis <dug@us.ibm.com>
- Date: Mon, 13 Apr 2009 22:16:32 -0600
- To: public-ws-resource-access@w3.org
- Message-ID: <OF9DB455BC.758558B3-ON85257598.001594FB-85257598.00177EE3@us.ibm.com>
Comments inline. However, I wish we wouldn't mix issues.
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
04/13/2009 07:20 PM
To
Christopher B Ferris/Waltham/IBM@IBMUS, "Chou, Wu (Wu)" <wuchou@avaya.com>
cc
Asir Vedamuthu <asirveda@microsoft.com>, "Li, Li (Li)" <lli5@avaya.com>,
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>,
"public-ws-resource-access-request@w3.org"
<public-ws-resource-access-request@w3.org>
Subject
RE: issue 6432 - yet another proposal
Chris,
> and the Event source had no capacity for sending events via the FTP
protocol, how would that be different than the MC case that you assert
requires some special extensions to an endpoint that does not understand
MC?
Let?s just focus at the above issue for a moment.
In the original submission, Eventing defined PUSH mode, which defined
functionality that specifically stated that the event source had to send
one-way messages to the event sink. The default mode, as expressed in the
Eventing spec, was PUSH mode. I hope we agree on that.
<dug> only 'sort of' true. One of the problems with WS-E (submission and
now) is that it talks about notifications being one-ways but one of the
first users of WS-E (meaning wsman) violates this rule by defining
notifications as two-ways. So, I'm not sure which is wrong, ws-e or wsman
since taken together there's an inconsistency. </dug>
We believe a common definition for PULL mode (as inferred from the
original submission) would be that the event sink would communicate to the
event source, using a request/response message,
<dug> not true - in fact the submission is silent on this so the
'assumption' that Pull is done this way (either using a new Mode or as a
request/response) is a myth. </dug>
in order to get (pull) the next event notification from the event source.
This involves not only the concept of defining a two way message to
accomplish this, but also involves significant new work by the event
source to store events for future retrieval (with subsequent
implementation details around retention time, etc). I hope we can agree
on that.
<dug> nope sorry - its just not true. Do a search for 'pull' and you'll
find nothing </dug>
In the current incarnation of the proposal for 6432, PUSH mode has been
changed to EPR mode and the meaning of mode is now somewhat blurred.
<dug> actually, its not blurred. It more accurately reflects what's going
on - the messages are sent to the specified EPR. Since EPRs can be used
for Push or Pull, the term "Push" is an out-of-date term and misleading at
best. </dug>
EPR mode could be PUSH or it could be PULL, depending on the EPR that is
placed in NotifyTo. <du> making my point - and this is true regardless of
the adoption of my proposal since even w/o my proposal you can still use
MC.</dug>
The original concept of the default mode for an event source has now
changed from ?always send a one way message? to be ? look at NotifyTo to
determine whether it is PUSH or PULL.
<dug> Yes - which is the way it should be. Compare NotifyTo with EndTo
and from a soap/wsa/messaging infrastructure you should see no difference.
In both cases you need to identify where messages are to be sent. If
Mode isn't needed for EndTo then I'm failing to see why they're needed for
Notifications. If you look at WSMan, where they defined a Pull mode, they
had to drop a key piece of functionality just to make it 'sort of' work.
In WSMan you _can not_ get the SubscriptionEnd message in Pull mode. This
means that they don't think people need to know this information in Pull
mode - which makes no sense to me. Either people will want to know a
subscription was prematurely terminated or not - regardless of the mode.
<dug>
Note that underlying all of this, there is still a concept of PUSH and
PULL because even in the new proposal if the event source does not
understand MC then it will still try to PUSH messages to the EPR in
NotifyTo. So now we have two concepts, both called mode, both of which are
states that the event source has to understand:
1. Do I look at the NotifyTo EPR to determine what to do? (the
proposal calls this mode)
2. Do I send out one way messages, or do I wait till the event sink
contacts me? (the proposal has no explicit name for this, maybe it?s an
internal mode)
Both of these require code to implement (PULL mode requires substantial
code on top of just supporting MC). In the current proposal, 1. is
handled through the mode attribute, 2. is handled by parsing the EPR. I
hope we can agree on that as well.
<dug> Again, why should the sending of Notifications be any different than
sending the SubscriptionEnd, Replies, Acks.... anything else? No one has
yet given a good reason why notifications need to be different from every
other WS-* spec that needs to send a message. </dug>
No matter which way you do things, the event source needs to keep the
state of, and run very different code paths, based on if it is handling
the PUSH or the PULL concept. The event source does not really need to
keep the state of mode = EPR, as described in the proposal, past the point
at which it has parsed to NotifyTo EPR. I hope we can agree on that as
well.
<dug> There something here that you're missing. If WS-E follows the same
path as every other WS-* spec then it can reuse the same
WSA/EPR/message-sending logic. As currently written WS-E needs to have
specialized logic to not only deal with a NotifyTo EPR but it also has to
have additional logic to deal with mode. Why shouldn't an implementation
be able to reuse the same code for sending Notifications as it does for
_every other_ soap message? </dug>
So, my first point revolves around if we need both of these ?mode?
definitions.
<dug> No, all you need is the EPR and then you can reuse the same code
from all other ws-* specs</dug>
If the mode attribute simply had the values PUSH and PULL as in the
submitted spec (rather than EPR), then the code would already understand
the context of what should be in the NotifyTo EPR. If the right type of
address is not in the EPR, then it can complain with a fault. The concept
of an ?EPR mode flag? is not required to achieve this and appears
redundant.
My second point revolves around the question you ask that I quoted at the
top of this email - why is one EPR (say one based on FTP) different from
another (say one based on MC). My answer is that the intent is
different. If the mode = PUSH then the EPR in the NotifyTo is an address
I need to send one-way messages to. If mode = PULL then the EPR better be
something (like MC) that I can use to make PULL mode happen. So what does
this mean in reality?
a) Submitted Version: if the event source does not implement PULL
mode, and receives a PULL mode attribute, it returns a fault. Current
Proposal: If event source does not understand MC (which now sets the
internal mode to PULL) then it can?t create a fault for it, assumes it?s a
PUSH mode EPR and at some point tries to send one-way messages to it and
silently fails.
b) Submitted Version: if mode = PUSH, the event source will try to
interpret NotifyTo as an address and send messages to it. This is your
FTP case above. Current Proposal: if mode = EPR and MC is not
implemented, the same thing will happen. In this case you are right,
there is no difference.
c) If client wants to PULL, Submitted Version: if mode = PULL and
NotifyTo is not MC then a fault can be generated (fat fingers). Current
Proposal: if mode = EPR and NotifyTo is not MC, then event source will set
internal mode to PUSH and silently fail.
d) If client wants to PUSH, Submitted Version: if mode = PUSH and an
MC is provided (and event source supports MC) then a fault can be
generated. Current Proposal: if mode = EPR and MC is implemented, then
the event source will set internal mode to PULL and silently fail.
There are clearly cases (a, c, d) where if we were to use a mode =
PUSH/PULL (Submitted Version) concept the results in terms of error
handling are certainly different and, we contend, much better than using
mode = EPR (Current Proposal).
<dug> sigh - let's not mix issues and all of this has been said and
answered before </dug>
My third point revolves around extensibility. It is likely that any PULL
mode implementation will require some extra elements inside the delivery
element (maybe time to keep events on the queue or something like that).
Using the Submitted Version method, any extensions that are placed inside
the delivery element can be related to the intended mode of operation,
based on the mode (PUSH and PULL) defined by the delivery element and the
event source can interpret them in that context. Using the new method
this is not true. For example, if I do not understand MC, but have extra
elements inside of the delivery element, then these elements will be
accidentally interpreted as PUSH mode extensions rather than PULL mode
extensions as intended.
<dug> but either way you'd ignore them so I don't understand the concern
</dug>
Basically we think that the value of mode should represent the
functionality the event sink is expecting the event source to provide, not
some esoteric concept associated with where the event source has to now
look to find out what functionality the event sink really wants. Our
proposal is, as it has always been, that there is no need to change the
value of the mode attribute from being PUSH (and PULL) to EPR. There
appears no good reason to do so, and we believe there are a number of
technical reasons why the status quo is actually better and more concise.
We are fine with MC being one potential implementation of PULL mode.
<dug>You're ok with MC as one option - good.
However (breaking my own rule by continuing with the mixing of issues :-),
I still think you need to explain why NotifyTo and EndTo are fundamentally
different. Why does one need mode but not the other? </dug>
--Geoff
From: public-ws-resource-access-request@w3.org
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Christopher
B Ferris
Sent: Monday, April 13, 2009 1:13 PM
To: Chou, Wu (Wu)
Cc: Asir Vedamuthu; Li, Li (Li); public-ws-resource-access@w3.org;
public-ws-resource-access-request@w3.org
Subject: RE: issue 6432 - yet another proposal
If the subscriber sent the following:
<wse:Subscribe>
<wse:Delivery>
<wse:NotifiyTo>
<wsa:Address>ftp://example.org/sockittome/
</wsa:Address>
</wse:NotifyTo>
</wse:Delivery>
</wse:Subscribe>
... and the Event source had no capacity for sending events via the FTP
protocol, how would that be different than the MC case that you assert
requires some special extensions to an endpoint that does not understand
MC?
If the subscriber required 2048bit encryption of the event content and
WS-Security was not supported by the source, is that different?
Of course not. Some means of achieving mutual compatibility of the
requirements of the sink with the capabilities of the source is needed
in order to enable effective composition of the various WS-* specs.
The W3C WS-Policy WG spent the better part of 18 months producing the
WS-Policy 1.5 Framework and Attachments Recommendations
for just this use case - and lo and behold, WS-MC even defined a policy
assertion vocabulary (as did WS-A and WS-Sec). Let's not
pretend that none of that happened - after all, this is the same working
group that is producing WS-MEX, which is designed to
enable exchange of the policy and other metadata of an endpoint, is it
not?
Cheers,
Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986
From:
"Chou, Wu (Wu)" <wuchou@avaya.com>
To:
"Asir Vedamuthu" <asirveda@microsoft.com>
Cc:
<public-ws-resource-access@w3.org>, "Li, Li (Li)" <lli5@avaya.com>
Date:
04/13/2009 02:27 PM
Subject:
RE: issue 6432 - yet another proposal
Sent by:
public-ws-resource-access-request@w3.org
It is a good idea to have a paper that explains how WS-MakeConnection (MC)
composes with WS-Eventing and how it interworks with other WS-Addressing
(WS-A)/WS-Eventing (WS-E) endpoints that do not support MC. We will also
be interested to contribute to such a paper.
One particular question is: WS-A 1.0 Core specifies: "Comparison of
[destination] property values is out of scope, other than using simple
string comparison to detect whether the value is anonymous, that is, where
[destination] has the value http://www.w3.org/2005/08/addressing/anonymous
."
>From WS-A Core, it seems that some extension from WS-A implementation is
needed in order to detect and understand the special MC anonymous EPR. If
such extension is beyond the mandatory features of a WS-A endpoint, it
would make sense to specify it as out-of-band to avoid additional
requirements on a regular WS-A endpoint implementation.
The concern is: if the WS-A implementation cannot identify the special MC
anonymous EPR by the simple string comparison as specified in WS-A 1.0
Core, it might treat the the special MC EPR as a regular EPR, and accept
the event subscription to send events to it (MC anonymous EPR). If that
happens, it could cause a major problem and the events won't be able to
deliver.
To be concrete, assume there is an event source that understands WS-E and
WS-A, but does not support MC. When the event subscriber sends a Subscribe
message using the MC extension:
<wse:Subscribe>
<wse:Delivery>
<wse:NotifiyTo>
<wsa:Address>http://docs.oasis-open.org/ws-718
rx/wsmc/200702/anonymous?id=550e8400-e29b-11d4-a716-446655440000
</wsa:Address>
</wse:NotifyTo>
</wse:Delivery>
</wse:Subscribe>
The event source checks the <wse:NotifyTo> EPR according to WS-A and
decides it is neither ?http://www.w3.org/2005/08/addressing/anonymous? nor
?http://www.w3.org/2005/08/addressing/none? . Then it assumes it is an
addressable EPR and will deliver notifications to it, which of course will
fail.
This means using EPR alone to indicate MC style delivery will put an event
source in one of the two situations:
1) The event source can be hit by a latent error because it does not
recognize MC.
2) To avoid the latent error, the event source has to recognize the MC
extension, even though it does not support MC.
- Wu Chou.
From: Asir Vedamuthu
Sent: Friday, April 10, 2009 5:00 PM
To: Christopher B Ferris
Cc: public-ws-resource-access@w3.org
Subject: RE: issue 6432 - yet another proposal
> Any event sink would be foolish to engage in MC interchange with
> an event source that did not advertise MC support in its policy.
Using WS-MakeConnection policy assertion to indicate the use of
WS-MakeConnection protocol is possible. Earlier in the same mail thread
[1], we mentioned that tiny subscribers are resource-challenged and may
not have access to or may not understand metadata.
Anyway, such usages are outside the scope of WS-Eventing and should work
with out-of-band agreements (and such agreements can be represented as a
policy assertion).
Having said that, the Working Group should consider authoring a paper that
explains how WS-MakeConnection composes with WS-Eventing using Doug?s
quoted sample as a starting point. We will be happy to help.
[1]
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0027.html
Regards,
Asir S Vedamuthu
Microsoft Corporation
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, April 09, 2009 6:32 AM
To: Asir Vedamuthu
Cc: public-ws-resource-access@w3.org
Subject: RE: issue 6432 - yet another proposal
Asir,
It says that comparison of destination properties is out of scope. It does
not say that it is disallowed. The reason that that
statement is there is because URI comparison is non-trivial when you take
into consideration all of the possible permutations
of encodings that might be used. Many specs have deferred to
straight-forward string comparison as a means of side-stepping
the complexity.
As for your implied assertion that _all_ implementations need to
understand MC, that is ludicrous. No one has suggested that, nor is it
necessary. Why do you think we spent all that time developing WS-Policy?
MC has a policy assertion. Any event sink would be
foolish to engage in MC interchange with an event source that did not
advertise MC support in its policy.
Cheers,
Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986
From:
Asir Vedamuthu <asirveda@microsoft.com>
To:
Christopher B Ferris/Waltham/IBM@IBMUS, "public-ws-resource-access@w3.org"
<public-ws-resource-access@w3.org>
Date:
04/08/2009 11:08 PM
Subject:
RE: issue 6432 - yet another proposal
A WS-Addressing-aware implementation or library is NOT required to run
character by character comparison to infer that a WS-MakeConnection
extension is required to speak with an Event Sink.
?Comparison of [destination] property values is out of scope, other than
using simple string comparison to detect whether the value is anonymous,
that is, where [destination] has the value "
http://www.w3.org/2005/08/addressing/anonymous".? [1]
An Endpoint Reference with encoded special semantics (WS-MakeConnection
URI) ONLY makes sense IFF both sender and receiver understand the special
semantics. This means, an Event Source (that is unaware of
WS-MakeConnection) will not issue a fault that the Event Source does not
understand the special semantics encoded in an Endpoint Reference.
What is the justification to require all WS-Eventing implementations to
recognize WS-MakeConnection URI?
[1]
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#msgaddrpropsinfoset
Regards,
Asir S Vedamuthu
Microsoft Corporation
From: public-ws-resource-access-request@w3.org [
mailto:public-ws-resource-access-request@w3.org] On Behalf Of Christopher
B Ferris
Sent: Wednesday, April 08, 2009 1:29 PM
To: public-ws-resource-access@w3.org
Subject: Re: issue 6432 - yet another proposal
Jeff is correct. Opacity is not a quality of an URI. It is a principle:
you should not infer anything from the
structure (or the content) of the path component of the URI. Note the use
of the word "should" - I'll come back to that
later.
For instance, just because an URI ends in .pdf does NOT mean that the
client/agent that uses that URI in a GET
should expect to receive an application/pdf media type in the response
entity body.
So, repeat after me, opacity is not a quality, it is a principle. One URI
is neither more, nor less "opaque" than another.
Period.
Now, what Asir may be alluding to is that the MC Anon URI is constructed
from a URI template:
http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=
{unique-String}
Here's where the opacity principle can be ignored: when the URI authority
provides explicit information as to how to
interpret the structure of the URI, as the WS-Make Connection spec [1]
does. One can do a character for character
match of the string
http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=
If it matches the first 58 characters of another URI, then that (other)
URI is a MCanon URI.
I refer you to the TAG finding that specifies that such practice is just
fine thank-you very much [2] (3nd bullet in conclusions section):
"* Assignment authorities may publish specifications detailing the
structure and semantics of the URIs they assign. Other users of those URIs
may use such specifications to infer information about resources
identified by URI assigned by that authority."
[1]
http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.1-spec-os.html#_Toc162743905
[2] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061204.html
Cheers,
Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986
From:
Jeff Mischkinsky <jeff.mischkinsky@oracle.com>
To:
Yves Lafon <ylafon@w3.org>
Cc:
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>
Date:
04/08/2009 03:16 PM
Subject:
Re: issue 6432 - yet another proposal
Sent by:
public-ws-resource-access-request@w3.org
hi,
My understanding of the use of "opaque" wrt to URI's is that you
are not supposed to infer anything from the structure of the URI, not
that specific uri's don't have specific "meanings"/semantics as
defined in specs.
Otherwise it is totally meaningless to define a uri and give it
semantics.
So this argument and asir's response don't make sense to me. You can
certainly tell that the 2 uri's in question are different and you can
certainly know what the semantics of using them are. So i don't see a
problem.
-jeff
On Apr 08, 2009, at 2:34 AM, 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.
>
>
> --
> Baroula que barouleras, au tiéu toujou t'entourneras.
>
> ~~Yves
>
>
--
Jeff Mischkinsky jeff.mischkinsky@oracle.com
Director, Oracle Fusion Middleware +1(650)506-1975
and Web Services Standards 500
Oracle Parkway, M/S 2OP9
Oracle Redwood Shores, CA 94065
Received on Tuesday, 14 April 2009 04:17:23 UTC