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

Doug,
 
Many thanks for your use case. It is highly appreciated.
 
We will work on it and get back to you as we progress.
 
Regards,
 
- Wu Chou.

________________________________

From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Wednesday, April 01, 2009 5:36 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, 
  here's what a Subscribe would look like: 

<s:Envelope> 
 <s:Header> 
  <wsa:Action> ..../Subscribe </wsa:Action> 
  <ext:ProxySupport mustUnderstand="1"/> 
 </s:Header> 
 <s:Body> 
  <wse:Subscribe> 
   <wse:Delivery> 
    <wse:NotifyTo> 
     <wsa:Address> http://www.avaya.com </wsa:Address> 
     <ext:Proxy/> 
    </wse:NotifyTo> 
   </wse:Delivery> 
   <wse:EndTo> 
    <wsa:Address> http://www.avay.com </wsa:Address> 
    <ext:Proxy/>  <!-- optional if you want this to go thru a proxy too
--> 
   </wse:EndTo> 
  </wse:Subscribe> 
 </s:Body> 
</s:Envelope> 

It won't show up if you read this thru the email archives but the
elements in red are the only new elements (the <ext:...> ones - 3 of
them).   

To your points: 
1 - same semantics as today.  In both cases (your current impl and
above) the receiver of this Subscribe will generate a Fault if it
doesn't understand the proxy stuff.  In your current impl you would get
an UnsupportedMode fault, in my version it would be a mustUnderstand
fault.  But that's a minor change - either way a fault is returned back
to the client with enough info to know why it was generated. 

2 - this did not require any change to WS-Eventing. 

3 - to your "fat" comment. This will obviously be subjective. You'll
notice that I chose to show the <ext:Proxy> element on the EndsTo EPR.
If you honestly consider this 'fat' then don't allow it.  This new
extension can be defined to only work on the NotifyTo EPR - that's
perfectly legal - and it would then not be any more 'fat' than what you
have today.  However, if implemented correctly, meaning done at the
transport layer, then you magically get support for the proxy on the
SubscriptionEnd message without ANY additional code - that's "thin"  :-)
And like I said before, I don't understand how you can support this
Proxy extension without also needing it for the SubscriptionEnd message.
Without it, it feels like only 1/2 of a solution. 

3a - True, any message could have an EPR and therefore could have this
extension element in it.  However, you can define it so that its only
legal in the NotifyTo and EndTo if that's what you wanted - then you
never have to worry about it in other places. It would be a shame, but
that's legal. 

To be complete, if you really didn't like extending the EPR (even
thought it a brilliant idea :-), here's another option: 

<s:Envelope> 
 <s:Header> 
  <wsa:Action> ..../Subscribe </wsa:Action> 
  <ext:ProxySupport mustUnderstand="1"/> 
 </s:Header> 
 <s:Body> 
  <wse:Subscribe> 
   <wse:Delivery> 
    <wse:NotifyTo> 
     <wsa:Address> http://www.avaya.com </wsa:Address> 
    </wse:NotifyTo> 
   </wse:Delivery> 
   <wse:EndTo> 
    <wsa:Address> http://www.avay.com </wsa:Address> 
   </wse:EndTo> 
  </wse:Subscribe> 
 </s:Body> 
</s:Envelope> 

Then you could define the <ext:ProxySupport> header to mean "send the
Notifications" thru the out-of-band proxy (and SubscriptionEnd too if
you want).  Again, no changes to WS-Eventing, just a "thin" as your
current stuff, no semantic change and you don't need to worry about
extending EPRs. 

The point here is that you can get the same end result w/o the need for
"Mode" - its a duplicative extensibility point. 

But seriously consider the EPR way of doing it - even if we do keep Mode
- SubscriptionEnd message will need it too. 

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> wrote on 04/01/2009 05:06:28 PM:

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