Re: issue 6432 - yet another proposal

Then it sounds like that "Asynchronous" word can be safely deleted.
-bob

On Apr 21, 2009, at 2:46 PM, Li, Li (Li) wrote:

> Bob,
> These are good questions. Without being bogged down to technical  
> details, can we say:
>
> Asynchronous message refers to messages which are transmitted  
> without coordination in time.
> For example, the interval between transmitting message A and B is  
> not the same as the interval between transmitting B and C.
>
> Thanks,
> Li
> From: Bob Freund [mailto:bob.freund@hitachisoftware.com]
> Sent: Monday, April 20, 2009 9:21 AM
> To: Christopher B Ferris
> Cc: Chou, Wu (Wu); 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
>
> +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
>
>
>
>
>
>
>
>
>
>