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>