Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

OSGi Discontent - No Migration Path!

03.25.2009
| 11541 views |
  • submit to reddit

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.

References
Published at DZone with permission of its author, Kirk Knoernschild. (source)

Comments

Denis Robert replied on Wed, 2009/03/25 - 12:29pm

Have you heard of Spring-DM server? It doesn't sound like it. You may want to look at what's being done there before you claim so categorically that there's no migration path to OSGi...

Kevin Jordan replied on Wed, 2009/03/25 - 1:11pm in response to: Denis Robert

He did mention Spring DM in the article.  Does it make it any easier to develop a web application as an OSGi app though?  I've been looking at OSGi lately for a project I have, but it seems to me it isn't so web oriented yet as this article also points out.

Wai Ho replied on Wed, 2009/03/25 - 2:27pm

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?

NetBeans IDE?

Jilles Van Gurp replied on Wed, 2009/03/25 - 2:58pm

I strongly agree with the article. Server side OSGI is really early adopter stuff with little or no meaningful support from vendors right now. If you want to try it, you're on your own. Bridging is particularly nasty as there is virtually no documentation on how to get going or how to support it in production environments. Essentially it's just a hack to introduce OSGI into an environment that was not designed for OSGI usage.

I spent the last 1 and a half year maintaining a small project that I initially developed for a Nokia N800 tablet with CDC Java that later morphed into a server side project (i.e. I run it serverside now and stopped trying to keep it compatible with the N800).  Initially it was a good match because it provided me with a tight application server like platform to deploy my components. I quickly decided on using on equinox due to a disturbing lack of documentation for any of the other containers. Apache Felix documentation is a OSGI howto (and not even a good one), not a Apache Felix manual. Knopflerfish is sort of mature but not really intended for server development. Equinox had (one and a half year ago already) documentation for server developers. Problem: this documentation has barely been changed in 1.5 years and is (I must assume) hopelessly out of date. There's tons of blog posts outlining how great OSGI is and how to do a hello world. Beyond that, there's little worth mentioning. http://neilbartlett.name/blog/osgi-articles/ is one of the better of this type of tutorials. Nice to get started but of little help after a day or so of fooling around.

A second, more serious problem is that OSGI was designed for embedded development in a time that predates most JEE 5, spring and other frameworks as well as post JDK 1.4 language features (cough generics, annotations) that have added tons of really useful concepts, idioms, and terminology to Java. Spring injection is nice. Spring injection with annotations is really nice. Hooking up OSGI bundles with activator classes is error prone and tedious. It's really encouraging of course that the Spring people are embracing OSGI. However, a lot of work remains to be done to get rid of what constitutes a pretty big impedance mismatch. 

A third problem is the ongoing standardization battles around modularizing Java which has IBM with Equinox on one side and Sun and a big not invented here attitude on the other side. Java needs modularization and OSGI provides important parts of the solution but it needs a lot of work (see problem 2) to not be a step back. Hopefully IBM buying Sun forces some progress here.

A fourth problem is that relevant serverside standards, including the upcoming ones like JEE6 are not aligned with OSGI at all. This means that for the foreseeable future Java server side will not be OSGI centric. This means that vendors are currently inventing how these things are supposed to fit together all while remaining 100% compliant with the standards. In most cases this means right now that OSGI is just something the apps server uses that developers have no direct access to.

A fifth problem is the desktop focus with particularly equinox. Serverside support is a side project and the main focus is supporting eclipse. Most of the documentation assumes you'll be developing eclipse plugins.

A sixth problem is that OSGI implementations come with implemenation specific frameworks, practices and dependencies. I.e. once you pick one it's a lot of work to switch.

There's a lot of ongoing work on fixing all of these problems. The problem with that is that it is ongoing work with uncertain outcome. In my view, this rules it out for production usage.

Some people mentioned spring-dm. I'm sure it's nice but also that it only makes sense to use it if you are going 100% the spring way. I use Spring in a different project and have grown to like and appreciate it (despite the XML cruft here and there). In my view, it provides a lot of stuff that comes with OSGI in a better way. The one thing it doesn't provide that OSGI does is bundle isolation and deployment. Maven provides a lot of convenience in managing dependencies but it does not enforce bundle/artifact boundaries like I'm used to in a OSGI environment.

Spring style dependency injection with Guice style ease of use and OSGI style enforcing of provided/required API is what the Java world needs. I'm hopeful that Spring 3.x gets us a little closer to this but I expect it will take several years for OSGI to morph into a general purpose Java thing.

 

Christopher Brind replied on Wed, 2009/03/25 - 8:08pm

I've been using OSGi on the server for over 2 years and without Spring.

A lot of the things that the two anti-OSGi posters on this page mention can be addressed by using Google!

Here's a few links:

Declarative Services:
http://www.eclipsezone.com/eclipse/forums/t96740.html

