On Mon, Sep 1, 2008 at 2:48 PM, Anne Noseda <[EMAIL PROTECTED]> wrote: > >>> Hello Guillaume, > >>> For one of our customers, we are going to develop a new architecture of >>> EDA type >>> and we we will base it on the Servicemix WS-Notification component. >>> After analysis, the component shows several limitations such as : >>> 1. no persistence of the consumer subscriptions >>> 2. no persistence of the publisher registrations > >> These two points depend in part of the way you use the component. >> The first possibility is to deploy JBI endpoints on the ws-notification >> component >> which will host these requests. In this case, the persistence is not >> needed because >> when the system will restart, these endpoints will be deployed again. >> If the requests are sent by external clients, data will indeed be lost >> when the system will restart. I must verify the specification >> WS-Notification >> to check how to solve the problem. > > My question was about external clients which send requests to the bus via > HTTP/SOAP or JMS/SOAP. > For the JMS part, what do you think about creating durable subscription on > JMS topics ? > For the JBI part, I suppose we must persist (in files, DB, ...) EPR and > subscription / registration ID > to deploy them again when the system will restart ?
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/). 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) >>> 3. no way to avoid automatic topic creation when a consumer send a >>> subscription request >>> 4. no way to force automatic topic creation when a publisher send a >>> registration request > >> Do you mean you want to check if the topic exists before validating a >> subscription ? >> For the point number 4, the component uses ActiveMQ and the topic creation >> is automatic... > > Exactly, it's the need of my customer. It's very easy to add this behaviour > in the WS-notification component > (I've already done it) but I suppose it would be better if we let the > possibility to choose > to activate or not this behaviour through a property of the ws-notification > component > for example ? > For the point number 4, the topic is automatically created when the > publisher sends it's first notification > and not when he registers. So, it would be bad in my case when subscribers > can only subscribe for existing topics. > There are several options : > - we force the topic creation when the publisher registers (if the topic > doesn't already exists) > - we force the sending of a first notification (hello notification) when a > publisher registers > --> if the topic doesn't exist, it is created > --> if the topic already exists, all the subscribers are warned that a new > publisher has registered on the 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. 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. >>> 5. no way to retrieve the list of the topics created by the >>> ws-notification component > >> Exact, This would be implemented in conformity with the >> WS-ResourceProperties specification > > Can you give me more information about it ? I don't know much it as I only had a glance at the spec (see http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf). It seems to be mostly about supporting some WS-RF-RP specific messages and process them. It seems the way to go would be to include a copy of the WS-RF-RP wsdl (http://docs.oasis-open.org/wsrf/rpw-2.wsdl) so that cxf will generate the appropriate beans at compile time. If we change the AbstractNotificationBroker to implement the GetResourceProperty interface in addition to the NotificationBroker interface, it should be sufficient (well, we obviously need to implement those methods ...) The properties that need to be supported are described in the WS-BaseNotification spec, in section 4.1 NotificationProducer Resource Properties. >>> 6. no way to define an order in notification messages > >> I'm not sure that the easiest method is to do it in the component it-self. >> This would imply to define an order on messages which content is unknown. >> It would be easier to use a resequencer >> (see >> http://servicemix.apache.org/servicemix-eip.html#servicemix-eip-Resequencer >> or camel). >> The problem of the order is complex (is it a total order, an order in >> relation with the publisher, etc...) > > I was just thinking about a way, for the consumer, to re-order the messages. > For exemple, when the component sends the notifications, he would add the > JMS timestamp in the message ? Have you checked http://activemq.apache.org/how-do-i-preserve-order-of-messages.html ? So for a given producer, the order is already preserved. For several producers, you could use http://activemq.apache.org/total-ordering.html. I don't think the WS-Notification should do that itself, as it would be very specific to a given use case, so I'd rather rely on an external resequencer if the above is not sufficient. The problem may also come from the WS-Notification component which create a new JMS producer each time Notify message is processed (it may be a good idea to use a pooled session underneath, in which case it should not be a problem). > >>> Points number 1 and 2 are true limitations of the component but points >>> number 3 to 6 are more >>> specific to our customer needs but all these points are related to the >>> core of the ws-notification >>> component --> so my questions : >>> - is there any improvements planned for this component ? > >> nothing planned for the moment because there is (was ?) no need > > ... so, now, there are needs ! :o) > >>> - if I make improvements, will they be included in the future releases of >>> ws-notification component ? > >> Yes, of course ... > >> Guillaume. > >>> Anne. > -- > View this message in context: > http://www.nabble.com/WS-Notification-Component-Improvment-tp19254179p19254179.html > Sent from the ServiceMix - Dev mailing list archive at Nabble.com. > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
