OSGi adaptation vs. OSGi migration
In this section we compare and contrast two different practical ways of transforming a traditional Java application framework into OSGi enabled platform, namely OSGi adaptation as oppose to OSGi migration. Both approaches require that the framework code, as well as the applications, the 3rd party code and resources are encapsulated in OSGi bundles. Besides this similarity, the 2 approaches have significant differences detailed below.

A pure OSGi migration approach can be characterized by the following features:
•  The framework architecture is transformed into OSGi service based architecture. The framework API is transformed into a set of service interfaces.
•  The 3rd party classes and resources are transformed into OSGi service components, implementing service interfaces required by the application framework. All operations required to deploy and run components are done inside the component bundle class space.
•  Integration of user components is done at the service level

While the OSGi migration approach can theoretically bring substantial benefits and help to overcome certain original framework limitations, in practice, this approach requires partial or complete re-design and re-implementation of the application framework architecture and API. It also implies changes in the application programming model and the front-end code of user components.

OSGi adaptation approach, in contrast to migration, does not require any modifications in the framework design or implementation. It also does not require any modifications in the 3rd party code. The main feature of the OSGi adaptation approach is the adaptation layer that allows the framework to integrate and run the 3rd party classes and resources, encapsulated in OSGi bundles, without modifying the application framework code or changing the application programming model. We call this adaptation layer the OSGi Service Adaptor. Besides common benefits of OSGi enablement, the adaptation approach also simplifies transition to module based environment both for the application framework developers and for the community of component and application developers.

Designing OSGi Service Adaptor
OSGi Service Adaptor represents the adaptation layer that allows existing Java application framework to integrate and run the 3rd party classes and other resources encapsulated in OSGi bundles and deployed in OSGi container. In this section we discuss the main conceptual aspects of designing and developing such an adaptation layer.
To achieve better understanding of the adaptation layer design goals, we, first, consider the general architecture of a plain Java application, which is built on top of a typical Java application framework (see Figure 1). The application framework not only provides applications with useful services, like traditional libraries do, but also imposes certain structural conditions, such as the recommended programming model (see [15], [16]). Applications integrate and run third party classes and resources thru the framework API. The application framework instantiates or deploys the third party classes and resources based on certain configuration settings or explicit descriptors. The access to the third party resources is guaranteed by appropriate environment settings, such as the JVM class path.

Figure 1. General architecture of Java applications, built on top of Java application framework

In the OSGi module system, both the application framework and the applications themselves are encapsulated in OSGi bundles and deployed in the OSGi container (see Figure 2). The third party items are packaged as OSGi components (bundles) with certain dependencies among them. In such a system, the applications and the framework do not have access to the third party resources thru the JVM class path, because every bundle has its own class loader, assigned by the OSGi Framework. There is a need in the adaptation layer that provides applications with the access to the third party resources encapsulated in OSGi bundles, and allows working with the resources by using the application framework API.

Based on this discussion, we can now formulate the main design goal of the OSGi Service Adaptor: enable Java applications to use existing Java application framework with third party classes and resources encapsulated in OSGi modules - bundles. In addition to this we can formulate the following conceptual design goals:
•  Providing applications with dynamic capabilities, like dynamically adding third party components. This may include extending OSGi dependency model by adding dynamic dependency management.
•  Providing applications with OSGi transparent (or nearly-transparent) API to minimize the modularization efforts for both application and component developers

Figure 2. Architecture of Java applications with OSGi Service Adaptor in OSGi container

In accordance with the formulated design goals, we can list the following conceptual mechanisms that need to be incorporated in the OSGi Service Adaptor to realize the goals:
•  The mechanism that opens the class space of the third party component bundles to both the application framework and the applications.
•  The mechanism that enables discovery of the third party components in the OSGi container.
•  The mechanism that enables dynamic resource management, including dynamic dependency management.