Architected Futures™

Tools and strategies ... for boiling the ocean

Bundles

Overview

Bundle and plug-in are synonymous. Plug-in is the term that was used by the original Eclipse development. Bundle is the term used by OSGi. Bundles (or plug-ins) define the basic unit of component functionality in the system. Applications are constructed as collections of interdependent bundles. Bundles are deployed in specially configured JAR files and are composed of standard Java packages along with special control files. Packages are composed of standard Java types (Classes, Interfaces, Enumerations, etc.).

Manifest

The specifications for a bundle's content and interdependencies are contained in its MANIFEST.MF file. These include:

  • Bundle-SymbolicName combined with Bundle-Version give the bundle a specific identity. Bundle-SymbolicNames are typically formed in a manner similar to Java package names and look like namespace names.
  • Bundle-Name, Bundle-Copyright and Bundle-Vendor may be useful from a legal perspective but are purely documentation from a technical perspective. Bundle-Names are typically formed in a manner that makes sense for human consumption.
  • Export-Package is the specification that details what packages within the bundle are available for use by other bundles. This is the public API of the bundle. Any number of packages may be exported. A distinct version number may be associated with each exported package.
  • Import-Package is the specification that declares dependency on packages that are external to the bundle that this bundle needs in order to function. Any number of packages may be imported. For imported packages a version range may be specified with a lower and upper bound on what versions of that package will satisfy the bundle's  requirements. Note: this dependency is specified for a package, not another bundle.
  • Require-Bundle is used to specify a dependency on another bundle and all of the packages it exports. Best practice advocates that this feature not be used unless there is a specific reason for it such as with multiple bundles that are fragment parts of a single coordinated application structure. Import-Package provides finer granularity to the dependency specification and gives the OSGi infrastructure more flexibility in satisfying the requirement.

Lifecycle

The Bundles are dynamic. They may be installed, started, used, stopped, updated and uninstalled as standard event in a running application. To support this they follow a clear lifecycle as depicted in the following state diagram.

Bundle lifecycle diagram

Bundles start in the installed state. If all dependencies are capable of being met, they move to a resolved state. Once resolved, their classes are loaded and they become eligible for activation. If they need to be updated, or if one or more of their dependencies need to be updated, they are stopped, they move from resolved to unresolved (installed), and need to be resolved again before again becoming active. When no longer needed they are stopped and uninstalled. The OSGi framework is responsible for managing this process. However, if desired, a bundle may participate in its lifecycle by having an activator. The activator can be used tfor initialization, acquisition of resources and other related functions.

Bundles become aware of state changes in their own state or the state of other bundles by subscribing to events. The OSGi framework dispatches events when the state of the bundles, the services or the OSGi framework changes. These include:

  • Service events — these support monitoring of interesting services and are fired when a service is registered, modified or unregistered.
  • Bundle events — these support monitoring bundles of interest to the application and are fired when the any of the state changes indicated in the diagram occur.
  • Framework events — these support monitoring the framework itself, the operating environment for the application, and are fired when the framework is started, when error, warning or information events occur, or when packages that are part of the framework have been refreshed.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
SystemsThinking