Mirko Jahn

Subscribe to Mirko Jahn: eMailAlertsEmail Alerts
Get Mirko Jahn: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: OSGi, Java Developer Magazine, Open Web Magazine

OSGi: Article

Adopting OSGi in Java Application Frameworks: A Case Study

Defining reusable software system components

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.

More Stories By Yurdaer Doganata

Dr. Doganata is the manager of the Information Management Solutions group at the Watson Research Center in Hawthorne, New York. He received B.S. and M.S. degrees from the Middle East Technical University, Ankara, Turkey, and a Ph.D. degree from the California Institute of Technology, Pasadena, California, all in electrical engineering. He joined the Watson Research Center as a research staff member in 1989 and worked on projects in many diverse areas, including high-speed switching systems, multimedia servers, intelligent transportation systems, multimedia collaborative applications, eservices, and information search and retrieval systems for technical support. His current work involves designing and prototyping innovative solutions, applications, tools, and utilities in the area of unstructured information management. Dr. Doganata hold several patents and research awards and is the author of numerous papers. http://yurdaer.doganata.us

More Stories By Lev Kozakov

Dr. Lev Kozakov is a research staff member at IBM T.J. Watson Research Center and is a member of the dBlue project architecture and research teams. He has worked in many areas, including dynamic systems, applied statistics, information management systems, man-machine interface, medical software, computer telephony, and design patterns. Lev holds a number of patents and is the author of several publications.

More Stories By Mirko Jahn

Mirko Jahn worked for several years as an independent software consultant and tutor before joining the Unstructured Information Management Architecture (UIMA) group at IBM Research. At present, his major research areas cover component-based development strategies, component repositories, and migration approaches toward modular applications, along with service-oriented architecture. Mr. Jahn is heavily involved in making use of OSGi component-based developement
standards in UIMA.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.