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.