OSGi Declarative Services vs. Blueprint Services

Yesterday, I learned that OSGi Declarative Services (DS) and Blueprint Services (BS) are two different things. That was truly a D’Oh moment.

In DS, you create one component.xml file for each Service you want to share, which outlines the references to other services among other things. Overall this seems to be a nice alternative to writing bundle activators, but nothing earth shattering. On the bright side, DS is supported by Equinox for some time already, given you have the org.eclipse.equinox.ds bundle in your target platform.

Now with BS, things get more interesting. It’s basically the Spring way of doing things applied to the OSGi world. The XML configuration files of BS look very familiar when you have past experience with Spring-powered J2EE apps. You can define all the Services your bundle provides in one XML file, wire them up with other services and so on.

BS also go a long way trying to hide the dynamic nature of OSGi from you. That is, if you reference a service from another bundle, and that service is not immediately available, your bundle will wait for a grace period before failing to deploy. Good stuff.

The downside of BS is that it is not widely supported yet. In fact, the reference implementation, Eclipse Gemini Blueprint (formerly known as Spring Dynamic Modules 2.0), is still at Milestone 1.

To me, the conculsion of all this is that DS and BS are two very different things, and that BS will be a much better choice once it becomes widely supported.

One thought on “OSGi Declarative Services vs. Blueprint Services”

Comments are closed.