- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Tue, 21 Apr 2009 06:10:14 -0600
- To: "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-request@w3.org
- Message-ID: <OF6EDB786E.F7D4DA24-ON8525759F.003CACC7-8525759F.0042DADC@us.ibm.com>
Wu,
This does not help me understand what Push means, and given that it is
defined as the default/implied
mode, that understanding seems to be fundamental to the correct
implementation of the specification.
A specification is supposed to provide an implementer with all of the
information needed to produce an
implementation. Clearly, there is something missing here because I have no
idea what "simple asynchronous
messaging" means. See Bob's note.
As to your point that @Mode was intended to enable resource constrained
devices to effectively bypass use
of some of the more advanced WS-* features, please help me understand
which of these features is needed to
implement Push.
Even in my most fevered dreams about what Push means, I fail to perceive a
need for anything more
advanced (beyond what WS-E already prescribes) than WS-Policy (to
advertise that Push is supported,
whatever that means) which requires almost no code on the part of the sink
(other than to return the policy
when asked). The policy itself can be quite compact. As for the source, it
requires a small amount of code to
ask for the policy and a trivial amount of code to affect policy
intersection to determine compatibility of the
two policies. The source could support a single policy alternative,
reducing the complexity of the intersection
code (which isn't very complex in any event).
You could even define a meta policy assertion that collapsed the semantic
of a given policy alternative to a
single assertion type such that intersection involved comparison of a
single XML element with some static
QName which is effectively what @Mode is attempting to do (but without an
underlying framework).
Even if I used WS-Man's PushWithAck as an example @Mode, my experience
tells me that the implementation
required to affect the behavior described (which is, again, somewhat
hand-wavy in its specificity, but I digress)
would not be much less than that required to implement a stripped down
version of WS-RM (to affect acks) and there
is nothing in the WS-RM spec to preclude the sink from simply discarding
and not acknowledging events that are not
sequential in their order so as to affect in-order delivery (which is what
PushWithAcks is attemping to achieve)
without requiring that the constrained device maintain a queue of
unprocessed messages while it waits for a gap to
be filled.
I could go on, but suffice to say that we designed WS-RM and many of the
other WS-* specs such that
even in the case of resource constrained devices, the protocols could be
effectively and efficiently implemented
to yield the desired functionality. If you have specific feedback that
this is not the case, I am sure that the
relevant TC/WGs would be interested.
Here's my main point. When there are more ways to affect the same
functionality, there is less interoperability.
It is that simple.
The W3C WS-Policy WG produced 2 Recommendations that enable a means of
enabling two endpoints to
communicate their capabilities and requirements to one another and
determine their mutual compatibility.
I maintain that @Mode is yet another, albeit limited, means of
accomplishing the same.
Why do we need two?
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:
Christopher B Ferris/Waltham/IBM@IBMUS
Cc:
"Asir Vedamuthu" <asirveda@microsoft.com>, "Li, Li (Li)" <lli5@avaya.com>,
<public-ws-resource-access@w3.org>,
<public-ws-resource-access-request@w3.org>
Date:
04/21/2009 01:19 AM
Subject:
RE: issue 6432 - yet another proposal
Sent by:
public-ws-resource-access-request@w3.org
Christopher,
My previous post was to point out, in addition to use other WS-*, WS-E
provides one simple solution in @Mode that can be used to deal with such
cases without requiring several other WS-* standards. Mode is implemented
in current WS-E implementations and used extensively in deployed
applications.
If "@Mode tells me nothing", then please don't use it. You can use
multiple WS-* to address the problem. But on resource limited devices and
for real-time communication, a simple and efficient solution without
dependency on multiple WS-* has its value.
Sorry, given the limited resources (cpu, memory) on the device and the
number of WS-* to implement for the required functions, it is absurd and
we should not make it even more absurd by mandatorily requiring more and
more WS-* for something as simple as eventing.
Thanks,
- Wu Chou.
Wu Chou, IEEE Fellow, Ph.D. | Director |Avaya Labs Research | AVAYA | 233
Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax:
908-696-5198 / 908-696-5401 | wuchou@avaya.com
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Monday, April 20, 2009 8:51 AM
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
Wu,
@Mode tells me nothing. The "Push" mode is especially vague in a
completely unspecified and hand-wavy sort of way. The alluded to, but
underfined "Wrap" mode is completely orthogonal to Push as it only speaks
to the format of the event, not the means by which it is
delivered/transferred from source to sink.
/s:Envelope/s:Body/*/wse:Delivery/@Mode
The delivery mode to be used for notification messages sent in relation to
this subscription. Implied value is "
http://www.w3.org/2009/02/ws-evt/DeliveryModes/Push", which indicates that
Push Mode delivery should be used. See 2.2 Delivery Modes for details.
If the event source does not support the requested delivery mode, the
request MUST fail, and the event source MAY generate a
wse:DeliveryModeRequestedUnavailable fault indicating that the requested
delivery mode is not supported.
Not much detail there. It tells me to go to section 2.2 for details...
let's see what that has to say. (Oh, note also that the spec only suggests
that an endpoint MAY respond with a wse:DeliveryModeRequestedUnavailable
fault. WOW is that ever helpful. Negotiation is almost guaranteed. NOT.
Note that faults are _generated_. They are not necessarily transferred,
and certainly not necessarily transferred to the origin of the message
that triggered the fault to be generated. Using faults as a means of
negotiation is, IMO, a poor design choice.)
On to section 2.2, which I will quote in its entirety so that no one
complains that I took anything out of context:
2.2 Delivery Modes
While the general pattern of asynchronous, event-based messages is
extremely common, different applications often require different event
message delivery mechanisms. For instance, in some cases a simple
asynchronous message is optimal, while other situations may work better if
the event consumer can poll for event messages in order to control the
flow and timing of message arrival. Some consumers will require event
messages to be wrapped in a standard "event" SOAP envelope, while others
will prefer messages to be delivered unwrapped. Some consumers may require
event messages to be delivered reliably, while others may be willing to
accept best-effort event delivery.
In order to support this broad variety of event delivery requirements,
this specification introduces an abstraction called a Delivery Mode. This
concept is used as an extension point, so that event sources and event
consumers may freely create new delivery mechanisms that are tailored to
their specific requirements. This specification provides a minimal amount
of support for delivery mode negotiation by allowing an event source to
provide a list of supported delivery modes in response to a subscription
request specifying a delivery mode it does not support.
This specification defines a single delivery mode, Push Mode, which is
simple asynchronous messaging.
As an example of a possible extension, a feature may allow a subscriber to
request that event messages be "wrapped" in a standard message. This
feature is requested by specifying a new delivery mode, e.g.
http://www.w3.org/2009/02/ws-evt/DeliveryModes/Wrap, in the Subscribe
request. Use of this delivery mode would indicate that notification
messages should be "wrapped". Similarly, this approach could be
generalized to allow the subscriber to provide other information regarding
their preferences for notification message delivery.
Would someone please explain where the precise definition of "simple
asynchronous messaging" is specified? The very concept of "simple
asynchronous messaging" is an oxymoron. Whatever it is, it isn't simple.
The subject of what constitutes "asynchronous messaging" has been the
source of much debate within the industry for years. It basically nets out
to "it depends on your perspective what that term means" [1]. I could dig
up reams of references from the WS-A WG discussion of the subject.
Certainly, a three word phrase does not do the subject justice. Someone
needs to define precisely what this mode means from an implementation
perspective or interop is more likely than not to be non-existant.
My point in my previous post was intended to point out that the WS-*
community _has already done this work_. It is manifested in the WS-Policy
1.5 Recommendations, and in the policy assertion vocabularies that have
been developed for it, including WS-Addressing. Why should WS-E, a
specification being developed by the very same group that is developing
WS-MEX which builds off of WS-Policy (amongst other specs) to further
enhance this system, clinging unnecessarily to its own ill-defined and
ill-conceived solution to the same problem domain?
For anyone to claim that this redundant and ill-defined feature needs to
be retained to preserve compatibility with previous implementations is
absurd.
[1] http://lists.w3.org/Archives/Public/www-ws-arch/2003May/0014.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:
"Chou, Wu (Wu)" <wuchou@avaya.com>
To:
Christopher B Ferris/Waltham/IBM@IBMUS
Cc:
"Asir Vedamuthu" <asirveda@microsoft.com>, "Li, Li (Li)" <lli5@avaya.com>,
<public-ws-resource-access@w3.org>,
<public-ws-resource-access-request@w3.org>
Date:
04/18/2009 01:27 AM
Subject:
RE: issue 6432 - yet another proposal
Sent by:
public-ws-resource-access-request@w3.org
I am glad to see your example. It points exactly to the issue: EPR of
WS-Addressing (WS-A) alone is not sufficient in MC case, and it is not
sufficient for many other use cases as well, e.g. use case of your
example, our delivery through proxy case, MC case, and many other use
cases pointed by Asir in
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0132.html
.
When looking at other potential WS-* standards for help, we should not
overlook what has already been provided in WS-E specs, as well as many
deployed WS-E applications and use cases that follow the WS-E specs to
deal with the similar situation.
In particular, the Mode attribute of Delivery in WS-E specs is for the
subscriber to specify the additional critical requirements for event
delivery. It is part of the WS-E semantics to critically support these
applications. It is a simple and light weight solution without requiring
other WS-* standards. It specifies: if event source does not support the
requested event delivery as specified by the Mode attribute of Delivery,
it should fault the event subscription with "
wse:DeliveryModeRequestedUnavailable fault indicating that the requested
delivery mode is not supported".
Thanks
- Wu Chou.
Wu Chou, IEEE Fellow, Ph.D. | Director |Avaya Labs Research | AVAYA | 233
Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax:
908-696-5198 / 908-696-5401 | wuchou@avaya.com
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Monday, April 13, 2009 4: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, 21 April 2009 12:11:09 UTC