Re: WS-Eventing Issue 6425 proposal

Wu,
  I don't understand the purpose behind the first part of your proposal. I 
think WS-Eventing is pretty clear that the Subscribe is sent to the Event 
Source and that the Event Source's EPR turns into the WSA headers - per 
WSA rules.  Could you elaborate on why there is confusion on this?

  On the 2nd part of your proposal... I think what you are proposing, if I 
understand it, is mostly fine but out of scope for WS-Eventing.  When a 
Subscriber sends a Subscribe() message to an Event Source it had to get 
the Event Source's EPR from someplace - perhaps some WSDL.  Regardless of 
how it got that EPR, it is up to the Event Source to determine what the 
EPR looks like.  If it wants to have reference parameters that have a 
portType or csta ID then that's fine but its not really any of WS-Eventing 
concern how it makes this decision.  But most importantly, the subscriber 
should not need to know this or even care.  To it, the EPR is just an 
opaque bit of XML.

  Also, within your proposal you talk about using ref-params as a, sort 
of, filtering mechanism.  While this is legal because an Event Source can 
choose to define what its EPRs look like - I think moving ref-params from 
being used for identifications or routing purposes and into the realm of 
filtering an event stream is a poor design choice.  This mixing of 
concerns is bound to make for a much more complex and fragile system.  The 
WSA headers (and ref-params) are meant to address the event source and 
nothing more. As long as the event source's EPR is an opaque object then 
this mixing of concerns (while wrong, IMO) is not something we can stop 
since the Event Source is free to decide how its EPRs are made.  However, 
quoting your proposal:
The above use cases requires an event subscriber to provide some 
additional information, besides the
service location URI defined in the Event Source WSDL, to associate a 
subscription with the targeted
individual event source (a resource or a port type).
worries me because when you talk about an event subscriber "providing 
additional information" then it sounds like you want the subscriber to not 
just use the EPR provided to it by an Event Source, but rather you want it 
to modify the ref-params to add this 'additional information'.  At this 
point the EPR is no longer opaque and the subscriber must now understand 
the internal design choices that the Event Source made about how its EPRs 
are constructed.  This assumed shared knowledge is not something 
WS-Eventing (or other WS specs - like WS-Session) should promote.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com



"Chou, Wu (Wu)" <wuchou@avaya.com> 
Sent by: public-ws-resource-access-request@w3.org
02/03/2009 03:28 PM

To
<public-ws-resource-access@w3.org>
cc

Subject
WS-Eventing  Issue 6425 proposal






 
 
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 
 [attachment "wse_6425_2.pdf" deleted by Doug Davis/Raleigh/IBM]