RE: [Bug 6692] New: Remove Mode from the specification

Doug,

We would like to work with you for a good solution moving forward that
can be interoperable with the existing WS-Eventing
implementations/applications, and at the same time address some new
concerns. 

For this purpose, please post your concrete Subscribe that requires the
event delivery through a specified proxy as we did. The Subscribe
message should convey the following semantics to the event source of
WS-E:   

1.  event delivery through  a subscriber specified proxy (including the
proxy can be a web service);  

2. the event source either accept the subscription and deliver the event
through the proxy to the sink,  or faults  the subscription with
wse:DeliveryModeRequestedUnavailable.  

With that, people can verify on  their WS-Eventing/WS-Addressing  specs
based implementations to see how it works.   

Three issues attached below, and we should discuss  when we see your
concrete uses case.  

1. Changes made to the current WS-E specs - The above (push_thru_proxy)
use case is supported by Mode in WS-E specs. with no change to the WS-E
specs  (we did not add any new element  or fault to WS-E, because Mode
is an extension point  and wse fault behavior is specified by WS-E).

2. Semantic gaps: Need to see if the extension point in EPR provides the
same semantics as Mode attribute to WS-E specs , e.g. relation to event
source behavior of accept/fault).  The Mode attribute is used for all
required behaviors under  push event delivery, including QoS, proxy,
transport, transport protocol version, ...   

3. Impact of extended EPR to the endpoint - A fully extended EPR for all
WS-* can be "Fat", and we need to weigh between complete/heavy vs.
light/agile, for server and mobile devices. In WS-E, EPR is not only
carried by the subscribe messages, but also by every events transmitted
(SOAP) to the sink. 

Regards,

- Wu Chou. 


________________________________

From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Tuesday, March 31, 2009 9:46 AM
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



"Chou, Wu (Wu)" <wuchou@avaya.com> wrote on 03/31/2009 12:18:50 AM:
... 
> 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. 

Rather than simply repeating "we can't change it because it's there" 
please explain what piece of _functionality_ (not xml) we are removing 
or impacting by making this change.  I don't believe anyone is
suggesting 
that we remove the ability to do any of the scenarios that have been 
discussed - the proposal simply changes how things appear on the wire.

And, to some people, this will improve WS-Eventing because it will 
compose better with the rest of the WS-* stack.   

I'm still waiting for an explanation for why WS-Eventing 
needs "Mode" when no other WS-* spec does.  Without this justification 
I'm having a hard time shifting from my opinion that the original 
WS-Eventing authors made a mistake.  Have you look at RM's AcksTo yet? 

> 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. 

I'm not sure what you're trying to say here.  There are a couple of 
way to interpret it: 
- IT code can modify the Delivery element to add the ext:Proxy element 
  but it can't go down one more level and modify the NotifyTo.   
  I don't buy that. 
- You claim the event source needs to differentiate between the two 
  cases.  At the transport layer, sure.  But why do the guts of the 
  pub/sub engine need to know this?  Anyone who coded it so that
anything 
  but the transport layer needs to know this has made a very poor design

  choice.  As I stated in my previous note, this means that each and
every 
  time a new "transport level" extension is introduced you'll impact
your 
  entire pub/sub engine.  Yuck!  :-) 
- Notice that even _if_ a poorly coded ws-e impl did want to know about 
  this extension, in my previous note I provide you a way to do this. 

> 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. 

I didn't put ext:Proxy as a ref-param so I'm not sure why you're worried

about that. 

> 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. 

And the mU header I proposed serves this exact same purpose.  Remember, 
I'm not suggesting that we remove the ability to do what you're asking. 
All I'm suggesting is that there are other ways to do the exact same
thing 
that are more aligned with how the rest of the WS-* stack works. 

However, having said all of that, if you really want to put the
ext:Proxy 
element outside of the EPR you can still do that.  But this does not
mean 
you MUST have the Mode attribute - you can get the same results with the

mU header.  And it allows for people to choose a more optimal
implementation. 
With your solution it'll force the less optimimal solution.  Let me
repeat 
that.... w/o the Mode people can choose which implementation choice they

want to make (aware or unaware within the pub/sub engine); with the Mode

attribute they only have ONE choice - the pub/sub engine MUST be forced
to 
be aware of this extension.  We should not be forcing this kind of
design 
choice on people. 

Please think about this in terms of functionality.  Can you achieve the 
same desired results with this change?  Based on the use-cases discussed

so far the answer is 'yes'.  Yes it will invole some code changes, but
any 
change we propose to the spec will do that. 

> 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.com> 
> 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 
>