Component Models Overview

From OSGi Community Wiki

Jump to: navigation, search


Various Component Models exist for OSGi. Though they vary significantly in their goals and implementation details, they have some common features:

Two component models — Declarative Services and Blueprint — are defined by the OSGi specification and have multiple implementations. Some other models are derived from or wrap a pre-existing framework such as Spring-DM (based on the Spring Framework), or Peaberry (based on Google Guice). Others such as iPOJO were designed from scratch to work well in OSGi but are not part of any specification. Finally ScalaModules is a DSL in the Scala programming language for working with the OSGi APIs.

Interoperability

Each component model reflects different design goals, choices and compromises about features to include or omit. As such there is no single model that is "best" for all tasks -- though naturally each model has its evangelists and detractors.

However, a beautiful property of OSGi is that all of these component models interoperate perfectly through OSGi services. Each focuses on consuming and providing services, therefore it is possible for services provided from a Peaberry/Guice bundle to be consumed by a bundle that uses Spring-DM, or vice versa.

Therefore the choice of component model is an internal implementation detail for a bundle, and we can in theory use many models in one application. It is not desirable to do this arbitrarily — each new model does carry costs, in terms of developer training and additional supporting bundles — but we do not need to fear using third-party components developed with other models, nor do we need to worry about committing to a particular model and never being able to change our minds in the future.

Personal tools
Namespaces
Variants
Actions
Navigation
JavaDoc
Wiki
Toolbox