Page 1 of 5   next page »

Migration of software systems to the OSGi platform is gaining momentum with wide acceptance of the OSGi technology as the dynamic module system for Java. This transition is of special interest when it comes to popular Java application frameworks, which attract a growing number of Java developers around the world. Although the technical merits of the OSGi platform are broadly recognized, the migration of existing application frameworks is slow due to significant redesign and re-implementation efforts involved. We present an alternative lightweight approach - an adaptation of existing Java application framework for component based OSGi environment. Adaptation, as opposed to migration, eliminates the necessity of modularizing or redesigning the existing framework. This is particularly important when existing software platform and the associated programming model is mature and has already penetrated into the market place. As a general adaptation solution we introduce a thin layer between the OSGi Service Platform and the existing framework. Furthermore, we present the case study of an OSGi adaptation of a popular open source Java platform developed by IBM Research for integration of software analytics. Our results demonstrate that the adaptation approach is not limited to the presented case, but is broadly applicable to a variety of Java application frameworks.

Introduction
The software development and support costs are driven by increase in software complexity, thrust to reduce product cycles and the need to support multiple hardware and operating systems. There is an increasing emphasis on creating modular software solutions to enable reuse of software parts to reduce the cost and increase the quality of software development. In response to this need, OSGi technology is introduced as the dynamic module system for Java - a platform for component-based development of high quality and less costly software solutions. Built on top of the ubiquitous Java the OSGi technology creates a portable modularization platform embraced by many software products (see [4]).

While there is a surge of interest in OSGi technology, in particular after Eclipse adopted OSGi approach with Eclipse 3.2, the problem of migrating existing Java solutions into OSGi is not trivial. In this paper, we focus on Java application frameworks that become increasingly popular among professional application developers (see [15],[16]). In addition to services provided by traditional software libraries, application frameworks also provide structure to applications. In this sense, the problem of OSGi migration for Java application frameworks seems to be more interesting than for traditional libraries.

Typically, existing Java application frameworks do not fully support the fundamental principles of modularity (see [19]). Hence, transforming existing application frameworks into OSGi platform may not be accomplished without changing the programming model or introducing new service interfaces. Before we take on the challenging problem of adopting OSGi technologies in traditional Java application frameworks, we would like to review the fundamental characteristics of a modular system and confront them with the needs of application frameworks. This will further clarify the nature of the challenge.

In a fully modular computing environment, it is expected that "off the shelf" software components can be reused and integrated into the application coherently. Installing, updating and removing components on the fly are the essential functionality of component based systems. Components are capable of dynamically discover and cooperate with each other. More importantly, all this is done with little or no configuration. In a modular system, componentization is enforced with a proper code separation and the isolation level guaranteed by component class loaders. Needless to say that plain Java lacks these core characteristics of a modular platform (see [20]). Traditional Java application frameworks also do not fully support modularity due to their inherent characteristics, such as the utilization of the Inversion of Control (IoC) pattern (see [21]). The IoC pattern implies that the application class loader together with the framework have access to certain resources of third party components, which are used by the application. With the isolation level, established by a modular environment, even providing the IoC based framework with a legitimate access to component resources is a problem by itself.

Once we established that traditional Java application frameworks do not fully support modularity, it is important to understand what it takes to attain modularity, particularly using OSGi technology. Three different types of modularization are possible for Java application frameworks:

•  Framework only migration.
Modularizing the framework architecture/implementation without affecting applications/components (example - WebSphere Application Server [22]). This type is not discussed here, because the modular framework implementation still does not provide real component-based environment for application and component developers.
•  Full migration.
Modularizing the framework architecture/implementation together with applications/components (example - Spring Framework [23]).
•  Adaptation.
Modularizing applications/components without modifying the framework itself. This type of modularization, however, requires extending the framework with an enablement layer that allows the framework to work with modularized components/applications.

In this paper we discuss the latter 2 types of modularization in Java application frameworks. In section 3 we compare the latter 2 approaches, namely migration approach versus adaptation approach. Section 4 introduces the OSGi service adapter solution as a way to adopt OSGi modularization in traditional Java application frameworks. In section 5, UIMA framework is reviewed as an example of a traditional Java application framework to be used for this case study. Section 6 discusses the architecture of the OSGi services adapter as well as its core features. Finally, the findings of this case study are outlined in sections 7 and 8.

Overview of OSGi as Java module system
The OSGi Alliance [1] makes the following statement: "OSGi Technology is the dynamic module system for Java". Today, this technology is widely adopted by both the Java community (see [2], [3]) and the major software vendors (see, for instance, [4]). The main focus of the OSGi Technology lies in the integration of software components based on the OSGi Service Platform. Comprehensive overview of the OSGi Service Platform is given by the OSGi Alliance in [5]. In this section we briefly review several key features of the OSGi Service Platform that are most relevant in the context of this paper.

Bundles and bundle management
In OSGi Service Platform, a bundle is defined as a unit of modularization. OSGi bundles are JAR files comprised of Java classes and other resources without any specific structural constraints. Unlike other JAR files, OSGi bundles always include a manifest file, providing information about the bundle. This file consists of headers, which specify information that the OSGi Framework utilizes to handle a bundle. For example, some manifest headers are used to state dependencies on other resources that must be available before a bundle can be used. Some bundles may also contain the Activator class that is used to start and register bundle services and perform other initial interactions with the OSGi Framework.

The OSGi Framework provides a container for managing bundles and supports full set of bundle lifecycle management operations, such as installing, updating, resolving, starting, stopping and uninstalling. Each bundle can be in one of the following states:

•  installed (bundle is deployed into the container);
•  resolved (bundle dependencies are resolved within the container);
•  active (bundle Activator is called)
•  uninstalled (bundle is uninstalled from the container).

For complete description of bundle states and state transition diagrams see [5].

Modules and class loading
The modularization concept in OSGi Framework is supported by the module-based class loading policy. The OSGi Framework has a powerful and rigidly specified class loading model that allows modules to declare shared and private class space and controls linking between modules. In this model, each bundle has its own class loader, and forms a class loading delegation network with other bundles (see [5], section 3.4). A bundle class space includes imported packages, shared class space of required bundles, private bundle classes and attached fragments. Note, that in order to have a consistent bundle class space, it's not recommended to put two classes with the same fully qualified name into the same class space. Separate class spaces in the OSGi Framework, however, may contain classes with the same fully qualified name. Therefore, the OSGi Framework modularization layer supports a model where multiple versions of the same class are loaded in the same VM. This allows binding two versions of the same component within the same application.

Services and service registry
The OSGi Service Platform defines a dynamic collaborative 'find-and-bind' service model (see [5], chapter 5). A service in OSGi Platform is a normal Java object that is registered under one or more Java interfaces with the service registry. Bundles can register services, search for them, or receive notifications when their registration state changes. The service registry provides a comprehensive model to share objects between bundles.

Page 1 of 5   next page »