RE: Issue 7970 (proposal version 2)

Bob,
 
To make it clear, we think the current WS-E spec is fine regarding event
source. If we do not want to cover other deployment model for clusters
or for better efficiency, we prefer not to change the definition of
event source in the current spec, since it is a fundamental one and
takes time to fully understand its impact. 
 
You asked a very good question: "Why is it necessary to peer under the
hood?" My answer is: it is driven by use cases. In my view, separating
event dispatcher from the event source follows the same thinking process
of separating subscription manager from the event source. 
 
Subscription manager originally is part of the event source and it can
continue to be so under the current spec. One critical benefit, among
many others, to open the hood of event source allowing subscription
manager to be a separate endpoint is: event source can be on and off in
terms of reach-ability, but the subscriber needs constant control of the
event subscription, e.g. renew, etc. Therefore, by allowing subscription
manager to be separated from event source, it can be deployed in a more
reliable environment allowing the event subscriber to successfully renew
the event subscription while event source may be temporally out of
reach.
 
It is the same story for event dispatcher. We went through those use
cases and came to the conclusion that there is a critical need to open
the hood allowing event dispatcher to be separable from the event source
(details are in the rationale and benefits of my proposal). 
 
Thanks,
 
- Wu Chou.

________________________________

From: Bob Freund [mailto:bob.freund@hitachisoftware.com] 
Sent: Sunday, November 01, 2009 6:57 PM
To: Chou, Wu (Wu)
Cc: public-ws-resource-access@w3.org; Li, Li (Li); Doug Davis
Subject: 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
<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
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=7970>  

		
		  


		<Event dispatcher_wu_submit_v2.pdf>