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