- From: Bob Freund <bob.freund@hitachisoftware.com>
- Date: Mon, 20 Apr 2009 09:20:30 -0400
- To: Christopher B Ferris <chrisfer@us.ibm.com>
- Cc: "Chou, Wu (Wu)" <wuchou@avaya.com>, 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: <D08542B1-9FA9-4EEB-9DC5-D60CCDE0F3BB@hitachisoftware.com>
+1 to Chris on the "simple asynchronous message" point.
we spent many hours hashing this over during WS-A.
One of the first sub-issues on this is "Asynchronous" with respect to
what?
I am guessing that it does not mean asynchronous with respect to event
occurrence.
Does it mean asynchronous with respect to a request message?
This is hard to clearly understand since event messages occur only if
they have been subscribed-to. The subscribe message is certainly a
request for events. There is no limitation in WS-A that there be only
one response to a request.
Does it mean Asynchronous with respect to some underlying transport
mechanism?
Messages that are returned on connections established by polling
mechanisms might be thought of as occurring asynchronously with
respect to an underlying polled transport.
Does it mean that the message is not sent as part of an http reply?
http, being a special case of transport means has the characteristic
of a back-channel implicit reply mechanism. Is this definition bound
only to implementations that use http as a transport mechanism?
Since synchrony can only be established based on some stream of events
and a relationship to that stream (which might be one to one, or one
to many), and a definition of a definite range of temporal
relationships to that stream; asynchrony is defined by the failure of
that set of relationships.
Or does it simply mean that you really don't now when it will occur?
Does that suggest that there is an implicit expectation of the nature
of the underlying transport?
Perhaps a better term might be considered.
thanks
-bob
On Apr 20, 2009, at 8:50 AM, Christopher B Ferris wrote:
> 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
>
>
>
>
>
>
>
>
>
>
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 20 April 2009 13:21:15 UTC