>> 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 ? >> - 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 " > 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 ? -- 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.
