Simplified Enterprise OSGi in WAS 7
Join the DZone community and get the full member experience.Join For Free
When IBM's work on WAS 7 began, they wanted to deploy OSGi bundles and avoid building a new server type, so they built a model where bundled and non-bundled Java EE applications could be deployed on the same server using a common administrative model. "It gives you the ability to solve a number of problems with a familiar Java EE programming model," said Robinson. "The alpha allows you to provide additional modularity capabilities that aren't present in a pure Java EE deployment model." Before the OSGi alpha in WAS 7, there was a way exploit OSGi modularity. "But the way you would have to do that," Robinson said, "is by deploying your application and an OSGi framework in your .war file." Once you did that, he said, you could then exploit OSGi within the context of your application. This technique could be used in Tomcat or any other servlet container.
Robinson explains, "What we've done with the OSGi alpha, however, is we've enabled the application server to directly understand the applications deployed as OSGi bundles. It will even understand, based on the metadata that you provide when you deploy your application, that the application you're deploying needs some other OSGi bundles." Robinson says the application depends on these "other" bundles, but they aren't chosen by the developer to deploy as part of the OSGi application. These bundles are referenced from an OSGi bundle repository. This gives you the ability to separate out common libraries that many applications share so that you don't have to re-deploy the libraries inside the enterprise archive.
A common problem across many Java EE application servers occurs when several applications have third party libraries which may have dependancies on other third party libraries. During deployment, the applications end up with many copies of the same library. With the alpha, Robinson says, users can leverage OSGi metadata to describe the dependancies of their application so that only first-class components are deployed. "Then you can load up your enterprise bundle repository with the common libraries that are used by many of your applications and just have the applications deployed with references to those common libraries," said Robinson. "The WebSphere administrative process will take care of ensuring that all of those dependancies in the application can be resolved." He says users can even ensure that the dependencies are resolved at specific versions if they want to have multiple versions of the same common library deployed to the runtime. "You save memory footprint and disk footprint by having single copies of libraries laid down on disk and single copies loaded into memory," said Robinson. "That is a pretty big deal."
Ultimately, IBM's key goal is making OSGi very easy for people to use with existing Java EE applications and infrastructure. Robinson says IBM doesn't want people to go back to the drawing board and redesign their applications in order to use them with OSGi. They've created what Robinson calls "a natural progression" so that an existing web application can simply be deployed as one or more OSGi bundles without actually having to recode an application. Robinson says IBM wants people to test the OSGi alpha and give feedback. He mentioned that the alpha uses technologies from the the Apache Aries project, which is now in the incubation stage. The project is aimed at building a community around implementing enterprise OSGi technologies. With the Aries community, Robinson says IBM would like to build interest, build implementation, and get a broad perspective on enterprise OSGi to help make it successful. The alpha shows how you can integrate that technology in to WAS.
Opinions expressed by DZone contributors are their own.