- From: David Snelling <David.Snelling@UK.Fujitsu.com>
- Date: Tue, 31 Mar 2009 20:31:00 +0100
- To: Gilbert Pilz <gilbert.pilz@oracle.com>
- Cc: "Chou, Wu (Wu)" <wuchou@avaya.com>, Katy Warr <katy_warr@uk.ibm.com>, Doug Davis <dug@us.ibm.com>, Asir Vedamuthu <asirveda@microsoft.com>, Bob Freund <bob.freund@hitachisoftware.com>, "Li, Li (Li)" <lli5@avaya.com>, public-ws-resource-access@w3.org
- Message-Id: <6ED79F02-5B33-47A0-AE52-912771A03F05@UK.Fujitsu.com>
Gilbert,
When I clicked on the kitten link, what kind of virus did you install
on my machine?
On 31 Mar 2009, at 20:21, Gilbert Pilz wrote:
> I'm sorry, but the hyperbole is getting a bit deep around here.
> "Fundamentally change the semantics of event delivery in WS-E"?
> How?!? It's an extension point (and a redundant one at that)!
> Extension points, by their definition, are not allowed to
> "fundamentally change the semantics" of anything!
>
> If we're just going to trade wildly exaggerated, unsubstantiated
> claims, I claim that, every time "Mode" is used, one of these
> kittens is killed. Clearly we need remove "Mode" before any more
> such innocent creatures are harmed!
>
> - gp
>
> Chou, Wu (Wu) wrote:
>>
>> Katy,
>>
>> wse:Mode attribute in WS-E is just an extension point to allow a
>> subscriber to specify the required type of the push mode event
>> delivery. The importance of having Mode attribute in Delivery of WS-
>> E is that the event source have to fully understand/support the
>> extension in the Mode attribute; otherwise it must fault the event
>> subscription with a standard wse:DeliveryModeRequestedUnavailable
>> fault. These are semantics defined in WS-E specs, not from EPR.
>>
>> I am not convinced that EPR solves everything, including Internet
>> routing, etc. Removing Mode attribute is going to fundamentally
>> change the semantics of event delivery in WS-E. This is a protocol
>> change that can impact many applications and implementations. This
>> is not a case of removing redundancy in the specs.
>>
>> - Wu Chou
>> From: Katy Warr [mailto:katy_warr@uk.ibm.com]
>> Sent: Tuesday, March 31, 2009 9:43 AM
>> To: Chou, Wu (Wu)
>> Cc: Gilbert Pilz; Doug Davis; Asir Vedamuthu; Bob Freund; Li, Li
>> (Li); public-ws-resource-access@w3.org
>> Subject: Fw: [Bug 6692] New: Remove Mode from the specification
>>
>>
>> Wu
>>
>> I agree with Gil's point below.
>>
>> Also, using a wse:Mode to indicate the proxy is a horrible design.
>> There are a number of ways that an EPR could be targeted at an
>> address through a proxy. Typically, the EPR's <address> might be
>> that of the proxy and the proxy itself would perform a mapping to
>> the target. If the proxy didn't hold this mapping, you could also
>> embed the real EPR within the proxy one so it flowed as a reference
>> parameter for the proxy to process. That would be a non-standard
>> solution but no less standard than the
>> 'wse:Mode=urn:push_thru_proxy' that you are advocating as an
>> alternative. And at least it the EPR solution solves the problem
>> for all EPRs (and not just WS-Eventing NotifyTos).
>>
>> As has been stated already - the addressing layer deals with
>> delivery of messages and we don't need to re-invent this function.
>> Why would we want to duplicate this in the Eventing spec (and not
>> in others)? And if we duplicate this function, what happens if the
>> wse:mode contradicts what's in the notifyTo EPR?
>>
>> Katy
>>
>> ----- Forwarded by Katy Warr/UK/IBM on 31/03/2009 13:59 -----
>> From: Gilbert Pilz <gilbert.pilz@oracle.com>
>> To: "Chou, Wu (Wu)" <wuchou@avaya.com>
>> Cc: Doug Davis <dug@us.ibm.com>, Asir Vedamuthu <asirveda@microsoft.com
>> >, Bob Freund <bob.freund@hitachisoftware.com>, "Li, Li (Li)" <lli5@avaya.com
>> >, member-ws-resource-access@w3.org, public-ws-resource-
>> access@w3.org, public-ws-resource-access-request@w3.org
>> Date: 31/03/2009 07:15
>> Subject: Re: [Bug 6692] New: Remove Mode from the
>> specification
>>
>>
>>
>> Wu,
>>
>> I'm confused by your "out-of-band-proxy" use case. If the agreement
>> to use a proxy is truly "out of band", how can it appear in the
>> wse:Subscribe message which is, be definition, a message sent from
>> the Subscriber to the Event Source?
>>
>> - gp
>>
>> Chou, Wu (Wu) wrote:
>> Doug,
>>
>> Many thanks for your comments. Let's separate the concerns and
>> focus on each thread.
>>
>> 1) Keep Mode attribute of Delivery in WS-E: The use case is to
>> establish legitimate critical applications based on Mode
>> attribute of Delivery in WS-Eventing. It should not remove Mode
>> from the WS-E specs, because it will affect and break the protocol
>> used by existing applications and implementations.
>>
>> 2) EPR usage patterns: Let's definitely find sometime to discuss
>> EPR extensions, and I will follow up with you on that.
>>
>> My thinking is: EPR can do many things but not everything. In our
>> "out-of-band proxy" use case, the NotifyTo EPR is exactly the same
>> for both cases, no matter it needs to go through the proxy or not,
>> e.g. " http://avaya.com " . The out-of-band proxy can be opaque
>> to the subscriber, e.g. a between enterprise IT 's agreement. The
>> event source cannot differentiate two different event delivery
>> modes just from the EPR in NotifyTo. And this is where the Mode
>> attribute of Delivery in WS-E becomes critical.
>>
>> It is possible to put <ext:Proxy> as part of the NotifyTo EPR. But
>> it is not all clear what event source should do to it. EPR alone
>> does not provide the declarative semantics to event source on how
>> it should treat <ext:Proxy>. For example, <ext:Proxy> should not be
>> interpreted as reference parameters of the sink, because it is the
>> EPR of the routing proxy which is a separate resource entity.
>>
>> By the opaque rule recommendation of EPR, event source should copy
>> NotifyTo EPR and send the event back. But this will not work here.
>> In order to deliver event correctly, the event source must do some
>> "deep" semantic analysis of the EPR , and derive from the EPR the
>> semantic action that it has to perform - must deliver the events
>> through <ext:Proxy> to the sink. If it cannot do that, it must
>> fault the subscription. This is where the Mode attribute of
>> Delivery in WS-E is needed as described in our use case.
>>
>> Regards,
>>
>> - Wu Chou
>>
>> From: Doug Davis [mailto:dug@us.ibm.com]
>> Sent: Monday, March 30, 2009 2:45 PM
>> To: Chou, Wu (Wu)
>> Cc: Asir Vedamuthu; Bob Freund; Li, Li (Li); member-ws-resource-access@w3.org
>> ; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
>> Subject: RE: [Bug 6692] New: Remove Mode from the specification
>>
>>
>> Wu,
>> your use-case is a very interesting one. It shows one of the key
>> points that I've been trying to make - this isn't specific to WS-
>> Eventing. The need to send a message through a proxy (and have
>> that proxy be defined by someone other than the sending endpoint -
>> the subscriber in your case) could be just as meaningful to any
>> EPR. For example, this could be needed for uses of wsa:ReplyTo, or
>> the registrationEPR in WSTX, or the AcksTo EPR in RM. In all of
>> these cases I believe this can be done by doing pretty much what
>> you've done below. That is, provide the ultimate destination within
>> the NotifyTo EPR but then use some extension mechanism to say "use
>> a proxy". In this particular case I would suggest that you define
>> an extension for the EPR structure - then this can be reused in
>> _all_ WS-* specs. For example:
>> <wse:NotfyTo>
>> <wsa:Address> http://avaya.com </wsa:Address>
>> <ext:Proxy> http://myproxy.com </ext:Proxy>
>> </wse:NotifyTo>
>> You can then also define a mU header that would require it to
>> verify that it will adhere to the extension. IMO, this will not
>> only satisfy your WS-Eventing needs but allow for this useful
>> extension to be reused in lots of places. I'm not keen on creating
>> one-off type of solutions just for certain WS-* specs - I think its
>> a much better design to create reusable components. For example,
>> should RM create a "use a proxy" extension too for its EPRs?
>> Probably not when the above seems to work just fine for both specs.
>>
>> Its also worth pointing out that reusing the extensibility points
>> of EPRs is actually a far cleaner design. In the example you gave
>> it looks like the pub/sub code will need to understand this
>> extension. While that is a valid choice, it would be much less work
>> for developers to have this information encapsulated within the EPR
>> itself. Then as this information is moved through a system only
>> one data structure needs to be passed around - the EPR - and the
>> pub/sub code might never actually need to know about this extension
>> at all. In your model below they would need to pass around an EPR
>> as well as the proxy information. And then when the next extension
>> comes along they'll need to add yet another. That a potentially
>> large code change each time. If, instead, they just knew about the
>> EPR structure then no code changes will be needed except down at
>> the transport layer of the product - where it should be. At that
>> point they can examine all of the bits of the EPR (including the
>> proxy info) and take whatever steps are necessary. This allows for
>> an implementation to be designed such that it isolates itself from
>> areas of concern that are of no consequence to it.
>>
>> 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.
>>
>> "Chou, Wu (Wu)" <wuchou@avaya.com>
>> Sent by: public-ws-resource-access-request@w3.org
>> 03/30/2009 02:12 PM
>>
>>
>> To
>> <public-ws-resource-access@w3.org>, <member-ws-resource-
>> access@w3.org>
>> cc
>> "Asir Vedamuthu" <asirveda@microsoft.com>, "Bob Freund" <bob.freund@hitachisoftware.com
>> >, "Li Li" <lli5@avaya.com>
>> Subject
>> RE: [Bug 6692] New: Remove Mode from the specification
>>
>>
>>
>>
>>
>>
>>
>>
>> +1
>> Asir: Many thanks for sharing your thoughts on this issue. And I
>> attach one of our use cases of Mode in WS-E Delivery below.
>>
>> - 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
>>
>> ------Use Case of MODE in WS-E Delivery -----
>>
>> Here is a concrete use case where the subscriber requests the
>> event source to push the event notifications through a proxy,
>> obtained either through an out-of-band channel (not specified in
>> the Subscribe request, e.g. the enterprise registers a special
>> event notification proxy with the service provider) or dynamically
>> specified in the Subscribe request. Certainly this behavior cannot
>> be conveyed by the wse:NotifyTo. This critical use case thus
>> justifies the need for the Mode attribute in WS-E Delivery.
>> To indicate the use of an out-of-band proxy, the Subscribe request
>> body looks like this:
>>
>> <wse:Subscribe>
>>
>> <wse:Delivery Mode=”urn:push_thru_proxy” >
>>
>> <wse:NotifyTo>…</wse:NotifyTo>
>>
>> </wse:Delivery>
>>
>> </wse:Subscribe>
>>
>> To indicate the use of a dynamic proxy, the Subscribe request body
>> looks like this:
>>
>> <wse:Subscribe>
>>
>> <wse:Delivery Mode=”urn:push_thru_proxy” >
>>
>> <wse:Notifyto>…</wse:Notifyto>
>>
>> <ext:Proxy>…</ext:Proxy>
>>
>> </wse:Delivery>
>>
>> </wse:Subscribe>
>>
>> "Mode=urn:push_thru_proxy" cannot be put into the Delivery
>> extension. This is because if the source cannot support
>> "push_thru_proxy", it must fault as defined by Mode in Delivery,
>> and the subscriber expects a standard
>> wse:DeliveryModeRequestedUnavailable fault. And there is no
>> standard WS-E fault for items in the Delivery extension.
>>
>> ----------
>>
>>
>> From: Asir Vedamuthu <asirveda@microsoft.com>
>> Date: Sun, 29 Mar 2009 19:59:23 -0700
>> To: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org
>> >
>> Message-ID: <D46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7@NA-EXMSG-C118.redmond.corp.microsoft
>> >
>> Last week, on the WG conference call, I mentioned that we will
>> provide some clarity on the concept of delivery mode (in WS-
>> Eventing) and related use cases.
>>
>> Delivery mode [1] provides a subscriber with a mechanism to specify
>> the means by which an event is delivered. Delivery mode is
>> represented as a URI in a Subscribe message [2]. The semantics
>> indicated by a delivery mode are:
>>
>>
>> 1) Rules for the delivery of events
>>
>> a) Semantics and lifecycle of a Notification delivery
>>
>> b) Message Exchange Pattern used (One-way, Request-Response, etc.)
>> and how the delivery mode binds to those Message Exchange Patterns
>>
>> c) Format of a response (if any)
>>
>> d) Configuration parameters or context data (if any) to support
>> the Message Exchange Pattern
>>
>> e) Rules for the delivery or other disposition of faults generated
>> during a Notification delivery
>>
>> 2) Delivery mode specific protocol information (if any) to
>> guarantee interop
>>
>> 3) Supported delivery formats.
>>
>> Some portion of the above semantics are captured by an EPR, in a
>> machine-readable form, but certainly not all. So, there is value
>> added by a formal mechanism to indicate a delivery mode.
>>
>> The delivery mode is an extension point in WS-Eventing. The WS-
>> Eventing specification defines a single built-in delivery mode,
>> Push Mode. Other delivery modes may be important for external
>> groups or other W3C Working Groups and are delegated to those
>> groups. This is similar to SOAP Bindings. The W3C XML Protocol WG
>> defined SOAP Protocol Binding Framework as an extension point and a
>> concrete binding, SOAP HTTP Binding (is also identified using a URI
>> [3]). Other groups defined SOAP bindings such as SOAP-over-JMS and
>> SOAP-over-UDP.
>>
>> The DMTF WS-Management WG defined three new delivery modes [4] and
>> these delivery modes have been widely adopted.
>>
>> Furthermore, based on the WS-RA WG charter [5], the WG deliverables
>> need to satisfy the following requirements as well:
>>
>>
>> 1) Charter scope - "Mechanisms to allow a subscriber to specify
>> the means by which an event is delivered and the definition of a
>> push-based delivery mode".
>>
>> 2) Charter scope - "In order to avoid disrupting the
>> interoperability of existing implementations, WS-MetadataExchange<http://www.w3.org/Submission/2008/SUBM-WS-MetadataExchange-20080813/
>> >, WS-Transfer<http://www.w3.org/Submission/2006/SUBM-WS-Transfer-20060927/
>> >, WS-Eventing<http://www.w3.org/Submission/2006/SUBM-WS-Eventing-20060315/
>> > and WS-Enumeration<http://www.w3.org/Submission/2006/SUBM-WS-Enumeration-20060315/
>> > should remain compatible with protocols and formats that depend
>> on them, and offer a smooth migration path from the submission to
>> the standard." We are aware of two dependant protocols - DPWS [6]
>> (uses Push Mode) and WS-Management [4] (uses Push Mode and, as
>> mentioned before, defines three new delivery modes).
>>
>> [1] http://www.w3.org/Submission/WS-Eventing/#Delivery_Modes
>> [2] http://www.w3.org/Submission/WS-Eventing/#Subscribe
>> [3] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#http-
>> bindname
>> [4] http://www.dmtf.org/standards/published_documents/DSP0226.pdf -
>> Section 7
>> [5] http://www.w3.org/2008/11/ws-ra-charter.html#scope
>> [6] http://specs.xmlsoap.org/ws/2006/02/devprof/
>>
>> We hope this helps.
>>
>> Regards,
>>
>> Asir S Vedamuthu
>> Microsoft Corporation
>>
>> -----Original Message-----
>> From: public-ws-resource-access-notifications-request@w3.org [mailto:public-ws-resource-access-notifications-request@w3.org
>> ] On Behalf Of bugzilla@wiggum.w3.org
>> Sent: Thursday, March 12, 2009 8:37 AM
>> To: public-ws-resource-access-notifications@w3.org
>> Subject: [Bug 6692] New: Remove Mode from the specification
>>
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692
>>
>> Summary: Remove Mode from the specification
>>
>> Product: WS-Resource Access
>>
>> Version: CR
>>
>> Platform: PC
>>
>> OS/Version: All
>>
>> Status: NEW
>>
>> Severity: major
>>
>> Priority: P2
>>
>> Component: Eventing
>>
>> AssignedTo: public-ws-resource-access-notifications@w3.org<mailto:public-ws-resource-access-notifications@w3.org
>> >
>>
>> ReportedBy: david.Snelling@UK.Fujitsu.com<mailto:david.Snelling@UK.Fujitsu.com
>> >
>>
>> QAContact: public-ws-resource-access-notifications@w3.org<mailto:public-ws-resource-access-notifications@w3.org
>> >
>>
>>
>> The concept of Mode is redundant in the current version of the
>> specification.
>>
>> All events can be thought of as being delivered. There is no actual
>> definition
>>
>> of "Push Mode" and no other recommended modes. We even have a
>> MakeConnection
>>
>> strategy to allow clients behind NATs to fetch events. Likewise,
>> strategies for
>>
>> complex queuing and distribution are supportable without adding
>> additional
>>
>> modes and are outside the scope of this specification.
>>
>>
>>
>> Proposal: Remove /s:Envelope/s:Body/*/wse:Delivery/@Mode from the
>> specification
>>
>> and all references to Push Mode. A simple explanation of the
>> delivery idea and
>>
>> a pointer to some of the techniques available will be needed.
>>
>> --
>>
>> Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
>>
>> ------- You are receiving this mail because: -------
>>
>> You are the QA contact for the bug.
>>
>> You are the assignee for the bug.
>>
>>
>> Wu Chou, IEEE Fellow, Ph.D. | Director |Dialogue System Research |
>> AVAYA | 233 Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 |
>> Voice/Fax: 908-696-5198 / 908-696-5401 | wuchou@avaya.com
>>
>>
>>
>>
>>
>>
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with
>> number 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>> PO6 3AU
>>
>>
>>
>>
>>
>>
>>
Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
Fujitsu Laboratories of Europe Limited
Hayes Park Central
Hayes End Road
Hayes, Middlesex UB4 8FE
Reg. No. 4153469
+44-7590-293439 (Mobile)
______________________________________________________________________
Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
Registered No. 4153469
This e-mail and any attachments are for the sole use of addressee(s) and
may contain information which is privileged and confidential. Unauthorised
use or copying for disclosure is strictly prohibited. The fact that this
e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
not guarantee that it has not been intercepted or amended nor that it is
virus-free.
Received on Tuesday, 31 March 2009 19:31:51 UTC