WeigleWilczek Company Blog

Some weeks ago blogged about a comparison of OSGi DS and Spring DM. I tried to be as unbiased as possible and I obviously did not upset anyone as I only received nice comments. Now I think it is time to express my personal opinion about this comparison.

For me the most important thing considering this comparison is Dependency Injection (DI). I simply cannot live without it. That is not because I can configure my objects via XML (in fact I do not like XML that much) or some other means which is just a matter of programming. I am talking about design for flexibility and testability. When my objects are „passive“ and all relations to the world outside are injected by some kind of runtime, they adapt to different environments easily. And of course real unit testing - testing the sole objects and not half the system - is greatly enhanced by such a design.

Spring DM of course offers sophisticated DI, no need to detail on that. OSGi DS however offers only very limited DI capabilities. Service references may be injected, but what about non-service properties? There are Component Properties, but these are restricted to a limited type set and they have to be retrieved actively from the ComponentContext and therefore pollute my objects with OSGi API.

OK, to be fair, let‘s try using OSGi DS and some kind of full featured DI framework together. Well, this will not work, because DI solutions require to manage the life cycle of the objects, i.e. create the instances. And that is what OSGi DS also does. Ever since Highlander we know that there can only be one, and if we use OSGi DS we cannot also use another DI framework for the same objects.

From these considerations I clearly decide on Spring DM as the preferable declarative service component model and I am looking forward to having it standardized in the 4.2 specification.

The OSGi Framework provides a powerful service model. However its dynamic nature brings about a certain degree of complexity which makes using it a challenging task. In order to simplify the programming model there are several solutions around, most notably OSGi Declarative Services (DS), Spring Dynamic Modules (DM) and Apache Felix iPOJO.

DS offers a declarative service component model and is already an OSGi standard specified in the OSGi Service Compendium. According to the early draft of the OSGi 4.2 specification Spring Dynamic Modules will heavily influence RFC 124 and eventually be the second standardized service component model.

There have been quite a few discussions in the community like “Do we really need two service component models?“ or “This one is the better!“. Before jumping in, I would like to know the differences, but as U2 I still haven‘t found what I am looking for. Therefore I started comparing DS and DM on my own and I also asked some people (special kudos to Neil) about their opinion. In the following I will list the most important differences which I found out so far. Your comments and additions are very welcome!

Intra-bundle referencing

DS Service Components may reference any OSGi services, but it is not possible to declare a reference to another Service Component (in the same bundle) “directly“. This other Service Component has to publish a service in order to be referenced. DM builds upon the DI container of the Spring Framework and therefore any beans within an Application Context may be wired together independent of service exposure.

In my opinion using DS might lead to exposing too many services, even if this functionality is only used bundle-internal.

Component life cycle

DS Service Components have got their own individual life cycle. If all references are satisfied a Service Component is activated or ready to be activated (in case of a Delayed Component) independent of other Service Components. DM will suspend the creation of an Application Context until all mandatory dependencies are satisfied. Therefore no services will be published from the whole bundle if only one mandatory dependency cannot be resolved. This in turn might influence the creation of other Application Contexts.

In my opinion DM might introduce an unnecessary coupling between otherwise unrelated services.

Configuration

DS Service Components can provided properties statically or via the Configuration Admin Service. The values are limited to Strings, primitive types and their wrappers as well as arrays and Vectors of these. A Service Component has to actively access these properties by means of OSGi API. DM offers the whole power of Spring‘s DI for static configuration but no support for the Configuration Admin Service yet.

In my opinion DS configuration is too intrusive as it misses the POJO and DI paradigms.

Having said this, I want to point out, that there is no need to lock-in on one solution. DS and DM are built on top of the core OSGi service model and will work seamlessly together.