On Wed, Sep 3, 2008 at 11:04 AM, Anne Noseda <[EMAIL PROTECTED]> wrote: > > "Durable subscribers is an option that we would need so that > subscribers don't loose any messages. > It's different (though complementary) to the fact that the > subscription itself is persisted. > For storing the informations needed for subscrition / registration, i > think we could leverage the simple JDBC support we have in ServiceMix > (see > http://svn.apache.org/repos/asf/servicemix/utils/trunk/src/main/java/org/apache/servicemix/jdbc/)." > > Can you give me an example of component / code where this is used ?
Here is one: https://svn.apache.org/repos/asf/servicemix/smx3/trunk/core/servicemix-audit/src/main/java/org/apache/servicemix/jbi/audit/jdbc/JdbcAuditor.java > > " 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. > > "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. > "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. > -- > View this message in context: > http://www.nabble.com/WS-Notification-Component-Improvment-tp19254179p19285408.html > Sent from the ServiceMix - Dev mailing list archive at Nabble.com. > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
