Re: Issue 7970 (proposal version 2)

It seems to me the term "event source" is used incorrectly.
We might consider changing its name to "Notification Source", since  
events are not sent, but notifications are.
If a description of event source is required, then it might be  
described as an abstraction that it not constrained by this  
specification since there are an arbitrary number of potential and  
irrelevant implementation organizations.  Discussion of dispatchers or  
other parts that are not necessary for the implementation of the  
protocol and not otherwise visible on the wire is inappropriate and  
overly constraining.
thanks
-bob

On Oct 30, 2009, at 3:51 PM, Chou, Wu (Wu) wrote:

> This is the version 2 of the proposal to Issue 7970 (text file below  
> and color marked pdf file is attached), in which the last paragraph  
> of the previous proposal is removed to address an issue with pull- 
> model event delivery.
>
> Thanks,
>
> - Wu Chou.
>
> ---------------------------------
> A proposal to issue 7970 (changes are in RED – Wu Chou v.2)
> Section 3.4 Terminology
>
> Event Source
>
> A Web service that accepts requests to create subscriptions and sends
>
> notifications directly or through a separate event dispatcher.
>
> Event Dispatcher
>
> A SOAP endpoint that sends event notifications on behalf of the  
> event source.
>
> Section 4.1 Subscribe
>
> [Action]
>
> http://www.w3.org/2009/09/ws-evt/SubscribeResponse
>
> [Body]
>
> <wse:SubscribeResponse ...>
>
> <wse:SubscriptionManager>
>
> wsa:EndpointReferenceType
>
> </wse:SubscriptionManager>
>
> <wse:EventDispatcher>
>
> wsa:EndpointReferenceType
>
> </wse:EventDispatcher> ?
>
> <wse:Expires>(xs:dateTime | xs:duration)</wse:Expires>
>
> xs:any*
>
> </wse:SubscribeResponse>
>
> (After the text of [Body]/wse:SubscribeResponse/ 
> wse:SubsrciptionManager)
>
> [Body]/wse:SubscribeResponse/wse:EventDispatcher
>
> The EPR of the event dispatcher for this subscription.
>
> If the event source uses a separate event dispatcher to send  
> notifications, it
>
> MUST include wse:EventDispatcher element for this subscription in its
>
> SubscribeResponse. Otherwise, the event notification is sent from  
> the event
>
> source.
>
> ---------------
> From: Chou, Wu (Wu)
> Sent: Thursday, October 29, 2009 11:43 PM
> To: 'public-ws-resource-access@w3.org'
> Cc: 'Bob Freund'; Li, Li (Li); 'Doug Davis'
> Subject: RE: Issue 7970
>
> The pdf file of this proposal to issue 7970 [1] is attached to  
> retain the color marking for viewing.
>
> Thanks,
>
> - Wu Chou.
>
> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7970
>
>
> From: Chou, Wu (Wu)
> Sent: Thursday, October 29, 2009 2:51 PM
> To: 'Doug Davis'
> Cc: Bob Freund; Li, Li (Li); public-ws-resource-access@w3.org
> Subject: RE: Issue 7970
>
> Doug,
>
> After thinking about this issue again, I think we should cover the  
> following use case for clustering deployment. And I attach a  
> proposal for issue 7970 that can support the existing as well as the  
> clustering deployment model.
>
> Use case: In some data center or high volume event processor, events  
> may be delivered from a special event dispatcher or from a pool of  
> high speed event dispatchers, not necessarily from the event source  
> endpoint.
>
> Rationale and benefits: 1) Event dispatcher pools can be shared by  
> all event sources to improve the event dispatch throughput. 2) These  
> event dispatchers can be on high speed links (IP addresses) as part  
> of the infrastructure. 3) There is no need to implement a http  
> client event dispatch for every single event source. For example,  
> there might be 10,000 individual event sources on the platform, but  
> only 10 high speed event dispatchers. 4) For some resource limited  
> devices, the resource hungry event dispatcher may reside in a  
> separate but more resourceful environment from the event source.
>
> The attached proposal supports this clustering deployment model . In  
> addition, by making the event dispatcher explicit, it supports the  
> poll-model in event delivery and IP-blocking as in current model.
>
> Thanks,
>
> - Wu Chou.
>
> ---- A Proposal to Issue 7970 (changes are in RED) -------
>
> Section 3.4 Terminology
>
> Event Source
> A Web service that accepts requests to create subscriptions and  
> sends notifications directly or through a separate event dispatcher.
>
> Event Dispatcher
> A SOAP endpoint that sends event notifications on behalf of the  
> event source.
>
> Section 4.1 Subscribe
>
> [Action]
>   http://www.w3.org/2009/09/ws-evt/SubscribeResponse
>
> [Body]
>   <wse:SubscribeResponse ...>
>     <wse:SubscriptionManager>
>       wsa:EndpointReferenceType
> </wse:SubscriptionManager>
>
>      <wse:EventDispatcher>
>       wsa:EndpointReferenceType
> </wse:EventDispatcher> ?
>
>     <wse:Expires>(xs:dateTime | xs:duration)</wse:Expires>
>     xs:any*
>   </wse:SubscribeResponse>
>
> (After the text of [Body]/wse:SubscribeResponse/ 
> wse:SubsrciptionManager)
>
> [Body]/wse:SubscribeResponse/wse:EventDispatcher
>
> The EPR of the event dispatcher for this subscription.
>
> If the event source uses a separate event dispatcher to send  
> notifications, it MUST include wse:EventDispatcher element for this  
> subscription in its SubscribeResponse. Otherwise, the event  
> notification is sent from the event source.
>
> If the EPR of the event dispatcher cannot be determined, the  
> <wsa:Address> value of wse:EventDispatcher MUST be “http:// 
> www.w3.org/2005/08/addressing/anonymous”
>
> -------------------------------------------------------------
>
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Monday, October 26, 2009 4:45 PM
> To: Chou, Wu (Wu)
> Cc: Bob Freund; Li, Li (Li); public-ws-resource-access@w3.org
> Subject: RE: Issue 7970
>
>
> Wu,
>   I think you're missing the point.  WS-Eventing needs to allow for  
> more than one deployment model - this does not mean that every  
> deployment needs to support everything.  Current WS-Eventing only  
> works for one model and will not work in many other common models -  
> like clusters.  If you want to have your deployment limited to one  
> where only one IP address sends notifications then that's great.   
> But if WS-Eventing is designed so that that is the only model then  
> it will severely limited its use in more advanced environments.
>
>   If you really want to enforce the rule you have in mind then I  
> suggest you open a new issue to add text to WS-Eventing that makes  
> this very clear, and clearly define the scope of an Event Source -  
> meaning limited to just one outbound IP address so that this can be  
> an explicit statement of direction instead of informally implied -  
> leading to confusion and interop issues.
>
> 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>
> 10/26/2009 03:34 PM
>
> To
> Doug Davis/Raleigh/IBM@IBMUS
> cc
> "Bob Freund" <bob.freund@hitachisoftware.com>, "Li, Li (Li)" <lli5@avaya.com 
> >, <public-ws-resource-access@w3.org>
> Subject
> RE: Issue 7970
>
>
>
>
>
> Doug,
>
> Please see the comments in line.
>
> Thanks,
>
> - Wu Chou.
>
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Monday, October 26, 2009 10:51 AM
> To: Chou, Wu (Wu)
> Cc: Bob Freund; Li, Li (Li); public-ws-resource-access@w3.org
> Subject: Re: Issue 7970
>
>
> Wu,
>  could you elaborate a bit on your thinking here.  If we went with  
> the 2nd option (which seemed to be preferred on the call):
>   A Web service that accepts requests to create subscriptions for
>  a certain set of notification that might be generated.
>
> what woud need to change in your implementation or what would break  
> in any existing implementation?
>
> <Wu: The security and trusted event source will be affected and  
> break. Since the notification source is unknown,  the common IP  
> blocking implementation cannot be used to protect the event sink.   
> The event subscriber cannot be sure if the event notification is  
> from a trusted endpoint . Moreover, the event subscriber cannot be  
> sure if it can receive event notification after a successful event  
> subscription, because if the notification  is from some unknown  
> suspicious host not permitted by firewall filter, it will be blocked  
> by firewall.>
>  <Wu:  In  WS-E, it describes a model that event source indicates  
> its event notification operations in its wsdl (or its notification  
> wsdl to be BP compliant).  Not clear if it is appropriate that  
> operations on the event source endpoint wsdl are not its own  
> operations but operations from some unknown endpoint. This change to  
> the fundamental concept of WS-E may take time to learn its full  
> impact, and we prefer not changing it.>
>
> Also, your point #3 actually might not be true.  If WS-Eventing  
> doesn't define an Event Source to allow for other components  
> (anything other than the _one_ event source) to send Notifications  
> then an extension spec can't do it either since it would be  
> contradicting the base spec.
>
> <Wu: It could work, since the base spec says the notification is  
> from the event source, and the extension spec says an event source  
> can be a proxy that forwards the event notification to the sink.  
> >From the subscriber perspective, it is the base  spec, and from the  
> event source perspective, it allows an notification source to  
> establish a proxy relation and allow subscribers to subscribe events  
> from its proxy.  In short, an extension service can allow  
> introducing additional entities and in this case, an extended event  
> sender does not need to correspond to any concepts in WS-E.>
>
> As it currently stands we have an inconsistency in the spec - if  
> Event Sources are the only things that can send Notifications, then  
> when we use a pull-style model we're broken because in those cases  
> the Subscription Manager is the one that sends the Notifications.
>
>  <Wu: No, in  ws-eventing, subscription manager and event source can  
> be the same endpoint. It should work for your case. Allowing the new  
> changes as in the proposal may actually break a pull-model, as the  
> event sender can be some unknown thing other than the event source  
> and subscription manager. In this case, the event sink does not know  
> where to pull event from.>
>
>  I don't think the above proposal would break anyone, nor even  
> require a coding change.  Rather its just an admission that our WS-*  
> specs only control what goes on the wire and we can't control what  
> happens behind the scenes.  How people choose to implement this  
> stuff is up to them.  For example, there is nothing inWS-Addressing  
> that requires the sender of an async response to be the same entity  
> as the one that received the request and this is no different.  Do  
> we really need to say that the entity that sends the  
> SubscribeResponse MUST be the same one the receives the  
> SubscribeRequest?
>
>  <Wu: One difference is: in ws-eventing, the event source has  
> notification operations in its wsdl (or its notification wsdl) and  
> the subscriber subscribes to that service from that (event source)  
> endpoint.  It is true that WS-A does not prohibit a reply comes from  
> somewhere other than the receiver, but the WS-A only specifies how a  
> receiver  formulates a reply message (WS-A core section 3.4). It  
> seems other use cases are extensions.>
>
>  And what does "same one" mean?  In a clustered environment things  
> get a bit complicated.
>
> 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
> 10/26/2009 10:23 AM
>
>
> To
> "Bob Freund" <bob.freund@hitachisoftware.com>, <public-ws-resource-access@w3.org 
> >, <public-ws-resource-access-request@w3.org>
> cc
> "Li, Li (Li)" <lli5@avaya.com>
> Subject
> Issue 7970
>
>
>
>
>
>
> Bob,
>
> We see some problems with issue 7970 [1] and we share our thoughts  
> below.
>
> 1) Current WS-Eventing is based on a set of well-defined web  
> services (source, sink, subscriber and subscription manager). If  
> there is some entity that interacts with WS-Eventing services, it  
> should be either defined in the spec, or it should be out of scope.  
> This proposal involves interactions with some entity whose behavior  
> is not defined in the spec.
>
> 2) By allowing an unknown third-party (instead of event source) to  
> send notifications to event sink complicates security checks against  
> attacks to the event sink. For example, IP blocking would not work  
> since the true notification senders are unknown, even after the  
> subscription.
>
> 3) Current WS-Eventing architecture can handle this use case by  
> having the event source forward notifications (from other senders)  
> to the sinks. Therefore, alternative approaches should be treated as  
> extensions.
>
> Thanks,
>
> - Wu Chou/Li Li,
>
> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7970
>
>
>
>
>
> <Event dispatcher_wu_submit_v2.pdf>