OSGi Application support in WAS is complementary to the Java EE programming model and aims to enable the use of familiar Java EE technologies - for building web UI components, accessing resources, using container managed transactions and security - as well as familar WebSphere adminstrative tasks for application deployment and management. OSGi Applications are assembed from a collection of modules and optional metadata into an archive and deployed to WAS in a similar manner to Java EE applications. There are several differences to standard Java EE assembly and deployment though. First of all, while the ".eba" archive (enterprise bundle archive) may contain all the application's modules and dependencies within it, as a Java EE EAR typically does, it may also refer (through application-metadata) to some or all of the application content as explicit dependencies and omit those from the archive. Of course, these have to be provisioned from somewhere, which is where the WAS configured OSGi bundle repository comes in. Application modules and common libraries that need to be shared between applications can be installed (through WAS admin) into one of the configured OSGi bundle repositories and these repositories are used by WAS admin during application deployment to ensure that all an application's dependencies are resolved. For example, one of the Alpha samples uses a JSON library that can be installed into the integrated WAS bundle repository and shared between the sample application and other applications - the WAS Admin view on the bundle repository is shown below:
WAS can be configured to use existing repositories instead of or as well as the integrated internal repository. At the application level, it is not necessary in the application metadata to describe a transitively closed set of dependencies - WAS works this out during deployment and produces deployment metadata that describes precisely which modules the application consists of. If deployment metadata already exists then it can be used during application deployment - this is useful if an application has been tested in a QA deployment and is ready to be rolled out to a production system - you now want the application you tested to be deployed rather than a newly resolved version of it.
If you have many applications using common libraries then having a single copy of those modules shared between applications is better then deploying a copy of the common library in each EAR. Having the dependencies resolved at deployment time ensures that applications cannot be started unless all their dependencies are present, eliminating hard-to-debug ClassNotFoundExceptions that can occur in more loosely-managed shared-library installations. Since OSGi modules are versioned, different applications can easily move to new versions of a common library at their own pace, independent of other applications. And horrible second-order dependency clashes are avoided by module-versioning so that if an application has two libraries, A and B, which need both a third library C - but at different versions - then the application will deploy successfully with both versions of C.
Once the application is installed, it is ready to be started just like any other WebSphere applications. Starting the application is what causes the bundles to be "installed" in the application-level OSGi framework (and started). This is "install" in the OSGi lifecycle sense - the applications have already been installed in the WebSphere sense to the target WAS servers.
An installed OSGi application can be managed at the bundle level - if later versions of bundles are added to the configured OSGi bundle repository after the application has been installed these will not affect the applicaiton but will be available in the WAS Admin console if the application is to be updated to such later levels.
By way of illustration, the WAS Alpha sample mentioned above delivers 3 bundles, one of which is a web application which has a dependency on a common JSON library. From a management perspective, the application consistents of the set of four libraries, one of which is denoted as being shared. If a later version of the JSON library were to be be deployed to the configured bundle repository then it would show up in the drop-down list of available versions in the view shown below. Selecting that version would cause a re-resolve of the application which, if successful, would offer the administrator the opportunity to save the configuration and update the application.
I've mentioned web applications a few times. The migration step to convert an existing Java EE enterprise web application, consisting of one of more web archives (WARs), into an OSGi application involves renaming the archive from .ear to .eba prior to deploying to WAS. For most web apps its as simple as that. WAS introspects any WARs within a .eba archive and generates the OSGi metadata required to convert this to a web application bundle.
One final note - one of the innovative technologies included in the WAS V7 OSGi Application Alpha is an integrated OSGi Blueprint container. This is a dependency injection container whose heritage is derived from the Spring framework; it enables business logic to be built from simple POJO components whose lifecycle and dependencies - including references to other components and to resources such as JDBC and JMS providers - are described in an XML "blueprint" and managed by the Blueprint container.This and other features of the WebSphere OSGi Application support are being developed as open source components of the Apache Aries project and integrated into WAS.
Thats all for now - do take a look at the Alpha and let us know what you think.
