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. Existing web applications that consist of one or more web application archives (WARs) can be deployed as an OSGi application in which each WAR is converted to a web application bundle (WAB) as described in Conversion of an enterprise application to an OSGi application. You can develop new applications as OSGi Application projects as described in Developing and deploying 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. 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 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.
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 module 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.
OSGi services provide a convenient 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.
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, and bundles with JPA entities and persistence configuration (persistence bundles).
An OSGi application isolates the OSGi services that are offered to modules that are 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).
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.
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 that is 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 produces any external services and references, these are explicitly made available by declaring them in an application manifest. An external component must use Service Component Architecture (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.