On 6th February 2008, Mark Newton caught up with Ales Justin - Core Developer for JBoss Microcontainer, JBoss AS 5, and Seam integration specialist. Member of the 'JSR-291 Dynamic Component Support for Java SE' and 'OSGi' expert groups. Here's what he had to say.

The Interview

Mark JBoss R&D have been working on a new OSGi implementation for a while now. What is the purpose of this effort?

Ales Our first goal is to have an OSGi based classloader. This will first be done for our runtime (services) and later on, along with OSGi Enterprise Expert Group (EEG) effort, we'll try to introduce the same for application developers. As a secondary goal we are aiming to create a full OSGi core spec v4.1 implementation. This effort is made a lot easier thanks to the fact that JBoss Microcontainer (MC) already has all of the OSGi core features. As an extra we'll be also throwing in the new OSGi EEG 'Component model' support. Finally since JBoss AS 5 already has a notion of profiles, we'll integrate the use of the OSGi Bundle Repository (OBR) with our ProfileService.

Mark Why not use an existing OSGi implementation?

Ales The current OSGi service registry lacks the features we need - fine grained dependency, AOP integration, legacy JMX support, scoped metadata, open mbeans, Virtual File System (VFS), generic deployers, etc... If we were to take an existing implementation and add these features then it would probably take the same amount of effort, if not more, to put everything together. Also by building our own implementation we ensure that we have the most control over the core piece of our application server, i.e. the kernel.

We could probably use the classloading features of existing OSGi frameworks but it would again mean bending around things to make them work. As we wanted to have a bullet proof implementation, where all the nasty details were hidden away under private/protected modifiers, it was important that we could tightly control access through policies and delegation. From this perspective it made more sense to implement our own classloading layer. It also meant that things like resource lookups could be implemented using our Virtual File System which gives us really nice access to deployments regardless of their location or structure (packaged or unpackaged).

Mark How do our OSGi efforts relate to the recent announcement from Spring about Dynamic Dependency Modules?

Ales What Spring is doing is similar to what already exists in OSGi where it's called Declarative Services Support (DSS). It basically concerns the way you configure your services via XML. They were able to see (with the help of the OSGi alliance people) some of the holes that are present in DSS and were able to fix them, introducing a better component model. More importantly they are finally trying to get something put back underneath the specification.

Relatively speaking this is one of the simpler aspects of OSGi. Spring just provides a simpler way to use the existing complex features of OSGi. Our effort is significantly different as we are implementing all of those complex features from scratch and also providing similar support for components.

Mark Does Seam currently provide OSGi support?

Ales No, but OSGi support for the features of Seam (EJBs, JSPs, JSFs) is currently being worked on by the OSGi EEG. As this continues to develop we should start to see Seam begin to implement that support. For the moment we could perhaps provide similar fine-grained package version support for their POJO components using some MC + Seam hooks. This is actually similar to how they currently perform hot deployment.

Mark What will application developers get from using the OSGi capabilities of JBoss AS 5?

Ales Classic JEE application developers currently won't see any benefits, since the OSGi functionality is currently all at the runtime services level. They will have to wait for the first results of the OSGi EEG work before they can begin to use it in JEE. In this respect we aim to be ahead of competition since we can freely alter our own OSGi implementation to provide EE features as soon as possible.

For service developers (people who create .sar archives) OSGi support will be provided out-of-the-box. Specially any users/developers of JBoss ESB are going to be thrilled to get this going.

Mark How do providers of custom runtimes based on JBoss AS 5 benefit from OSGi?

Ales I think their biggest benefit is going to be the new classloader layer. It's often a problem that you want to update some of your services but you run into class compatibility issues. With the new OSGi based classloading functionality these problems will go away.

What's also good is the strictness of visibility rules. This means that you can now control the exposure of your implementation details when you bundle your services, thereby removing the ability for users or developers to hack the code.

Mark How does OSGi relate to JEE?

Ales Well OSGi and JEE are two different specifications addressing different but overlapping concerns. At the end of 2006 a new OSGi expert group was formed to address how they can be integrated to get the best of both worlds. As you might expect there are certain limitations since the current versions of both specifications OSGi 4.1 and JEE 5, are already finished. However it's my hope that since representatives from all major EE vendors are onboard we're going to see better integration in the following releases.

Mark How is JBoss contributing to this effort?

Ales Together with myself In the expert group are Mark Little and Kevin Conner, both from the JBoss ESB camp. My interest is in the component model and the features that resemble our MC work. Mark's and Kevin's interests are mostly services related, e.g. SCA and discovery. As we're new to OSGi and our features are still a work-in-progress we haven't contributed anything specific yet. But we're following an on-going process with RFCs/RFPs and have an architecture in place for helping with the initial implementations.

Mark What excites you most about the future of application server development?

Ales Speaking as a user I like the idea of profiles the most. Meaning you can start with really a small runtime consisting just of your bootstrap. As you then begin to deploy services or applications the kernel tries to resolve all the dependencies you have by pulling them out of your local or public repository. Ultimately this means that you don't have to worry about classloading hell, you're just focused on the development of features.

As an application server developer I like what's happening with OpenJDK and our effort to contribute. This means we'll finally be able to fix some of the things that prevent us from doing real zero-turnaround redeployment.

Mark What about JBoss, OSGi and community?

Ales As you can see most of our OSGi implementation takes place in the MC project except for the OBR which has found a more suitable home in JBoss AS 5 next to the ProfileService. MC is an exciting project, as you know yourself from contributing to the docs and examples. I'd therefore like to encourage everybody to have a look at it and see if they feel comfortable contributing. With its modular implementation and strict separation of concerns MC has a lot of space to expand with OSGi just being one of them. The classloading is mostly in place for 2.0.0 but other features are still being finished.

If you're interested in helping out with the OSGi work then we have a specific JIRA space and user/dev forums where most of the action takes place.

Mark That's great, thanks for your time.

Ales You're welcome.