felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bartlett <njbartl...@gmail.com>
Subject Re: Building better OSGi applications
Date Thu, 17 Jul 2014 09:49:36 GMT
I agree with everything said so far, but nobody directly addressed your question about performance
impact. Whichever approach you use, service binding/unbinding glue should NOT affect wall-clock
performance, since service events are comparatively rare. Once a service is bound there is
no overhead at all, since the consumer of the service gets the actual real object that was
published by the provider… so when you invoke a service method, it is direct invocation
that goes as fast as any method cal can go in Java.

The exception to this is if you use Blueprint, because Blueprint does use proxies and sometimes
blocks calling threads. I would not recommend Blueprint in an embedded or performance-critical

However I would expect that using DS will *improve* the memory consumption of most applications.
As you said, you are writing a lot of glue code, which is hard to get right and even harder
to optimise. DS centralises the glue into one place, and has been worked on for a long time
by some of the smartest developers in the world.

Some people avoid DS in very constrained embedded environments. But even there I find it strange
that people are willing to pay for the large overhead of using Java but not the small additional
overhead of using DS to drastically simplify their code!


On 17 July 2014 at 10:28:29, Pierre De Rop (pierre.derop@gmail.com) wrote:

Hi Philipp;  

I'm using DM and DS in some large applications (~400 bundles, ~1000  
services), and I confirm that both DM and DS are fast.  

If you want to give a try to DM java API, you can take a look at [1]. it's  
a simple but powerful API, which allows to not only declare simple  
services, but also service aspects (interceptors), service adapters,  
configuration dependencies, etc ...  

DS will also allow you to declare your services easily. As suggested by  
Ferry, you can take a look at the bndtools faq from [2], but the FAQ from  
[3] is also useful and concise.  

[1] http://felix.apache.org/site/apache-felix-dependency-manager.html  
[2] http://bndtools.org/tutorial.html  
[3] http://wiki.osgi.org/wiki/Declarative_Services  

hope this helps;  

kind regards;  

On Thu, Jul 17, 2014 at 10:19 AM, Paul Bakker <paul.bakker@luminis.eu>  

> Definetly use either Felix Dependency Manager (that's what I use on all  
> projects) or Declarative Services. DS is slightly simpler, DM is more  
> powerful. The main difference is that DM can also be used from code to  
> register/deregister components at any given time.  
> Both solutions will solve the problem you are describing, which is a very  
> common one :-)  
> Cheers,  
> Paul  
> On Thu, Jul 17, 2014 at 10:04 AM, Bulu <bulu@romandie.com> wrote:  
> > Hi all  
> >  
> > I'm building an application on an embedded system which will contain ~20  
> > bundles.  
> >  
> > There are many dependencies of services - say for example to provide its  
> > service, module A (several classes) needs services B,C,D.  
> > In order to fully account for the dynamics of OSGi, I have to monitor  
> > B,C,D to stop A when any of these 3 goes away. This unregisters service  
> A,  
> > which in turn will disrupt all clients of A.  
> > If additionally you want to handle part case (A should still provide a  
> > reduced service, if only B and C are available but not D) it gets messy  
> > rapidly.  
> >  
> > In the end, I realize that I am mostly writing life cycle code instead of  
> > business logic and I have lots of OSGi dependencies, with the  
> BundleContect  
> > passed around nearly everywhere. This smells like bad design.  
> >  
> > Could you share insights or recommend reading on how to structure OSGi  
> > services for cohesion and modularity, to avoid the problems above?  
> > Are there ways to reduce the boiler plate?  
> > Should I be investigating declarative services, iPojo or others (in  
> > general I prefer writing code than XML...). As this is an embedded  
> system,  
> > should I be worried about the performance impact of DS?  
> >  
> >  
> > Thanks for your insights  
> > Philipp  
> >  
> >  
> >  
> > ---------------------------------------------------------------------  
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org  
> > For additional commands, e-mail: users-help@felix.apache.org  
> >  
> >  

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message