What is the relationship between OSGi and Dependency Injection

Question

What are they of each other?

• Specification and implementation?
• Competitors?
• Unrelated?

Answer 1

They are unrelated.

Edit:

DI is a conecpt first described by Martin Fowler, OSGi is a module system for Java that implements a complete and dynamic component model specified by the OSGi Alliance.

• DI can be used in languages different from Java, OSGi is specific to Java
• OSGi tries to solve the problem of versioned components, DI is an alternative to the old Service Locator pattern.

Answer 2

They are conceptually related in that they both provide a "separation of concerns" mechanisms.

OSGI does this on a module level - think Eclipse architecture with multiple plugins with each being responsible for specific concern/feature.

DI is oriented at the object level - it provides the means for constructing applications out of multiple objects wired together, with each object responsible for its specific functionality.

Technologically they are different. OSGI is a spec that has multiple implementations. DI used to be a design pattern with multiple implementations and APIs. There is some recent work however in JCP to try to standardize DI APIs (JSR 330)

Answer 3

The OSGi specification is composed of two separated parts: core and compendium.

The core part is the specification of a module system for Java. As such, the core specification has no relationship with the concept of DI.

The compendium part, on the other side, specifies a series of services that an OSGi container can provide. Among this services you'll find the "Declarative Services Specification" (OSGi Compendium Services, Chapter 112) that is the first attempt to bring the familiar concept of DI into OSGi. The idea is simple: since OSGi allows the developer to implement, define and register services, the Declarative Services Specification gives the developer the possibility to define a service dependent on a series of other underlying services. That's a particularly interesting (and hard) problem in OSGi, because services are by definition unreliable, and they can appear and disappear.

Beside the Declarative Services Specification, there are at least two other popular solution trying to provide a more powerful DI framework in OSGi:

• Peaberry, an extension of the Guice framework for OSGi
• Spring Dynamic Modules for OSGi (aka Spring DM), the OSGi extension of the Spring Framework

It worth noting that the upcoming R4.2 version of the OSGi specification will contain a new compendium specification named Blueprint Services, that will provide a complete DI solution for OSGi based on the Spring DM framework (the Spring team has heavily contributed to this new specification)