On Thu, Sep 4, 2008 at 1:53 PM, Anne Noseda <[EMAIL PROTECTED]> wrote: > >>>> This can be done independantly from the JMS durable subscription. >>>> For the JMS part, I think we should support it in the form of a >>>> WS-Notification policy that would be included in the subscription >>>> request. >>>> For more infos, check the WS-BaseNotification spec, line 622 (which >>>> documents the /wsnt:Subscribe/wsnt:SubscriptionPolicy element) > >>> You mean the subscriber will send in his subscription request an element >>> telling that he wants a durable subscription like this (for example) : >>> >>> <wsnt:Subscribe> >>> <wsnt:ConsumerReference> >>> ... >>> </wsnt:ConsumerReference> >>> <wsnt:Filter> >>> ... >>> </wsnt:Filter> >>> <wsnt:SubscriptionPolicy> >>> <wsnt:UseDurable/> >>> </wsnt:SubscriptionPolicy> >>> </wsnt:Subscribe> > >> Yes, but it would have to be a servicemix specific element. >> So something like: >> <wsnt:SubscriptionPolicy> >> <useDurableSubscription >>xmlns="http://servicemix.apache.org/wsn2005/1.0"; /> >> </wsnt:SubscriptionPolicy> >> We already have a few extensions defined in the >> http://servicemix.apache.org/wsn2005/1.0 namespace, mainly for the >> CreatePullPoint request. > > Two more points about persistance : > 1. what do you think about this situation : if all the subscribers of a > topic have specified "useDurableSubscription=false", a publisher sends a > notification and at the same time, Servicemix system is restarted. As there > are no JMS durable subscription on the topic, it is deleted when Servicemix > restarts... > To avoid this, what do you think of creating an empty subscriber which uses > JMS durable subscription ? If you think it's a good idea, must this empty > subscriber be created by the wsn-component or must we develop it outside the > component (in a servicemix-bean or other) ? > 2. what about the topicSet of WS-RessourceProperties ? It must also be > persisted to retrieve the topic list after restarting the system.
I'm not sure to understand your exact needs here. Do you really need the JMS topic to exist (if so, why ?) or is the only purpose to be able to check when a subscriber registeres, in which case, if the component keeps a persistent list of created topics, we would not care about the existence of the JMS topic... >>>> "It seems there are two different things / options here. The first one >>>> would be to check the existence of the underlying JMS topic, but it >>>> may make more sense to check only topics that the >>>> WS-NotificationBroker knows about (i.e. those that have been >>>> advertised through a publisher registration), as we'd need the list to >>>> be available for the next point too." > >>> Yes, that's it. But if we can retrieve this list, you agree this >>> behaviour >>> can be added to the component ? >>> This would be the default behaviour or would it be specify by a property >>> of >>> the component or a part of the registration / subscription request ? > >> Well, we can at least add a way to configure this behavior. Not sure >> yet what the default should be though. >> Btw, would the existence of a topic be tied to the existence of a >> publisher ? What would happen to subscribers if the publisher >> unregisters ? Do we need a way to remove a topic ? Sounds like it >> raise a number of questions. > > Indeed. I can send you my customer analyse where I study all these > possibilities. > In general, the main rule is to avoid the lost of messages. So, when all the > publishers of a topic unregister, we conserve the topic and the > subscriptions. Maybe others publishers will come... And if the topic is > really out-of-date, it's an administrator who can delete it. In this case, a > delete method must be available. The administrator must also warn the > subscribers that their subscriptions are destroyed because the topic is > out-of-date. > In the same order, it will be interesting to have some methods to retrieve > the list of subscriptions / registrations. Wow, this sounds like a fait amount of work. We would need to define a WSDL and a port type along with the needed requests for topic management. This port type would be implemented by the NotificationBroker as an additional port type (or maybe an additional JBI endpoint would be better). > >>>> As for the automatic creation of the topic, there is no JMS compliant >>>> way to force the topic creation though it can be done in an activemq >>>> specific way. > >>> Even if we force the sending of a first notification ? > >> That would work, but i'm not sure it's a good idea to send an >> unexpected notification on the topic. >> Btw, it there a need to really create the JMS topic or is that just >> because of the above points, where we want to be able to send the list >> of existing topic and check their existence when a subscription >> request is received ? If the component maintains its own list of >> topics somehow, it should not be needed to force the JMS topic >> creation. > > Exact, after reading about WS-ResourceProperty, I realize it solve many > problems. > > > 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. > - 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. 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. > -- > View this message in context: > http://www.nabble.com/WS-Notification-Component-Improvment-tp19254179p19308776.html > Sent from the ServiceMix - Dev mailing list archive at Nabble.com. > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
