WebSphere: up to its EARs in OSGi

WebSphere Appplication Server has been up to its neck in OSGi for ages, running as a collection of OSGi bundles on an Equinox framework since WAS 6.1 was released in 2006; now, with the WAS V7 OSGi Application Alpha, its up to its EARs as well enabling enterprise web applications to be optionally developed, assembled, deployed and managed as a collection of versioned OSGi bundles. The Alpha is an early program to showcase and get feedback on WAS enablement of OSGi exploitation by applications. 

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.

OSGi 4.2 Published

My previous post mentioned early drafts of the OSGi 4.2 specifications which define part of the enterprise OSGi programming model that the new Apache Aries project is implementing. Since then the OSGi Service Platform V4.2 have been finalized and published by the OSGi Alliance. The platform is defined in two specifications - the "core" and "compendium" specifications. The latter includes the new Blueprint container specification mentioned in the previous post, an important part of the enterprise OSGi programming model we're implementing in Aries.

OSGi in the Enterprise – the Apache Aries incubator

There have been an increasing numbers of discussions recently - these two on TheServerSide are pretty representative - over the role of OSGi technology in enterprise Java applications. On the one hand it can be an asset in enabling a more modular approach to building enterprise applications: not only is a significant amount of enterprise Java middleware built on OSGi for this reason but so are some significant applications such as LinkedIn and the Jazz Team Server. On the other hand is the question of just how OSGi features in the programming model for enterprise applications. What is the web component model? The persistence model? How does the vast landscape of existing Java EE components begin to take some advantage from OSGi?

These are the questions the OSGi Alliance Enterprise Expert Group (EEG) are addressing through a set of specifications related to how existing, familiar Java EE technologies are exploited in an OSGi environment. For example, the EEG's Web Application specification (RFC 66) describes how an OSGi web container manages the lifecycle of application components written to the Servlet and JSP specifications and how existing WAR files are transformed to a web application bundle whose web components are then managed by that container. Other EEG specifications follow a similar pattern, describing how JPA, JTA, JNDI and other technologies in common use in Java EE applications should be catered for in an OSGi environment. And the Spring framework is relevant here too as the inspiration for the OSGi Blueprint container specification. This defines a standard dependency injection container including the application configuration XML (the application "blueprint") used by the container to manage, wire and configure simple Java components and optionally publish/consume these as services in the OSGi service registry. A public draft roll-up of these specifications was published earlier this year by the OSGi Alliance, ahead of finalization.

The broad adoption of OSGi as part of the enterprise Java application programming model depends not only on the EEG specifications - to encourage consistency of behaviour across enterprise OSGi platforms, to ensure application portability and avoid vendor lock-in - but also on their widespread implementation. This is the primary motivation of the Aries incubator, which aims to deliver implementation of the EEG specifications that are part of the enterprise OSGi programming model. Aries sets out to provide enterprise OSGi componentry that can be integrated into application or integration server runtimes - such as Geronimo and ServiceMix - without being tied to any one of these. Some of the work - for example the Blueprint container implementation - actually started inside Geronimo but, as it evolved, it seemed better to move it into a new incubator to help develop a community with a focus on enterprise OSGi that was independent of any specific target runtime.

Want to help develop Aries? Have a look at the proposal and discussion and get involved.