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>