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 <[email protected]>:
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:[email protected]] 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
