In the hopes of driving the adoption of OSGi-based development patterns in enterprise Java shops, SpringSource on Tuesday submitted its dm Server for acceptance as an Eclipse Foundation project.

Adam Fitzgerald, director of developer relations at SpringSource (which is owned by VMware), said that SpringSource has seen little uptake in OSGi usage from its enterprise customers. “What we’ve seen, and this is confirmed by others, is that while OSGi has had tremendous success in other areas like the IDE, and in places like embeddable devices, we haven’t seen the broad and widespread adoption of OSGi as a solution in enterprise Java,” he said. “There are certainly early adopters, but there is not as much penetration into the mainstream enterprise Java development world as we’d like.

“We think part of the reason might be the additional complexity that comes with building OSGi solutions. We need more common projects that are easily accessible to community members. We are moving dm Server over to Eclipse in the hopes that we can foster more use of OSGi.”

In essence, OSGi shoehorns a module component model into Java by describing an entire application life-cycle framework. The JCP is working on its own modular Java, but the OSGi Alliance and the Eclipse Foundation have already expanded the OSGi universe to include many tools, platforms and APIs. The benefits of OSGi, claim its proponents, are exemplary of service-oriented architecture and of the future of Java itself.

Building with OSGi, which has outlived the meaning of its original acronym (Open Services Gateway Initiative), allows JAR files to be packaged along with metadata that describe the application. OSGi bundles (the deployable artifacts) describe public and private spaces in code, allowing for greater control over access and usage.

OSGi’s modular nature also allows developers to deploy updates to underlying libraries and applications without requiring a restart of the host JVM. With OSGi, life cycles include deployment to live machines without any interruptions.

SpringSource and Sun both support OSGi in their application servers; Sun’s GlassFish contains OSGi support. Fitzgerald said neither dm Server nor any OSGi-based application server can provide the benefits of OSGi-based architecture without properly prepared code.

Problems with overhead
Jason van Zyl, creator of Maven and founder of Sonatype, said that the biggest problem for OSGi uptake is that the tools for building and handling OSGi bundles are still formative and difficult to deploy.

“There is a lot of overhead in managing the bundles,” he said. “In OSGi you have a programming model, and that’s somewhat difficult to use. This is what SpringSource is trying to encourage with dm Server.

“On the tooling side, it’s a disaster. If you went to an enterprise team and asked how they would take advantage of OSGi, it’s a nightmare. You would have to have OSGi bundles for everything. An OSGi bundle is just a JAR file with metadata that describes what’s private and what’s public.

“If this OSGi manifest is not there, nothing works. You can’t find dependencies; it won’t work in an IDE. If you have 10 dependencies and you have to turn those into bundles first, it becomes a real overhead.”

Complicating matters are the two competing standards for OSGi repositories. The OBR and p2 standards conflict in their requirements, so van Zyl said his company is supporting both.

Sonatype has another answer to the bundle problem: hosting more bundle repositories. Sonatype already hosts Maven repositories, which give developers a one-stop shop for resolving their dependencies. van Zyl said that the next step is creating this type of infrastructure for OSGi bundles.

He added that having libraries prepackaged as bundles and available in a reliable online repository may help with the uptake of OSGi in enterprises.