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 to types from other bundles. Hence a dynamic component programming model has been introduced for bundle developers to addresses the late binding of dependencies.

The dynamic component programming model

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

Components

• 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 metadata can be added via annotations which get converted into required XMLs at build time.
• Every component has a unique name which is also its PID (Persistence Identifier).
• The component has a lifecycle and it can be started or stopped.
• Supports extending model – Component can be made abstract. The 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.
• The runtime can be instructed to activate a component immediately or lazily (delayed – on the first invocation)
• A component can be marked as configuration factory. A 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

• Services are special components that can be injected into other components.
• In addition to the mechanics of components, service needs an interface. Hence, interfaces are decoupled from the implementations.
• Interfaces are used to bind services. The selection of the 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 the selection of the 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 needs to be taken care of by the bundle developers.
• A service can be marked as a service factory. The service factory creates a new instance for every bundle which uses the service.