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