OSGi Discontent - No Migration Path!

OSGi has emerged as the de facto standard for modularity on the Java platform. The Eclipse RCP plug-in architecture is built on Equinox. Major application server vendors, including IBM, Oracle, and JBoss are leveraging OSGi to increase the modularity of their platforms. The ability to dynamically provision server-side modules reduces footprint and decreases start-up time. Without question, OSGi will play a major role in the next generation application platform.

In my last post where I embedded OSGi (Equinox) in Tomcat, I promised to provide a synopsis of my experiences thus far with OSGi. I’ve come to a disturbing conclusion - OSGi is not ready for the enterprise. With so much industry momentum, OSGi is not ready for enterprise web application development! The reason is because enterprise developers don’t have the tools to build OSGi based server-side applications, and vendors aren’t exposing the capabilities of OSGi to enterprise developers. Neil says that I should be able to name 10 things I don’t like about OSGi. Well here’s six things I don’t like today when using OSGi to build enterprise applications. But first, some background.

Building for the Web

Understanding the root of this problem demands we examine the two ways to build web applications using OSGi. The first is Host OSGi. The second is Embedded OSGi.

• Host OSGi - With this approach, OSGi is the host environment, and the advantages of modularity are brought to the entire application platform. For an example of this approach, see my post where I embed Jetty within Felix.
• Embedded OSGi - With this approach, OSGi is not embedded within the platform, but instead is embedded within each web application we build. For an example of this approach, see my post where I embed Equinox in Tomcat.

The differences may seem subtle, but have significant ramifications on how we develop and manage enterprise applications.

• With Host OSGi, I don’t need to embed an OSGi framework into my web application. It’s already been embedded for me by the application platform vendor. All I need to do is build atop it and take advantage of what OSGi has to offer. For instance, when embedding OSGi, I need to manage starting up and shutting down the OSGi framework. With Host OSGi, the application platform would do it for me.
• With Host OSGi, I’m no longer limited by the coarse grained WAR and EAR units of deployment. Instead, I have an option of finer grained control over how I deploy and manage enterprise applications and components.
• With Host OSGi, I’m not constrained by application boundaries that limit and prohibit class sharing between applications. The classes within a JAR file are available to the entire environment, whereas today, they are constrained based on the WAR or EAR file in which the JAR is packaged.
• With Host OSGi, the environment is adaptable, whereas with Embedded OSGi, only my application is adaptable. Vendors are leveraging OSGi to build an adaptable platform. For instance, if an EJB container isn’t needed, it’s not loaded. No longer is an EJB container loaded simply because I’m using a Java EE application server. The platform will adapt based on the needs of the application. I’d like this same level of adaptability for applications that I create.

Why is this important? Foremost, it allows us to build more modular applications. The bane of many enterprise development efforts is the lack of modularity, the excessive (and often unknown) dependencies, the ripple effect of change, and the design rot that ultimately brings the system to it’s knees. Beyond this, a platform built atop OSGi can remove the artificial application boundaries that exist today. By separating the unit of deployment from application and process boundaries, we open up amazing flexibility in how enterprise applications can adapt, shrink, grow, and morph over time.

Host OSGi is the preferred scenario, but today, SpringSource dm Server and Paremus Infiniflow are the only products I’m aware of that provides the capability. While other major application platform vendors are beginning to build OSGi into their platform, they are not exposing the capabillities to enterprise developers. Until application platform vendors expose the capabilities of OSGi to the enteprise, our only option is Embedded OSGi, which can be tricky and difficult. Unfortunately, the enterprise is left building applications on many of the traditional application servers - WAS, WebLogic, and JBoss - and this poses challenges.

The Challenge

Attempting to develop enterprise web applications today using OSGi presents significant challenges. In fact, these challenges are significant enough that they are severely impeding OSGi adoption within the enterprise. While the OSGi framework implementations themselves are capable, the surrounding ecosystem is not yet mature enough.

