Dynamic component programming model in OSGi

In OSGi deployment model for java, bundles come and go at run time. Hence, dependencies between the bundles would have to be resolved at run time. This would lead to inconsistency as programs cannot be written with confidence referring types from other bundles. Hence a dynamic component programming model has been introduced for bundle developers to addresses the late binding of dependencies.

Dynamic component programming model

  • Introduced the notion of component and service.
  • Mechanism to bind services at run time.


  • A component is a POJO with additional meta information and managed by the OSGi container. With plugin such as Apache felix SCR annotations, all these meta data can be added via annotations which get converted into required XMLs at build time.
  • Every component has an unique name which is also its PID (Persistence Identifier).
  • Component has a lifecycle and it can be started or stopped.
  • Supports extending model – Component can be made abstract. Component can inherit other components.
  • A component can be declared as a factory object. Meaning, Any number of instances of that component can be made at programmers will.
  • Runtime can be instructed to activate a component immediately or lazily (delayed – on first invocation)
  • A component can be marked as configuration factory. New instance could be created for every configuration supplied.
  • A component can be made to be active only when a configuration object is present.
  • A component may have multiple properties (including configurations). Property can be single valued or multivalued.


  • Services are special components which can be injected into other components.
  • In addition to the mechanics of component, service needs an interface. Hence, interfaces are decoupled from the implementations.
  • Interfaces are used to bind services. Selection of right implementation for the given service can be deferred to run time.
  • Services can be injected into components. Using the component property as filters, target filters for selection of right implementation can be defined.
  • An implementation can be registered as a service against multiple interfaces.
  • Services are usually singletons. So, thread safety for the mutable state need to be taken care by the bundle developers.
  • A service can be marked as service factory. Service factory creates new instance for every bundle which uses the service.

Learn more on OSGi design patterns including basics on OSGi trail.

Dynamic component programming model in OSGi