+

Search Tips   |   Advanced Search

Enterprise bundle archives

An enterprise bundle archive (EBA) file contains a set of OSGi bundles that are deployed as a single OSGi application, and that are isolated from other OSGi applications.

Each OSGi application runs in its own isolated OSGi framework instance with its own OSGi service registry. Bundles in one OSGi application cannot see bundles, services, or packages that are defined in another OSGi application, unless the bundles, services, or packages are explicitly shared by both applications.

The bundles used by the OSGi application are either directly contained in the EBA file, or pulled in by reference from an OSGi bundle repository when the application is provisioned. Application metadata stored in the EBA file defines solation scope of the bundles that the OSGi application uses.

An EBA file is packaged as a single compressed archive file with a .eba file extension. It can contain an application manifest, and a set of application modules. An application module can be one of the following types of resource:

Application modules are contained in the root of the EBA file. These modules are directly contained in the OSGi application, whereas all other bundles are provided by reference.

An OSGi application can also use metadata to permit some of its constituent bundles to be shared. Sharing in this way can reduce the memory and resource requirements of a system. Shared bundles must be provided by reference rather than contained directly in an application.

An OSGi application can also load packages and consume OSGi services from a shared bundle space, that is, from the OSGi framework instance that is the parent of all solated framework instances of the OSGi applications.


Application manifest

The OSGi bundles in an EBA file share services with other OSGi applications by declaring them in an application manifest file, META-INF/APPLICATION.MF. Any external services and references that the OSGi application produces are exposed by declaring them in the manifest, and any external services and references that the application consumes are also declared in the manifest.

The application manifest specifies the bundles that form the primary content of the application. A bundle that is listed in the primary content might use a package that is not included in the application, and therefore require other bundles to be pulled in. The application manifest might also specify an allowed version range for some bundles; this range defines nitial version of the application, and the latest version to which it can be upgraded.

Optionally, we can explicitly declare shared bundles on which the primary application content depends so that we can restrict the level at which sharing is possible; for example, we can ensure that the application uses a shared bundle only between a specified version range. For more information, see the description of the "Use-Bundle" header in Example: OSGi application manifest file.

An EBA file does not have to contain an application manifest file. The contents of the EBA file is used in two different ways, depending on whether we have included an application manifest, and on whether an Application-Content header is defined in the application manifest:

See Example: OSGi application manifest file.


Deployment manifest

A deployment manifest file, META-INF/DEPLOYMENT.MF, is created automatically when you import an EBA asset. The deployment manifest file lists, at specific versions, all the bundles and composite bundles that make up the application, including bundles that are determined following dependency analysis. The manifest file is used to ensure that each time an application server starts, the bundles that make up the application are the same.

You can export the current deployment manifest from an EBA asset, then import the deployment manifest into another asset containing the same application. The target asset then uses mported manifest instead of the generated manifest. This is useful during application development, when an application is fully tested and moves to a production environment. By importing the deployment manifest from the test environment, you ensure that the bundles and their versions that make up the application in the production environment are exactly the same as the bundles that make up the application in the test environment.

See OSGi deployment manifest file and Export and import a deployment manifest file.


Subtopics


Parent topic: OSGi bundles and bundle archives


Related concepts

  • Composite bundles
  • Application bundles, use bundles and provision bundles
  • Web application bundles
  • EJB bundles
  • Bundle and package versioning
  • Manifest files
  • OSGi application isolation and sharing


    Related tasks

  • Administer OSGi applications
  • Create an OSGi application
  • Deploy an OSGi application as a business-level application


    OSGi Alliance Specifications

  • Example: OSGi application manifest file
  • OSGi deployment manifest file
  • Converting an enterprise application to an OSGi application
  • Converting an EJB JAR file to an OSGi EJB bundle
  • Converting a utility JAR file to an OSGi bundle
  • Converting a persistence archive file to an OSGi bundle
  • Converting a web application archive file to an OSGi web application bundle