RE: Issue 7970 (proposal version 2)

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>