Introduction to OSGi Concepts
The OSGi Alliance 1 (http://osgi.org) is an independent consortium with the mission "to create a market for universal middleware". This manifests itself as a set of specifications, reference implementations, and test suites around a dynamic module system for Java. The module system forms the basis for a "service platform" that in turn supports the creation and execution of loosely coupled, dynamic modular systems. Originating in the embedded space, OSGi retains its minimalist approach by producing a core specification of just 27 Java types. This ethic of simplicity and consistency is pervasive in the OSGi specifications.
In this chapter we explore the basic concepts around OSGi and look at how they fit together. You will learn about
- The OSGi framework, its key parts and operation
- Bundles, their structure, and their lifecycle
- Services, extensions, and component collaboration
2.1 A Community of Bundles
An OSGi system is a community of components known as bundles. Bundles executing within an OSGi service platform are independent of each other, yet they collaborate in well-defined ways. Bundles are fully self-describing, declaring their public API, defining their runtime dependencies on other bundles, and hiding their internal implementation.
Bundle writers, producers, create bundles and make them available for others to use. System integrators or application writers, consumers, use these bundles and write still more bundles using the available API. This continues until there is enough functionality available to solve a given problem. Bundles are then composed and configured to create the desired system.
As shown in Figure 2-1, an OSGi application has no top and no bottom—it is simply a collection of bundles. There is also no main program; some bundles contribute code libraries; others start threads, communicate over the network, access databases, or collaborate with still others to gain access to hardware devices and system resources. While there are often dependencies between bundles, in many cases bundles are peers in a collaborative system.
Figure 2-1 An OSGi application as a collection of interdependent bundles
OSGi-based systems are dynamic in that the bundles in the community can change over the lifetime of the application. A bundle can be installed, uninstalled, and updated at any time. To facilitate this, bundles must be implemented to gracefully handle being uninstalled, as well as to respond to the addition, removal, and possible replacement of collaborating bundles.
These characteristics lead to a fundamentally simple but powerful module system upon which other systems can be built. Indeed, modularity and OSGi bundles are among the secrets to the success of Eclipse as a platform and as an ecosystem. In any suitably large system it is increasingly unlikely that all components will be written by the same producer. In fact, in an OSGi system such as an Eclipse application, it is common for bundles to come from a variety of producers, such as open-source projects, corporations, and individuals. The strong modularity promoted and supported by OSGi dramatically increases the opportunity for code reuse and accelerates the delivery of applications.