• Platforms not ready - Even though most application platform vendors are leveraging OSGi to modularize their platforms, they are not exposing the capabilities of OSGi to developers. Therefore, the only way to leverage OSGi is to embed it within your web application. While dm Server does provide support for Host OSGi, it’s a long way from capturing the marketshare required to be placed in the same category as the major application server vendors.  Embedding is not easy and requires developers to write a lot of infrastructure code. This is the main reason I chose Equinox instead of Felix when embedding within Tomcat - the Servlet Bridge performed two very important functions for me. It launched Equinox, and it bridged servlet requests from the container to bundles managed by OSGi that contained my servlets. Certainly I could have written this functionality myself, but I didn’t want to. And no enterprise developer should have to do this either. They should focus on business logic, not infrastructure logic.
• No Migration Path - Where are the tools that allow developers to create modular applications today such that when the platforms expose the virtues of OSGi to the enterprise developers, they’ll be able to take advantage of it? Where are the tools that allow us to build more modular applications today?
• Lack of best practices - Currently, there are few patterns that document how OSGi can be used to develop enterprise web applications. There are few practices that explain how to refactor large applications into applications with higher degrees of modularity. And because the JAR file has never been treated as the unit of modularity, tools provide no help in refactoring.
• Dearth of Frameworks - Over the past few years, enterprise Java development has made great strides in developing frameworks that allow developers to focus on writing business logic instead of infrastructure code. Developers have grown accustomed to this. Unfortunately, these frameworks don’t exist for us with OSGi today. For instance, if it weren’t for PAX WEB, I’d still be trying to figure out how to support JSP with Jetty embedded in Felix. The very fact I have to embed Jasper to compile JSP pages is a prime example of why we aren’t ready. Finding the right bundles, frameworks, and writing the glue code necessary got tricky pretty quickly. There is no enterprise application developer that has the time nor the desire to do this. Uuntil the platform or a framework provides this capability, it’s unrealistic to expect the enterprise to use OSGi.
• No Management Tools - Even if we’re able to develop more modular applications using OSGi, products do not have the capability to take advantage of modularity because most of the tooling is focused on managing the existing Java EE application modules, such as WAR and EAR files. It’s unrealistic for an enterprise development team to manage an application at the console, which makes managing OSGi applications unwieldy.
• Bundle Problem - Taking advantage of OSGi requires that JAR files are valid OSGi bundles. While I can make sure the JAR files i develop are OSGi valid, it’s not as easy to find 3rd party JAR file packaged as valid OSGi bundles. This is beginning to change, with commercial OBRs beginning to surface, such as the SpringSource Enterprise Bundle Repository, that transform many open source frameworks to valid OSGi bundles. But until framework creators package their products as OSGi bundles, the challenges will continue to linger.

OSGi was once heralded as the most important technology of the decade, and the majority of enterprise software developers can’t even use it yet. OSGi proper may be ready for primetime, but we have a long ways to go before the enterprise is able to develop web applications leveraging OSGi. The problem isn’t the OSGi specification, nor the popular Equinox and Felix implementations. Each of these are waiting and ready. Unfortunately, there is no easy way to build modular applications using OSGi and deploy them to the current generation application servers. There are no frameworks that help me do this. There are no tools that make this easy. There is no migration path that helps developers move away from building monolithic Java EE applications and move toward building the modular applications of tomorrow.

Migration Path Necessary

Ultimately, we need a migration path. As OSGi is built into the platform and exposed to enterprise developers, we need tools and patterns that allow us to build and manage more modular applications. These tools must allow us to take advantage of OSGi in building more modular applications today, and help us prepare for the platforms of tomorrow so that we are ready when they arrive.

If we are able to architect modular applications today, built using OSGi, then we are prepared for what tomorrow brings as we migrate to application platforms that Host OSGi. Just because the application platform doesn’t currently expose OSGi to enterprise developers doesn’t mean we shouldn’t be striving to create more modular applications. There is benefit to this of itself. And because OSGi bundles are backward compatible and capable of running in today’s application servers, what should prevent us from designing more modular software. Shouldn’t we be doing this today? Until there are tools available that help us do this, it’s not likely to happen. And that’s going to make leveraging the capabilities of the next generation platform more difficult, even after it’s arrived.

OSGi is an important and valuable technology that can help enterprise developers create more modular applications. The OSGi Tool Summit is being held Friday (03/27/09). Hopefully, this will result in another small step toward being able to leverage OSGi in the enterprise.

Comments