Best Practices:
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-1419&yr=2007&track=3

An alpha management console written in Flex:
http://www.arum.co.uk/solstice.php

This is a very naive article, IMHO.

Toni Menzel replied on Thu, 2009/03/26 - 6:27am

I agree with Erics reply about this post:
http://modualrit.blogspot.com/2009/03/good-information-bad-conclusion.html

To this post:
1. yes, check before making public assumptions
2. When it comes to tooling, the author is of cause right.
But you should follow the market and see that support is increasing dramatically. See some - maybe not new - ideas coming from SpringSource - Just to name a prominent brand for enterprise people.

When it comes to tooling a maybe not yet prominent but high qualitiy (and open) OPS4J toolchain is coming from OPS4J (http://ops4j.org) which includes the mentioned

  • Pax Web but also
  • a cross platform (choose Felix,Equinix, Knopflerfish or Concierge) bootstrapper (Pax Runner), - a tool that simplifies create, build, manage and deploy many types of OSGi bundles rapidly (Pax Construct) and
  • a Test Framework that supports JUnit directly for easy testing even between different platform vendors and versions (Pax Exam) to name just a few.

Check that out - not trying to sell anything here, its just to clarify that there's _a lot_ going on !!

cheers, Toni

Eric Newcomer replied on Thu, 2009/03/26 - 11:52am

Classic "innovator's dilemma" problem - yes, the analysis of the problem is correct, and lack of good tools and lack of a good migration path are significant barriers to adoption. But this does not invalidate the value proposition of OSGi for enterprise applications, and they are not deterring early adopters.

For more check my blog entry including a comment from Kirk.

And I agree if what Kirk is saying is that he wouldn't recommend OSGi for mainstream customers yet. It is definitely in the early adopter phase, just as Java EE application servers once were. The mistake then as now was ignoring the unique value proposition of the new technology for a significant category of enterprise requirements - significant enough that early adopters are willing to invest and overcome these adoption barriers. This is a typical technology adoptoin cycle.

Besides the incorrect conclusion Kirk provides, the article also does not address the issue of technology adoption cycles and where OSGi is on that cycle. I applaud Kirk for the good technical anaylsis but unfortunately his conclusion is incorrect.

Eric

Johan Compagner replied on Fri, 2009/03/27 - 7:21am

Embedded has one other major drawback because if there is something you shouldnt do in a webapplication is introducing classloaders on top of the webapp classloader.

 Ok if you use those purely for loading services and no objects go into the session that are loaded by a osgi classloader then thats ok. But if you do that you do have a problem because session serialization (on the same server or over clusters) do have then a big problem. Because the webappclassloader doesnt know anything about the osgi classloaders so cant deserialize the objects  again..

 

 

Eric Newcomer replied on Sat, 2009/03/28 - 10:17am

It's important to remember that enterprise OSGi is a work in progress, and that the work was started because people have been using OSGi for enterprise applications and approached the OSGi Alliance to extend OSGi for enterprise requirements. This was not anything the OSGi Alliance dreamed up on its own - OSGi was designed for, and is primarly used for, embedded applications. Because people were using it for enterprise applications, a kind of grass roots movement started a couple of years ago to formalize and improve it.

We have been talking about our work on the enterprise edition of OSGi because we want to get feedback and let people know what we're doing. It is definitely going to take some time to add enterprise features and functions (and of course proper tooling) to the OSGi framework because it was never design for that in the first place.

I think Kirk's analysis, and many of the comments here, totally miss this point. We have been working on the enterprise edition because people have already been using OSGi for enterprise applications and have submitted requirements to the OSGi Alliance to standardize enterprise features and add features and functions that better support enterprise applications. And so we started the work and started the discussions to get a feedback loop going. The reason for it is that if you are not a member of the Alliance you can't participate in the work. The Alliance was founded in 1999 and its IP policies date from that time, really before the open source "transparency" model became more or less normal and expected. We are doing what we can to open the discussion and have published three early release drafts now.

But it's also important to remember that the enterprise edition of OSGi has not been finalized and officially released. I know everyone is excited about it, and those working with OSGi in the enterprise can't wait for it ;-) but let's at least all be clear where we are in this process, why it was started in the first place, and what is being done to address these issues.

Eric

Eric Newcomer replied on Sun, 2009/03/29 - 3:04pm in response to: Johan Compagner

@Johan Agreed - this is why we are working to define a native mapping of web applications onto an OSGi framework. This is part of the current enterprise expert group activity.

Wolfgang Gehner replied on Mon, 2009/03/30 - 3:03pm

This article published just after suggests a migration path for existing web applications to OSGi. The code example comes with an Eclipse plug-in that facilitates the development of web-enabled OSGi bundles that integrate with a classic WAR project running in a web container.
(http://java.dzone.com/articles/modularizing-existing-web)

Wolfgang

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.