felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: EventAdmin jms bridge
Date Tue, 23 Oct 2012 11:40:21 GMT
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 <chris@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


Mime
View raw message