You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Christian Schneider <ch...@die-schneider.net> on 2012/10/09 15:23:26 UTC
EventAdmin jms bridge
Hi all,
I have implemented a first prototype of a jms bridge for the EventAdmin
service.
The idea is to be able to transparently send Events between OSGi
containers using a jms provider.
The current status is that events can be published and received and the
jms ConnectionFactory is bound as an OSGi service.
The following is missing:
- Configuration which jms ConnectionFactory to use if there are more
than one
- Configuration of the topic prefix on the jms server
- Configuration of the EventAdmin topics to send / receive as typically
you will not want all to be sent
- Ignoring our own events to avoid loops
If there is interest in the felix community I would like to donate the
bridge.
I have already used the felix project structure and package names to
make it easy to integrate.
The current code can be found here:
https://github.com/cschneider/event-admin-jms
What do you think?
Christian
Re: EventAdmin jms bridge
Posted by Christian Schneider <ch...@die-schneider.net>.
I think the special property is also not universal. It works very well
if you have the code under your control but it would not work if you
want to make "legacy" event code remote able. So I think we need a
mixture. I also think a blacklist may have some merrit.
In any case I think it is important to be able to use wildcards. Like
org/mycompany/* to white or blacklist a whole hierarchy. That should
make it much easier to configure.
Another thing to consider is how to listen to jms topics. I currently
implemented just one listener that listens to the whole hierarchy on
jms. After talking to someone who also implemented such a bridge I think
it may be necessary to dynamically listen to only the parts of the topic
tree the container is really interested in. Else receiving all events
and discarding 90% may be quite a waste of resources.
Best regards
Christian
Am 23.10.2012 13:15, schrieb Carsten Ziegeler:
> Hi Christian,
>
> I like your idea and I think it's valuable to have such a mechanism.
> If I understand your solution correctly, you configure somewhere which
> events are sent via the bridge by listing the topics, right?
>
> I'm not sure whether this configuration is the way to go or not. In
> Apache Sling we have a solution which is able to distribute OSGi
> events in a clustered installation (assuming that the JMS is hooked up
> to all cluster nodes, this is pretty similar in the result). We
> started with a configuration of topics, but soon found out that you
> never know all the potential topics that might be send in your
> instance.
> Another idea was to use a black list, so basically all events are
> distributed except those in the black list (like bundle or framework
> events). This wasn't a good idea either as we ended up with too many
> events being distributed.
> Then we came up with the conclusion that the only person who knows
> about such things is the code which sents the event. By default an
> event is not distributed, but as soon as it contains a special
> property it is.
>
> WDYT?
>
> Regards
> Carsten
>
> 2012/10/12 Christian Schneider <ch...@die-schneider.net>:
>> I have also looked into the Remote Services Spec. The problem is that Remote
>> Services work a bit differently.
>> At least in current implementations you get a local proxy for each remote
>> service that is detected. You also have to bind to one of those services to
>> send to the
>> respective remote service. So typically in Remote Services you have kind of
>> a point to point behaviour.
>>
>> When doing Events you typically want rather publish / subscribe. Basically
>> many containers subscribe to all the topics they are interested in and you
>> send the event then only once.
>> I have no idea how I would create that behaviour with Remote Services.
>>
>> Btw. the idea for the jms bridge for Events was based on a master thesis
>> about distributed OSGi. In the thesis a jms bridge for Events was used to
>> implement the Discovery port of the Remote Service Admin spec.
>> So in that case it was the other way round. They used remote events over jms
>> to implement Remote Services. I found the idea to transport Events over jms
>> very natural so I implemented a similar bridge.
>>
>> In any case I am open to suggestions. Regarding remote services I just did
>> not yet understand how I would apply them.
>>
>> Christian
>>
>>
>>
>> On 10/12/2012 03:05 PM, Nick Wilson wrote:
>>> Hi Christian,
>>>
>>> Have you had a look at the Enterprise OSGi Remote Services specification?
>>> I provides an easy way to publish services (including event handlers) to
>>> remote containers by just adding a few properties to the service.
>>>
>>> It sounds like your prototype is doing very similar work, and nothing
>>> wrong with JMS as a transport. Might be worth considering the Remote
>>> Services spec. if you want to expand it beyond just events.
>>> Regards,
>>>
>>> Nick
>>>
>>>
>>> -----Original Message-----
>>> From: Christian Schneider [mailto:cschneider111@gmail.com] On Behalf Of
>>> Christian Schneider
>>> Sent: 12 October 2012 10:00
>>> To: Felix Dev
>>> Subject: Re: EventAdmin jms bridge
>>>
>>> Hi all,
>>>
>>> I would be happy to get some feedback about my proposed EventAdmin jms
>>> bridge.
>>> I am fully aware that is not yet ready for addition but I wanted to get
>>> feedback early in the development.
>>>
>>> So what do you think? Is it a good idea to send Events to remote
>>> containers? Is jms the right transport?
>>> .. and of course is felix the right place for such a project?
>>>
>>> Best regards
>>>
>>> Christian
>>>
>>> Am 09.10.2012 15:23, schrieb Christian Schneider:
>>>> Hi all,
>>>>
>>>> I have implemented a first prototype of a jms bridge for the
>>>> EventAdmin service.
>>>> The idea is to be able to transparently send Events between OSGi
>>>> containers using a jms provider.
>>>>
>>>> The current status is that events can be published and received and
>>>> the jms ConnectionFactory is bound as an OSGi service.
>>>>
>>>> The following is missing:
>>>> - Configuration which jms ConnectionFactory to use if there are more
>>>> than one
>>>> - Configuration of the topic prefix on the jms server
>>>> - Configuration of the EventAdmin topics to send / receive as
>>>> typically you will not want all to be sent
>>>> - Ignoring our own events to avoid loops
>>>>
>>>> If there is interest in the felix community I would like to donate the
>>>> bridge.
>>>> I have already used the felix project structure and package names to
>>>> make it easy to integrate.
>>>>
>>>> The current code can be found here:
>>>> https://github.com/cschneider/event-admin-jms
>>>>
>>>> What do you think?
>>>>
>>>> Christian
>>>>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: EventAdmin jms bridge
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Christian,
I like your idea and I think it's valuable to have such a mechanism.
If I understand your solution correctly, you configure somewhere which
events are sent via the bridge by listing the topics, right?
I'm not sure whether this configuration is the way to go or not. In
Apache Sling we have a solution which is able to distribute OSGi
events in a clustered installation (assuming that the JMS is hooked up
to all cluster nodes, this is pretty similar in the result). We
started with a configuration of topics, but soon found out that you
never know all the potential topics that might be send in your
instance.
Another idea was to use a black list, so basically all events are
distributed except those in the black list (like bundle or framework
events). This wasn't a good idea either as we ended up with too many
events being distributed.
Then we came up with the conclusion that the only person who knows
about such things is the code which sents the event. By default an
event is not distributed, but as soon as it contains a special
property it is.
WDYT?
Regards
Carsten
2012/10/12 Christian Schneider <ch...@die-schneider.net>:
> I have also looked into the Remote Services Spec. The problem is that Remote
> Services work a bit differently.
> At least in current implementations you get a local proxy for each remote
> service that is detected. You also have to bind to one of those services to
> send to the
> respective remote service. So typically in Remote Services you have kind of
> a point to point behaviour.
>
> When doing Events you typically want rather publish / subscribe. Basically
> many containers subscribe to all the topics they are interested in and you
> send the event then only once.
> I have no idea how I would create that behaviour with Remote Services.
>
> Btw. the idea for the jms bridge for Events was based on a master thesis
> about distributed OSGi. In the thesis a jms bridge for Events was used to
> implement the Discovery port of the Remote Service Admin spec.
> So in that case it was the other way round. They used remote events over jms
> to implement Remote Services. I found the idea to transport Events over jms
> very natural so I implemented a similar bridge.
>
> In any case I am open to suggestions. Regarding remote services I just did
> not yet understand how I would apply them.
>
> Christian
>
>
>
> On 10/12/2012 03:05 PM, Nick Wilson wrote:
>>
>> Hi Christian,
>>
>> Have you had a look at the Enterprise OSGi Remote Services specification?
>> I provides an easy way to publish services (including event handlers) to
>> remote containers by just adding a few properties to the service.
>>
>> It sounds like your prototype is doing very similar work, and nothing
>> wrong with JMS as a transport. Might be worth considering the Remote
>> Services spec. if you want to expand it beyond just events.
>> Regards,
>>
>> Nick
>>
>>
>> -----Original Message-----
>> From: Christian Schneider [mailto:cschneider111@gmail.com] On Behalf Of
>> Christian Schneider
>> Sent: 12 October 2012 10:00
>> To: Felix Dev
>> Subject: Re: EventAdmin jms bridge
>>
>> Hi all,
>>
>> I would be happy to get some feedback about my proposed EventAdmin jms
>> bridge.
>> I am fully aware that is not yet ready for addition but I wanted to get
>> feedback early in the development.
>>
>> So what do you think? Is it a good idea to send Events to remote
>> containers? Is jms the right transport?
>> .. and of course is felix the right place for such a project?
>>
>> Best regards
>>
>> Christian
>>
>> Am 09.10.2012 15:23, schrieb Christian Schneider:
>>>
>>> Hi all,
>>>
>>> I have implemented a first prototype of a jms bridge for the
>>> EventAdmin service.
>>> The idea is to be able to transparently send Events between OSGi
>>> containers using a jms provider.
>>>
>>> The current status is that events can be published and received and
>>> the jms ConnectionFactory is bound as an OSGi service.
>>>
>>> The following is missing:
>>> - Configuration which jms ConnectionFactory to use if there are more
>>> than one
>>> - Configuration of the topic prefix on the jms server
>>> - Configuration of the EventAdmin topics to send / receive as
>>> typically you will not want all to be sent
>>> - Ignoring our own events to avoid loops
>>>
>>> If there is interest in the felix community I would like to donate the
>>> bridge.
>>> I have already used the felix project structure and package names to
>>> make it easy to integrate.
>>>
>>> The current code can be found here:
>>> https://github.com/cschneider/event-admin-jms
>>>
>>> What do you think?
>>>
>>> Christian
>>>
>>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: EventAdmin jms bridge
Posted by Christian Schneider <ch...@die-schneider.net>.
I have also looked into the Remote Services Spec. The problem is that
Remote Services work a bit differently.
At least in current implementations you get a local proxy for each
remote service that is detected. You also have to bind to one of those
services to send to the
respective remote service. So typically in Remote Services you have kind
of a point to point behaviour.
When doing Events you typically want rather publish / subscribe.
Basically many containers subscribe to all the topics they are
interested in and you send the event then only once.
I have no idea how I would create that behaviour with Remote Services.
Btw. the idea for the jms bridge for Events was based on a master thesis
about distributed OSGi. In the thesis a jms bridge for Events was used
to implement the Discovery port of the Remote Service Admin spec.
So in that case it was the other way round. They used remote events over
jms to implement Remote Services. I found the idea to transport Events
over jms very natural so I implemented a similar bridge.
In any case I am open to suggestions. Regarding remote services I just
did not yet understand how I would apply them.
Christian
On 10/12/2012 03:05 PM, Nick Wilson wrote:
> Hi Christian,
>
> Have you had a look at the Enterprise OSGi Remote Services specification? I provides an easy way to publish services (including event handlers) to remote containers by just adding a few properties to the service.
>
> It sounds like your prototype is doing very similar work, and nothing wrong with JMS as a transport. Might be worth considering the Remote Services spec. if you want to expand it beyond just events.
> Regards,
>
> Nick
>
>
> -----Original Message-----
> From: Christian Schneider [mailto:cschneider111@gmail.com] On Behalf Of Christian Schneider
> Sent: 12 October 2012 10:00
> To: Felix Dev
> Subject: Re: EventAdmin jms bridge
>
> Hi all,
>
> I would be happy to get some feedback about my proposed EventAdmin jms bridge.
> I am fully aware that is not yet ready for addition but I wanted to get feedback early in the development.
>
> So what do you think? Is it a good idea to send Events to remote containers? Is jms the right transport?
> .. and of course is felix the right place for such a project?
>
> Best regards
>
> Christian
>
> Am 09.10.2012 15:23, schrieb Christian Schneider:
>> Hi all,
>>
>> I have implemented a first prototype of a jms bridge for the
>> EventAdmin service.
>> The idea is to be able to transparently send Events between OSGi
>> containers using a jms provider.
>>
>> The current status is that events can be published and received and
>> the jms ConnectionFactory is bound as an OSGi service.
>>
>> The following is missing:
>> - Configuration which jms ConnectionFactory to use if there are more
>> than one
>> - Configuration of the topic prefix on the jms server
>> - Configuration of the EventAdmin topics to send / receive as
>> typically you will not want all to be sent
>> - Ignoring our own events to avoid loops
>>
>> If there is interest in the felix community I would like to donate the
>> bridge.
>> I have already used the felix project structure and package names to
>> make it easy to integrate.
>>
>> The current code can be found here:
>> https://github.com/cschneider/event-admin-jms
>>
>> What do you think?
>>
>> Christian
>>
>
RE: EventAdmin jms bridge
Posted by Nick Wilson <ni...@weareact.com>.
Hi Christian,
Have you had a look at the Enterprise OSGi Remote Services specification? I provides an easy way to publish services (including event handlers) to remote containers by just adding a few properties to the service.
It sounds like your prototype is doing very similar work, and nothing wrong with JMS as a transport. Might be worth considering the Remote Services spec. if you want to expand it beyond just events.
Regards,
Nick
-----Original Message-----
From: Christian Schneider [mailto:cschneider111@gmail.com] On Behalf Of Christian Schneider
Sent: 12 October 2012 10:00
To: Felix Dev
Subject: Re: EventAdmin jms bridge
Hi all,
I would be happy to get some feedback about my proposed EventAdmin jms bridge.
I am fully aware that is not yet ready for addition but I wanted to get feedback early in the development.
So what do you think? Is it a good idea to send Events to remote containers? Is jms the right transport?
.. and of course is felix the right place for such a project?
Best regards
Christian
Am 09.10.2012 15:23, schrieb Christian Schneider:
> Hi all,
>
> I have implemented a first prototype of a jms bridge for the
> EventAdmin service.
> The idea is to be able to transparently send Events between OSGi
> containers using a jms provider.
>
> The current status is that events can be published and received and
> the jms ConnectionFactory is bound as an OSGi service.
>
> The following is missing:
> - Configuration which jms ConnectionFactory to use if there are more
> than one
> - Configuration of the topic prefix on the jms server
> - Configuration of the EventAdmin topics to send / receive as
> typically you will not want all to be sent
> - Ignoring our own events to avoid loops
>
> If there is interest in the felix community I would like to donate the
> bridge.
> I have already used the felix project structure and package names to
> make it easy to integrate.
>
> The current code can be found here:
> https://github.com/cschneider/event-admin-jms
>
> What do you think?
>
> Christian
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
________________________________________________________________________
This e-mail has been scanned for all viruses.
________________________________________________________________________
Re: EventAdmin jms bridge
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi all,
I would be happy to get some feedback about my proposed EventAdmin jms
bridge.
I am fully aware that is not yet ready for addition but I wanted to get
feedback early in the development.
So what do you think? Is it a good idea to send Events to remote
containers? Is jms the right transport?
.. and of course is felix the right place for such a project?
Best regards
Christian
Am 09.10.2012 15:23, schrieb Christian Schneider:
> Hi all,
>
> I have implemented a first prototype of a jms bridge for the
> EventAdmin service.
> The idea is to be able to transparently send Events between OSGi
> containers using a jms provider.
>
> The current status is that events can be published and received and
> the jms ConnectionFactory is bound as an OSGi service.
>
> The following is missing:
> - Configuration which jms ConnectionFactory to use if there are more
> than one
> - Configuration of the topic prefix on the jms server
> - Configuration of the EventAdmin topics to send / receive as
> typically you will not want all to be sent
> - Ignoring our own events to avoid loops
>
> If there is interest in the felix community I would like to donate the
> bridge.
> I have already used the felix project structure and package names to
> make it easy to integrate.
>
> The current code can be found here:
> https://github.com/cschneider/event-admin-jms
>
> What do you think?
>
> Christian
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com