The WebSphere programming model and OSGi
The OSGi Applications programming model in WebSphere Application Server enables you to develop, assemble, and deploy modular applications that use Java™ EE and OSGi technologies. You can use tooling to deploy an enterprise application as an OSGi application that consists of one or more OSGi bundles.
The benefits of deploying an application as a set of bundles are described in Business goals and OSGi Applications.
The OSGi Applications programming model in WebSphere Application Server enables both new and existing applications to be deployed as OSGi applications. An existing enterprise application can be deployed as an OSGi application in which each component is converted to an OSGi bundle, as described in Converting an enterprise application to an OSGi application. You can develop new applications as OSGi Application projects as described in Develop an OSGi application. A new application might consist of two bundles, where each one contains business logic in plain old Java objects (POJOs), wired together through a Blueprint module definition, or by invoking an enterprise bean. The granularity of the bundle is such that each bundle has a coherent function in the context of an enterprise application. One bundle provides a service that the other bundle requires. The Blueprint Container in WebSphere Application Server wires the components in a bundle by creating component (bean) instances and injecting its dependencies. When a component in Bundle B, an EJB bundle, offers a service that Bundle A requires, the Blueprint Container takes care of registering the service in the service registry and injecting a service reference into the consuming component in Bundle A.
Figure 1. OSGi application with two bundles
For example, consider an application that represents a weblog service. A weblog business logic bundle exports a service that can be consumed by a web application bundle that handles HTTP clients for this service. The weblog bundle depends on two other bundles; one to provide persistence to a database, and one to provide a service so that readers of the weblog can post comments to the weblog. The weblog business logic bundle consists internally of three components whose configuration and references are injected into them at run time.
Figure 2. Example application for a weblog service
If we have used a dependency injection framework such as the Spring Framework, the XML module Blueprint configuration for the components in the weblog business bundle will be familiar. Each component is defined, along with the references and configurations that need to be injected. Specifically:
- Each service that needs to be automatically published to the service
registry is defined.
- Each reference that needs to be resolved automatically from the service registry for injection into a component is declared.
OSGi services provide a way to represent dependencies between bundles. Services have the same life cycle as the bundle that provides them. The underlying server run time wires services dynamically when bundles are started and stopped.
Unit test
Unit test for Blueprint components is simplified by the dependency injection pattern, which allows one bean to access another bean without having to implement any code to create the bean instance. The Blueprint Container creates the required bean instance, using information contained in the Blueprint configuration file. This eliminates compiled dependencies on either the OSGi Framework or the application server runtime environment. In the weblog application example, we can write a Java unit test for the weblog component that can run in a simple Java SE environment, or an integrated development environment (IDE), with no need to install the component to its target runtime environment. The unit test can include the following actions:
- Creation of a new weblog comment bean, rather than creation by the Blueprint Container.
- Injection of the configuration relevant to the test.
- Test the function of the weblog comment bean.
OSGi Applications support
An OSGi application is a collection of one or more OSGi modules that together provide a coherent business function. An OSGi application can consist of modules of many different types. For example, the weblog example described earlier might consist of bundles with web content (web application bundles), bundles with Blueprint contexts, EJB bundles, and bundles with JPA entities and persistence configuration (persistence bundles).
The modules contained in an OSGi application can offer OSGi services. The OSGi Applications support isolates those OSGi services so that they are not visible outside the application, unless they are explicitly configured to be exported from the application. OSGi applications have several ways to accept workloads:
- An OSGi application can include web bundles to process HTTP workloads.
- When the modules contained in an application offer OSGi services, an OSGi application can export one or more of those services to other OSGi applications, by using Service Component Architecture (SCA); for further information, see SCA and OSGi Applications.
An OSGi application isolates the OSGi services that are offered to modules contained in the application. The modules cannot consume services outside the application unless they are explicitly configured to import them. These imported services might be proxies to other OSGi application services or proxies to remote services (for example, web services); these proxies are provided by SCA.
In the following example, an OSGi application consists of three bundles. The application exposes one service, the web log service, and imports one service, the User authoring service. Within the application, the web log persistence service is exported by the weblog.persistence bundle and imported by the weblog bundle, but must not be exposed outside the application. The application isolation hides the web log persistence service from outside the application.
Figure 3. Bundles and services in an example application for a weblog service
OSGi Applications support provides a modularity construct at application level to describe an isolated application, including metadata that describes the constituent bundles of an application. A deployment system can use this to determine the constituent bundles that must be provisioned and deployed when the application is installed to a target server.
An OSGi application consists of a set of bundles, in an isolation scope defined by application metadata. An OSGi application is deployed as an enterprise bundle archive (EBA) file. This file contains the constituent bundles for the application, or the metadata required to get the constituent bundles from an OSGi bundle repository, or both.
If an OSGi application provides
or requires any external services and references, these are explicitly
made available by declaring them in an application manifest. 
An external component must use SCA to access an OSGi service; for further information, see SCA and OSGi Applications.
Any external services and references that the OSGi application must satisfy are also declared in the application manifest. The application manifest describes modularity at the application level in a similar way to OSGi headers in a bundle manifest file that define modularity at the bundle level.
The following examples illustrate the flexible ways in which an OSGi application can be deployed as an EBA file, with and without application-level isolation, and optionally exploiting a shared OSGi bundle repository. Each example extends the previous one.
- The OSGi application has an application-specific copy of each
bundle on disk and in memory. Each bundle is at version 1.0.0.
- The OSGi application references one bundle from a bundle repository, requiring version 1.0.0 or later to be present in the bundle repository.
There is one less bundle on disk. However, the same number of bundles
are loaded into memory, because each bundle is isolated for each application
in memory so there is still one copy of each bundle for the application
in memory.
- The OSGi application contains all the application bundles, but a later version of one bundle is in the configured bundle repository
and is within the version range in the application manifest. The installed
application is provisioned to use the bundle from the bundle repository, rather than the bundle included in the application. An example
of typical use is using a governed bundle repository to deliver critical
fixes to shared bundles.
- A content bundle in the OSGi application uses a service provided by a bundle that is not part of the application content. Dependencies that are not inside the application are satisfied by bundles that are shared by all applications on the same server. This reduces the memory footprint for applications that do not require component instances from the dependency bundle to be isolated in the OSGi application. Equivalent sharing for Java EE and SCA is achieved by using an isolated shared library class loader with a JAR file, but this mechanism requires greater administrative overhead
Parent topic: An introduction to OSGi Applications