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 that are 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 the isolation scope of the bundles that the OSGi application uses.
The OSGi bundles in the EBA file share services with other OSGi applications by declaring them in an application manifest. 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.
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, the OSGi framework instance that is the parent of all the isolated framework instances of the OSGi applications.
The archive content is used in two different ways, depending on whether an Application-Content header is defined in the application manifest.
If an Application-Content header is not defined, or there is no application manifest, the EBA file content defines the OSGi application content.
If an Application-Content header is defined, the EBA file content defines an initial bundle repository from which bundles can be provisioned.
The application manifest is located at META-INF/APPLICATION.MF and describes modularity at the application level. It uses configuration by exception, that is, you supply values only when you want to override the default. The default, when no application manifest is declared, is that the application content is the set of OSGi bundles contained in the OSGi application, and no external services or references are produced or consumed.
A developer provides an application manifest as part of the development process.
If you do not specify a value, the default value is the application symbolic name.
If you do not specify a value, the default value is the name of the EBA file.
If you do not specify a value but the application name contains an underscore character "_" followed by a valid version value, this value is used. For example, for the application name com.ibm.ws.eba.example_1.2.3.eba, the default value is 1.2.3.
Otherwise, if you do not specify a value, the default value is 0.0.0.
If you do not specify a value, the default is the modules that are contained directly in the root of the EBA file.
bundle_symbolic_name;version
The version format is the same as that used for OSGi import (for example, in the Import-Package syntax).
In OSGi syntax for a version range, brackets [ ] mean include the corresponding lower or upper limit, and parentheses ( ) mean exclude the corresponding lower or upper limit. For example, [1.0.0,2.0.0) means version 1.0.0 and all later versions, up to, but not including, version 2.0.0.
The Application-Content header defines the important applications that compose the business services, but it does not define the full list of bundles in the application. If a bundle that is listed in the content uses a package that is not included in the application, a dependency analysis is performed when the application is deployed and other bundles can be provisioned. Any bundles that are provisioned cannot provide services external to the application and cannot have security applied to them. Such bundles are provisioned to the shared bundle space, rather than being provisioned for each isolated application.
If you do not specify this header, no services are imported. If you do not specify a value, the default is no values.
The format is a comma-separated list of services, in the form of a service interface name, followed by the filter attribute; this attribute specifies an OSGi service filter.
Application-ImportService: com.myclub.security.authenticationService; filter="(security=strong)"
Any services that match the Application-ImportService header are made available for integration, but to actually do the integration you must use Service Component Architecture (SCA). See Using OSGi applications as SCA component implementations.
Your remotable service must support pass-by-value semantics. To match against services that are imported by the Application-ImportService header, your service references must look for the service.imported property.This prevents accidental exposure or use of services that only support local calls and expect pass-by-reference semantics.
If you do not specify this header, no services are exported. If you do not specify a value, the default is no values.
The format is a comma-separated list of services, in the form of a service interface name, followed by the filter attribute; this attribute specifies an OSGi service filter.
Application-ExportService: com.myclub.memberService; filter="(level=silver)"
Any services that match the Application-ExportService header are made available for integration, but to actually do the integration you must use Service Component Architecture (SCA). See Using OSGi applications as SCA component implementations.
Your remotable service must support pass-by-value semantics. To match against services that are exported by the Application-ExportService header, your service must be configured as remotable (that is, registered with the service.exported.interfaces property).This prevents accidental exposure or use of services that only support local calls and expect pass-by-reference semantics.
Often, you do not require a Use-Bundle header, but there are some situations where it is useful. You can use it to restrict the level at which sharing is possible. For example, you can ensure that an application uses the same bundle for package imports that it was tested with. Alternatively, you can ensure that two applications use the same bundle for package imports. By setting the restriction at application level, the bundle can remain flexible.
Manifest-Version: 1.0
Application-ManifestVersion: 1.0
Application-Name: Example Blog
Application-SymbolicName: com.ibm.ws.eba.example.blog.app
Application-Version: 1.0
Application-Content: com.ibm.ws.eba.example.blog.api;version=1.0.0,
com.ibm.ws.eba.example.blog.persistence;version="[1.0.0,1.1.0]",
com.ibm.ws.eba.example.blog.web;version="[1.2.0,1.2.5)"
com.ibm.ws.eba.example.blog;version="(1.2.0,2.0.0)"
Use-Bundle: com.ibm.json.java;version="[1.0.0,2.0.0)"
When you install an OSGi application, the application manifest specifies the bundles that form the primary content of the application. The application manifest might specify an allowed version range for some bundles. Bundles that are listed in the content might use a package that is not included in the application, and therefore require other bundles to be pulled in.
A deployment manifest, META-INF/DEPLOYMENT.MF, is created automatically when you install the EBA asset. It enumerates all the bundles at specific versions that make up the application, including bundles that are determined following dependency analysis. This is the set of bundles that will run each time the application is started. The deployment manifest ensures that each time an application server starts, the bundles that make up the application are the same.
You cannot edit a deployment manifest directly. The following information describes the headers in a generated deployment manifest, but developers and administrators do not need to manipulate this file.
The list includes all the bundles that are listed in the Application-Content header in the application manifest. An administrator can update bundles that are mapped into the Deployed-Content list from the Application-Content list after application deployment.
If a package is imported from both a bundle in the Deployed-Content list and an object in the Deployed-Use-Bundle or Provision-Bundle lists, a ResolverException exception is generated.
A deployment manifest is generated automatically and you cannot edit it directly. However, you can export the current deployment manifest from an EBA asset. If required, you can import a suitable deployment manifest into an EBA asset to use instead of the generated deployment manifest.
This is useful during application development when the application is fully tested and moves to a production environment. You can ensure that the bundles, and their versions, that make up the application in the production environment are exactly the same as the bundles that made up the application in the test environment. To do this, you export the deployment manifest from the EBA asset in the test environment, and import that deployment manifest into the EBA asset in the production environment.
The file to import must be a valid deployment manifest file, using the naming format file_name.MF, for example DEPLOYMENT_TEST.MF. When you import the deployment manifest into the EBA asset, the file is renamed to DEPLOYMENT.MF.
The application resolving process checks whether the deployment manifest contains all the required bundles. It should not need to pull in extra bundles to resolve the EBA asset.
When a deployment manifest is imported successfully, it is used the next time that the application starts.