On Tue, Sep 16, 2008 at 10:12 AM, 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. > > In the same idea, we can maybe use AOP Spring framework which allows to do > some treatment after or before a method without changing a word in the code > of the wsn2005 component ...
Not sure how well it would work as the code has not been designed for AOP. That's still an idea, but I'd lean toward defining an interface personaly. >>>>> - 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. > > Ok, but have you an idea how to correct this ? I have one but I don't know > if it is the best ... maybe you have a best way to correct that. My idea is > the following : > 1. when the servicemix instance receives the JMS notifications from the > topic, it tries to write the JMSMessageID property in a DB table (INSERT > operation, ID is the unique column and the primary key) > 2. if it succeed, the servicemix instance sends the notification > 3. if it fails, the servicemix instance don't send the notification (writes > a log for example) Using durable subscriptions would work. If two JMS consumers have the same durable subscription id, only one of them will receive a given message afaik. We may also want to leverage ActiveMQ virtual destinations instead. See http://activemq.apache.org/virtual-destinations.html for more informations. > >>>> 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). > > Ok, this meets our persistence point. It's not a problem. > > Another point, when an external subscriber sends a subscription message, > this message will be oriented (by an alteon) to one servicemix instance. > This instance will create the JBI endpoint only on this instance or also on > all the servicemix instances in the cluster ??? > Same question for registration of publishers. > -- > View this message in context: > http://www.nabble.com/WS-Notification-Component-Improvment-tp19254179p19507284.html > Sent from the ServiceMix - Dev mailing list archive at Nabble.com. > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
