Re: Issue 7970 (proposal version 2)

I have thought that it was always a bit misleading, since there is not  
a one to one relationship between an event and a notification.   
Filters limit the notifications produced, any indeed multiple  
subscribers may subscribe to a particular event and possibly with  
different filter specifications.
That is why I think that it is best to describe the event more  
abstractly.  An event provides the stimulus for a notification, but I  
am sure that it may be possible to define an event, such as "no events  
have occurred in the last hour"  Why is it necessary to peer under the  
hood?
-bob

On Nov 1, 2009, at 6:43 PM, Chou, Wu (Wu) wrote:

> Bob,
>
> In WS-Eventing, the event is sent in a form of notification, and  
> therefore, the event is sent. WS-Eventing is about eventing, and  
> therefore, the spec defines the event source, and notification is  
> secondary, since event delivery is possible through pulling (e.g.  
> without Notifyto in Delivery) instead of notification.
>
> The event dispatcher has the similar status as subscription manager  
> in WS-E, and therefore, it is visible on the wire and part of the  
> protocol. As in current WS-E spec, the event dispatcher is the event  
> source (unlike subscription manager which can be separated from the  
> source). The subscriber subscribes to the event notifications that  
> are on the event source endpoint wsdl (or its notification wsdl).  
> Therefore, following the current WS-E spec, the case is closed and  
> there is nothing wrong with the spec.
>
> My proposal is motivated by the discussion on issue 7970. It is an  
> attempt to extend WS-E to handle these other use cases. It is an  
> extension (not constraining) the current WS-E spec. Let's have some  
> discussion at the upcoming F2F meeting.
>
> Thanks,
>
> - Wu Chou.
>
> From: Bob Freund [mailto:bob.freund@hitachisoftware.com]
> Sent: Saturday, October 31, 2009 8:29 PM
> To: Chou, Wu (Wu)
> Cc: public-ws-resource-access@w3.org; Li, Li (Li); Doug Davis
> Subject: 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>
>