You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Anne Noseda <no...@gmail.com> on 2008/09/01 14:48:06 UTC
WS-Notification Component Improvment
>> 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.
Re: WS-Notification Component Improvment
Posted by Guillaume Nodet <gn...@gmail.com>.
>>>> 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.
I've just implemented the skeleton for WS-RF-RP support on the
NotificationBroker service.
We need to fill the blanks located in the
JmsNotificationBroker#handleGetResourceProperty method.
See https://issues.apache.org/activemq/browse/SM-1543
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: WS-Notification Component Improvment
Posted by tefo <te...@gmail.com>.
Thanks a lot for the response.
>
> hi Guillaume,
>
> We are using the Servicemix WS-Notification component for our EDA project
> in
> which message reliability is very important. I have noticed that there is
> a
> suggestion for improving the component to support "Durable subscription"
> concept so that consumers/subscribers do not loose messages.
>
> 1) Is this improvement under way for comming releases of wsn-2005
> component
>
*I don't think anyone is working on the wsn2005 component at this time.
> 2) Is there any sample code on how this could be done in the mean time.
>
* Not really. The code need to be enhanced to support durable
subscriptions.
* I think this should be set up using some custom xml in the subscriber
*registration, but i don't think there would be any real problem in doing
*that. Do you plan to work on that ?
My team is currently exploring some possibility of a quick work-around for
this issue in the mean time before a more robust solution comes up. It would
be fantastic to contribute toward the enhancement of the component. So yes
we plan on working on it!
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
View this message in context: http://old.nabble.com/WS-Notification-Component-Improvment-tp19254179p28452549.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: WS-Notification Component Improvment
Posted by Guillaume Nodet <gn...@gmail.com>.
On Sun, May 2, 2010 at 11:01, tefo <te...@gmail.com> wrote:
>
> hi Guillaume,
>
> We are using the Servicemix WS-Notification component for our EDA project
> in
> which message reliability is very important. I have noticed that there is a
> suggestion for improving the component to support "Durable subscription"
> concept so that consumers/subscribers do not loose messages.
>
> 1) Is this improvement under way for comming releases of wsn-2005 component
>
I don't think anyone is working on the wsn2005 component at this time.
> 2) Is there any sample code on how this could be done in the mean time.
>
> Not really. The code need to be enhanced to support durable subscriptions.
I think this should be set up using some custom xml in the subscriber
registration, but i don't think there would be any real problem in doing
that. Do you plan to work on that ?
> Thanks a lot.
>
> cheers
> tefo
>
>
> --
> View this message in context:
> http://old.nabble.com/WS-Notification-Component-Improvment-tp19254179p28425596.html
> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: WS-Notification Component Improvment
Posted by tefo <te...@gmail.com>.
hi Guillaume,
We are using the Servicemix WS-Notification component for our EDA project in
which message reliability is very important. I have noticed that there is a
suggestion for improving the component to support "Durable subscription"
concept so that consumers/subscribers do not loose messages.
1) Is this improvement under way for comming releases of wsn-2005 component
2) Is there any sample code on how this could be done in the mean time.
Thanks a lot.
cheers
tefo
--
View this message in context: http://old.nabble.com/WS-Notification-Component-Improvment-tp19254179p28425596.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: WS-Notification Component Improvment
Posted by Guillaume Nodet <gn...@gmail.com>.
On Tue, Sep 16, 2008 at 12:36 PM, Anne Noseda <no...@gmail.com> wrote:
>
>>>>>>> - 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
>>>>> "
>
>>>> No, and that's the problem. They *should* act as a single subscriber,
>>>> but it does not work this way at the moment.
>
>>> Ok, but have you an idea how to correct this ? I have one but I don't
>>> know
>>> if it is the best ... maybe you have a best way to correct that. My idea
>>> is
>>> the following :
>>> 1. when the servicemix instance receives the JMS notifications from the
>>> topic, it tries to write the JMSMessageID property in a DB table (INSERT
>>> operation, ID is the unique column and the primary key)
>>> 2. if it succeed, the servicemix instance sends the notification
>>> 3. if it fails, the servicemix instance don't send the notification
>>> (writes
>>> a log for example)
>
>> Using durable subscriptions would work. If two JMS consumers have the
>> same durable subscription id, only one of them will receive a given
>> message afaik.
>> We may also want to leverage ActiveMQ virtual destinations instead.
>> See http://activemq.apache.org/virtual-destinations.html for more
>> informations.
>
> About virtual destinations :
> - isn't it too specific to ActiveMQ broker ?
> - if I have well understood the concept, the topic is virtual and for each
> subscriber, one physical queue is created : will the notifications be
> duplicated in all these queues for each subscriber ? if yes, isn't it too
> expansive in term of time and place ?
We may be able to find a way to do both by adding a configuration flag
on the component.
>>> Another point, when an external subscriber sends a subscription message,
>>> this message will be oriented (by an alteon) to one servicemix instance.
>>> This instance will create the JBI endpoint only on this instance or also
>>> on
>>> all the servicemix instances in the cluster ???
>>> Same question for registration of publishers.
>
> You didn't reply ...
I missed that one.
Currently, the WS-Notification components have no knowledge of
clustering, so the subscription / publisher is only valid for the
component that received the request.
At some point in the discussion, we talked about persisting this data
in a database, but it would only work across restart of a single
component. If you need full failover, it means that when a component
receives a subscription or registration, it has to inform the other
components to do so too. I guess we could have a topic for that where
all components would subscribe to and which would be use to send
commands to other components.
At some point for such a system, I guess we might want to use
transactions too...
>
> --
> View this message in context: http://www.nabble.com/WS-Notification-Component-Improvment-tp19254179p19509261.html
> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: WS-Notification Component Improvment
Posted by Anne Noseda <no...@gmail.com>.
>>>>>> - 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
>>>> "
>>> No, and that's the problem. They *should* act as a single subscriber,
>>> but it does not work this way at the moment.
>> Ok, but have you an idea how to correct this ? I have one but I don't
>> know
>> if it is the best ... maybe you have a best way to correct that. My idea
>> is
>> the following :
>> 1. when the servicemix instance receives the JMS notifications from the
>> topic, it tries to write the JMSMessageID property in a DB table (INSERT
>> operation, ID is the unique column and the primary key)
>> 2. if it succeed, the servicemix instance sends the notification
>> 3. if it fails, the servicemix instance don't send the notification
>> (writes
>> a log for example)
> Using durable subscriptions would work. If two JMS consumers have the
> same durable subscription id, only one of them will receive a given
> message afaik.
> We may also want to leverage ActiveMQ virtual destinations instead.
> See http://activemq.apache.org/virtual-destinations.html for more
> informations.
About virtual destinations :
- isn't it too specific to ActiveMQ broker ?
- if I have well understood the concept, the topic is virtual and for each
subscriber, one physical queue is created : will the notifications be
duplicated in all these queues for each subscriber ? if yes, isn't it too
expansive in term of time and place ?
>> Another point, when an external subscriber sends a subscription message,
>> this message will be oriented (by an alteon) to one servicemix instance.
>> This instance will create the JBI endpoint only on this instance or also
>> on
>> all the servicemix instances in the cluster ???
>> Same question for registration of publishers.
You didn't reply ...
--
View this message in context: http://www.nabble.com/WS-Notification-Component-Improvment-tp19254179p19509261.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: WS-Notification Component Improvment
Posted by Guillaume Nodet <gn...@gmail.com>.
On Tue, Sep 16, 2008 at 10:12 AM, Anne Noseda <no...@gmail.com> wrote:
>
>>>>> 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 ?
>
>> Yeah, if we can come up with something generic enough, I see no reason
>> why not including it in the component.
>
> In the same idea, we can maybe use AOP Spring framework which allows to do
> some treatment after or before a method without changing a word in the code
> of the wsn2005 component ...
Not sure how well it would work as the code has not been designed for AOP.
That's still an idea, but I'd lean toward defining an interface personaly.
>>>>> - 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
>>> "
>
>> No, and that's the problem. They *should* act as a single subscriber,
>> but it does not work this way at the moment.
>
> Ok, but have you an idea how to correct this ? I have one but I don't know
> if it is the best ... maybe you have a best way to correct that. My idea is
> the following :
> 1. when the servicemix instance receives the JMS notifications from the
> topic, it tries to write the JMSMessageID property in a DB table (INSERT
> operation, ID is the unique column and the primary key)
> 2. if it succeed, the servicemix instance sends the notification
> 3. if it fails, the servicemix instance don't send the notification (writes
> a log for example)
Using durable subscriptions would work. If two JMS consumers have the
same durable subscription id, only one of them will receive a given
message afaik.
We may also want to leverage ActiveMQ virtual destinations instead.
See http://activemq.apache.org/virtual-destinations.html for more informations.
>
>>>> 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 ?
>
>> We need to persist the subscriptions somehow (to a database for
>> example) and be able to recover and restart those subscriptions when
>> the component starts again, instead of having the subscriber send
>> another request (it may not even be aware that servicemix has shut
>> down and restarted).
>
> Ok, this meets our persistence point. It's not a problem.
>
> Another point, when an external subscriber sends a subscription message,
> this message will be oriented (by an alteon) to one servicemix instance.
> This instance will create the JBI endpoint only on this instance or also on
> all the servicemix instances in the cluster ???
> Same question for registration of publishers.
> --
> View this message in context: http://www.nabble.com/WS-Notification-Component-Improvment-tp19254179p19507284.html
> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: WS-Notification Component Improvment
Posted by Anne Noseda <no...@gmail.com>.
>>>> 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 ?
> Yeah, if we can come up with something generic enough, I see no reason
> why not including it in the component.
In the same idea, we can maybe use AOP Spring framework which allows to do
some treatment after or before a method without changing a word in the code
of the wsn2005 component ...
>>>> - 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
>> "
> No, and that's the problem. They *should* act as a single subscriber,
> but it does not work this way at the moment.
Ok, but have you an idea how to correct this ? I have one but I don't know
if it is the best ... maybe you have a best way to correct that. My idea is
the following :
1. when the servicemix instance receives the JMS notifications from the
topic, it tries to write the JMSMessageID property in a DB table (INSERT
operation, ID is the unique column and the primary key)
2. if it succeed, the servicemix instance sends the notification
3. if it fails, the servicemix instance don't send the notification (writes
a log for example)
>>> 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 ?
> We need to persist the subscriptions somehow (to a database for
> example) and be able to recover and restart those subscriptions when
> the component starts again, instead of having the subscriber send
> another request (it may not even be aware that servicemix has shut
> down and restarted).
Ok, this meets our persistence point. It's not a problem.
Another point, when an external subscriber sends a subscription message,
this message will be oriented (by an alteon) to one servicemix instance.
This instance will create the JBI endpoint only on this instance or also on
all the servicemix instances in the cluster ???
Same question for registration of publishers.
--
View this message in context: http://www.nabble.com/WS-Notification-Component-Improvment-tp19254179p19507284.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: WS-Notification Component Improvment
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Sep 15, 2008 at 4:04 PM, Anne Noseda <no...@gmail.com> wrote:
>
>>> 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 ?
Yeah, if we can come up with something generic enough, I see no reason
why not including it in the component.
>>> - 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
> "
No, and that's the problem. They *should* act as a single subscriber,
but it does not work this way at the moment.
>> 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 ?
We need to persist the subscriptions somehow (to a database for
example) and be able to recover and restart those subscriptions when
the component starts again, instead of having the subscriber send
another request (it may not even be aware that servicemix has shut
down and restarted).
> --
> 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.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: WS-Notification Component Improvment
Posted by Anne Noseda <no...@gmail.com>.
>> 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.
Re: WS-Notification Component Improvment
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Sep 4, 2008 at 1:53 PM, Anne Noseda <no...@gmail.com> 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/
Re: WS-Notification Component Improvment
Posted by Anne Noseda <no...@gmail.com>.
>>> 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.
>>> "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.
>>> 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 ?
- 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 ?
--
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.
Re: WS-Notification Component Improvment
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Sep 3, 2008 at 11:04 AM, Anne Noseda <no...@gmail.com> 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/
Re: WS-Notification Component Improvment
Posted by Anne Noseda <no...@gmail.com>.
"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 ?
" 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>
"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 ?
"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 ?
--
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.
Re: WS-Notification Component Improvment
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Sep 1, 2008 at 2:48 PM, Anne Noseda <no...@gmail.com> 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/