On Mon, Sep 15, 2008 at 4:04 PM, Anne Noseda <[EMAIL PROTECTED]> wrote: > >>> Two more topics, I would like to discuss : > >>> - what about security ? >>> Is there something developped in the wsn2005 component ? >>> Is it the role of the notification component to check if : >>> - a publisher has the right to register to a certain topic ; >>> - a subscriber has the right to subscribe to a certain topic ; >>> - a publisher has the right to send notification to a certain topic ; >>> - a subscriber has the right to receive notification from a certain topic >>> ? > >> There's nothing implemented around security at the moment. We may be >> able to leverage activemq features, but i doubt it would fit all these >> needs. > > And do you think it's the role of the component to do the four points before > ? > I think that an idea would be to call an external component to check the > security before : > - accepting a registration > - accepting a subscription > - accepting a notification > - sending a notification > A little bit like the "marshaller" that we can configure on some binding > components. Here, we could call it a securityhandler which by default would > return true all the time. > So, every developper would implement his securityhandler as he need. > The securityhandler could connect to a LDAP, to a DB, ... to check if the > registration/subscription is up-to-date. > What do you think ?
Yeah, if we can come up with something generic enough, I see no reason why not including it in the component. >>> - what about clustering ? I see that if we have two endpoints clustered, >>> they will receive two notifications. But I see also you open a JIRA for >>> it >>> (https://issues.apache.org/activemq/browse/SM-418) where you say that >>> durable subscription can correct it ? > >> I think there are two disctincts use case here. If a subscriber is a >> JBI endpoints (deployed in a service unit for example), this endpoint >> may exist in several servicemix instances in the cluster. So they >> should act as a *single* subscriber and not receive multiple copies of >> the same notification. > > So, it is an improvment done recently ? Because on your website, you write : > " > The current implementation has several limitations: > * subscriptions can not be clustered: if you register the same > subscriber in a cluster, each node will receive all notifications > " No, and that's the problem. They *should* act as a single subscriber, but it does not work this way at the moment. >> Another use case is when the client is an >> external subscriber and if the notification broker crashes, we want >> the subscriber to continue to receive notifications from another >> broker. This is solved if you use JBI endpoints, as you could deploy >> multiple copies of the same endpoint on the servicemix instances, but >> if the client is external, is will usually send only a single >> subscribe request, so we would have to do something for that. > > Indeed, in our use case, there are only external subscribers. How can we > correct that ? We need to persist the subscriptions somehow (to a database for example) and be able to recover and restart those subscriptions when the component starts again, instead of having the subscriber send another request (it may not even be aware that servicemix has shut down and restarted). > -- > View this message in context: > http://www.nabble.com/WS-Notification-Component-Improvment-tp19254179p19493591.html > Sent from the ServiceMix - Dev mailing list archive at Nabble.com. > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
