My Stuff

2010 Conferences

OSGi DevCon @ JAX London

February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox

EclipseCon

March 22 - 25 - Tutorial on Modular Architecture

Über Conf

June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture

Catalyst

July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.

Tweets @ Twitter

re: #apple event "We sold more iPads than any PC manufacturer sold of their entire PC line." 2012-09-12

re: #Apple Event ""Our notebooks now rank #1 in the US in Market share in the last three months." 2012-09-12

Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29

The #osgi alliance response (http://t.co/KrN8XNWg) to the @mreinhold #jigsaw announcement (http://t.co/9YvcDdqC). 2012-08-29

Good Q&A with @mreinhold on project #jigsaw. http://t.co/9YvcDdqC. Modularity will change the way we design and run apps! 2012-08-28

LinkedIn Profile

The opinions expressed on this site are my own, and not necessarily those of my employer.

OSGi Discontent - No Migration Path!

Filed Under Architecture & Design, Development, Java, OSGi |  

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

12 Responses to “OSGi Discontent - No Migration Path!”

  1. Rob Walker on March 26th, 2009 6:02 am

    You arguments seem very narrowly focused around whether a specific app framework, such as Spring, has OSGi support - and from the deficits in this, you draw the conclusion that OSGi is not ready for enterprise app development.

    I wouldn’t argue with the former - or that there is plenty to work improving the latter. But that does not make a valid conclusion that enterprise apps can’t be reliably and quickly built on OSGi. Not having all the tools available is not the same as “not being ready”, at least in my experience.

    We are one of I suspect hundreds of commercial product developers who build enterprise applications on OSGi. In our case Felix, and formerly it’s predecessor Oscar. We’ve been doing so successfully for nearly 10 years now too - so claiming it is not ready is bogus. Sure, we sometimes have to roll our own code or build are own tools, but we’re developers. That’s what we do. We don’t buy into the current trend that seems to believe if you can’t just assemble some pre-built blocks, then you can’t develop anything.

  2. kirk on March 26th, 2009 1:29 pm

    Rob,

    thanx for your feedback. I didn’t intend to come across as narrowly focused. In fact, I thought I was pretty broadly focused and made it clear I was talking about OSGi for enterprise web development. That’s a pretty big market.

    I was also pretty clear that I felt OSGi proper (Equinox & Felix) is ready for primetime, but the surrounding ecosystem makes it incredibly difficult to build enterprise applications because of lack of development tooling, application management tooling, and product support (WAS, JBoss, WebLogic, etc.).

    Most organizations have a legacy of Java web apps deployed on WAS, JBoss, WebLogic, Tomcat, etc. While many vendors are leveraging OSGi in their products, they are not exposing the capabilities to the enterprise developer.

    The enterprise needs the tools that makes building applications with OSGi easier. They don’t have time to build infrastructure code. They don’t have the time to embed Jasper so they can deploy JSP. That’s why they use products and frameworks. It’s not because they don’t know how to develop software, it’s because they expect the platform to help them out.

    Until these tools exist or vendors decide to expose the capabilities of OSGi to the enterprise developer, it’s unrealistic for the majority of enterprise applications to leverage OSGi. I’d prefer to see this change sooner rather than later.

  3. OSGi Discontent - Part 2 : Software & Technology @kirkk.com on March 26th, 2009 8:09 pm

    [...] For the first part of the story, see my blog post titled OSGi Discontent - No Migration Path. [...]

  4. Kas Thomas on March 27th, 2009 12:43 pm

    I’m happy to find a kindrid soul on this. I agree 110% with everything you’re saying (and I never agree 110% with anybody on anything). ;^)

    “… (Equinox & Felix) is ready for primetime, but the surrounding ecosystem makes it incredibly difficult to build enterprise applications because of lack of development tooling, application management tooling, and product support (WAS, JBoss, WebLogic, etc.).”

    Lack of sufficient tooling to make OSGi more transparent to developers is a big issue, I agree. This should create a market opportunity tooling vendors, but no one seems to be rushing in to fill the void in any meaningful (disruptive) way, AFAIK.

    A pity.

  5. Software Rot - Manage those Dependencies : Software & Technology @kirkk.com on April 6th, 2009 3:46 pm

    [...] also provide ways to help manage dependencies. And of course, looming on the horizon is OSGi, which may not be ready for widespread enterprise use today, but hopefully will be [...]

  6. OSGi Survey Results : Software & Technology @kirkk.com on October 22nd, 2009 2:51 pm

    [...] Tooling, a migration path, and educational material surrounding how to use OSGi most effectively continues to be a significant issue for developers, even though roughly 15% more of this year’s respondents claimed familiarity [...]

  7. Question on Module Design : Software & Technology @kirkk.com on October 30th, 2009 7:56 pm

    [...] sexy enough? I suppose that’s just a bit more fodder for the argument that there is no migration path for modularity, and that we need better tools, tutorials, and educational materials to help us design modular [...]

  8. A New Year’s Declaration : Software & Technology @kirkk.com on January 5th, 2010 7:15 pm

    [...] there has been a nagging problem…an elephant in the room you might say…that’s hindered widespread adoption. Without gluing together a platform, assembling it yourself, or adopting an entirely new platform, [...]

  9. OSGi - Feast or Famine? : Software & Technology @kirkk.com on April 12th, 2010 4:49 pm

    [...] drive adoption. Another obstacle is tooling, which I discussed a while back when lamenting that one of the biggest barriers to adoption is no migration path. With better tools, we’re beginning to overcome that [...]

  10. Computer Science Degree Online Quickly on June 1st, 2011 9:37 pm

    Computer Science Degree Online Quickly
    I think so. I think your article will give those people a good reminding. And they will express

  11. ojmiaomake on December 1st, 2012 9:57 am

    Dior Show Black Out of is such a good product for a more dramatic look. ,Karen Millen sale

  12. running magazine on February 11th, 2014 11:33 pm

    running magazine…

    OSGi Discontent - No Migration Path! : Software & Technology @kirkk.com…

Leave a Reply