Dependency Injection in OSGi

The OSGi framework and its compendium services provide a whole lot of fun to build applications. Defining bundles is a cool stuff to cut the big job into pieces and enjoy the coolness of separation of concerns just like the old Romans said: Divide et Impera !

One interesting compendium specification is the Declarative Services Specification. This specification tries and IMHO succeeds very well to bring some of the cool stuff of Spring, namely Dependency Injection, into the OSGi world. Just like the application descriptors in Spring you have component descriptors in Declarative Services.

Using a component descriptor, you define the following properties of a component:


  • The name of the component and whether it is activated immediately or not

  • Whether the component is a service and the service interfaces to register the component with

  • Which other services are used by the component. These services may be injected (bound in OSGi speak) or may be looked up. There is also the notion of mandatory and optional services which provides the functionality to delay the component action until the mandatory service becomes available.

  • Configuration properties. Some properties may be injected by the descriptor itself. But at the same time, configuration properties may also be overwritten by configuration from the Configuration Admin Service. Thus the configuration of components may even be very dynamic.



The good news for the XML-haters like me: Over in the Apache Felix project we have Maven 2 plugin which takes annotations (JavaDoc or Java 5 Annotations) from your Component classes and builds the descriptors on your behalf.

So the next time, you are looking for dependency injection, you might want to consider OSGi and Declarative Services ;-)

Just for completeness, here is a list of other frameworks providing some sort of dependency injection:



In the end all work more or less the same, in that the provide some abstraction layer on top of the basic OSGi framework functionality: the Service Registry. This is really, the greatest things of all and IMHO shows the cleverness of the OSGi Framework specification: With just three basic layers (modularity, lifecycle and the service registry), you get the whole world in your hand to build flexible, modular and extensible applications.

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Ready to serve requests ...

In the Apache Sling project we have an interesting problem : Knowing when the application has finished its startup. Coming from a background of a traditional application, you know when the system has finished its startup. For example, a servlet container knows it has finished the startup, when all web applications have been started. In Apache Sling, the situation is a bit different: Apache Sling is an extensible system, where extensions may simply be added by adding more bundles. "Easy", you say, "just wait for all bundles to have been started and you know when the application is ready". True, but there is a catch. To extend Apache Sling, you register services with the OSGi registry. "Still easy", you might say. Right, if the services are all started by bundle activators, we still can depend on having all bundles started for the system to be ready. Again, this is only part of the story: Some services depend on other services. So the dependent services may...
Mehr anzeigen

To embed or to inline ?

At times you want (or need) to include third party libraries in your bundles. You basically have two options to do that: Embed the complete library Inline the required classes/packages (or everything) Until recently I was in the camp of embedding the complete libraries and setting the Bundle-ClassPath manifest header accordingly. The Embed-Dependency directive of the Apache Felix Maven Bundle Plugin makes this extremely easy to do. Lately, though, this has been questioned by Karl Paul's pojosr project. This project brings the OSGi Service Registry to regular applications. The nice thing here is, that it really is a stripped down OSGi Framework basically removing the modularity pillar. The drawback is that this causes the Bundle-ClassPath manifest header and embeddeded libraries to not be supported. Thus to run your regular bundle inside pojosr, you will have to inline all third party libraries instead of embedding them. The upside is that this really works. For example the Apac...
Mehr anzeigen

OSGi DevCon 2013 coming soon

OSGi DevCon 2013 once again is co-located with EclipseCon 2013 taking place in Boston, Massachusetts, between March 25 to 28. See the OSGi Alliance announcement for full details. The call for papers is still open until November 19, so hurry up and submit a talk. For teasers an early bird selection has been taken: Modularity in the Cloud: a Case Study by by Paul Bakker and Marcel Offermans from Luminis. Hop to see you next March in Boston.
Mehr anzeigen