Alexander Klimetschek's Blog On Software Design and Development

Rails fighting Java in the web application space? (or: Software Deployment - Web2.0-style Hosting vs. Enterprise Installation)

Ruby on Rails is popular for its simple way of scaffolding building web applications, especially for Web 2.0 sites (although one of the top ones is still written in that kiddie language PHP, despite the fact that it has to offer an interface for applications written by others ). Now as "Development-as-a-service" becomes a new internet business segment (see Joyent, Coghead, Amazon, Salesforce and others), there is also a service that will host your Rails-based apps called Engine Yard, that just got decent VC funding.

Is this tendency going to be the real killer for Java in its last area of defense, namely enterprise server applications? Well, I don't think so and I will tell you why.

Central application hosting, as naturally done by larger websites where software developer = business itself (eg. eBay and the whole Web 2.0 crew today), is a lot easier when compared to normal software products that have to be installed. It's because there is only a single deployment to rule them all - you don't have to manage your hundreds of customers all running on different versions of your product and maybe each of them with special bugfixes. Instead there is only one single version of your software out in production and you control the install process yourself - no errors that can be introduced by the customer. He only has to remember the URL of your site (and should not be surprised when he sees a totally different application on Monday morning after you did that great update during the weekend).

But it's a fact that there is still a lot of software that needs to be installed, because the customer wants it in-house. The market for SaaS (software as a service) solutions is growing (eg. Google Apps for your domain), but it is hard to get larger customers to run their core business processes outside the company. And as Ruby on Rails maybe great when hosted, it is less good when it has to be installed. Scripting languages generally lack support when it comes to  deployment solutions that include automated build systems, packaging, concise versioning of those packages and dependency management. With scripts you easily hack them to add just another small feature here and there or quickly fix a bug, but in the end it you have no control over your different product versions.

Java has some track-record in this space since it already has some history in the enterprise. The first step towards a controlled software product lifecycle management (this is what you want when you have those hundred customers on different versions of your product crying for the latest bugfix) was introduced by Sun itself when it allowed class files to be stored and loaded from JAR archives. It standardized the way to deploy an entire library or application. The second (and small) step was the Ant build system by somewhat standardizing Java build systems. But each ant script was different and it only simplified the process of creating a jar (or war or ear). Then came Maven, which introduced a common packaging system and versioning of those packages. It even provides central repositories for open source libraries.

But even maven is not perfect. Apart from the typical problems people have with maven (like never-leave-the-recommended-default-convention-or-you-will-cry-in-tears) it only solves the packaging problem on the developer's side, but not on the installer's side, ie. on the actual running software. This is the classical DLL-hell problem under Windows: there is no control over what code gets actually used if you have two different versions of the same library in the various lib locations. The only indicators are weird exceptions. And how do I provide an easy upgrade path when I want to install a simple bugfix? Reinstallation? On a production system where you have to start a second system for maintaining service during the downtime first? Nope, that could be better.

And this is where OSGi comes into play - in hopefully the final step, number 4. It adds just a bit of meta-information to your maven packages to create so-called bundles and (here comes the trick) provides a full runtime framework that introduces its own super-duper classloading. This offers full control over what versions of bundles are currently running on your system, it allows for deployment of new bundles and new versions during runtime with zero-downtime. It can magically give new objects the classes of the updated bundle, and older objects will keep the old ones until they are no longer needed. This works great in a request-based environment, aka in all servlet containers. If you wonder why Eclipse, one of the first larger projects to implement OSGi, does not use that feature to install plugins at runtime, without restarting the big beast, you are with me - they must have done something wrong when adopting the basic OSGi principles.

OSGi could also make the old dream of component programming come true: it has a standardized interface for making bundles provide and consume services to and from other bundles. Which also is needed as OSGi has a strict dependency management: you have to export the Java packages others can use - and these packages can be versioned. All this makes it possible that the framework can tell you whether the installation of a new bundle will satisfy all requirements or not - before it is loaded and code is run. A management console shows you all your bundles, including their versions, their exported and imported packages, their components and so on - in the actual running application, not only in a descriptive POM file that states how it should be.

And if you now think that OSGi has to be a heavy framework that makes everything slower, I can tell you that the opposite is the case: one of the target areas of the specification are embedded software platforms, so OSGi is super-lightweight and has a very, very fast startup time.

It's great that Apache Sling uses Apache Felix as OSGi framework, which in conjunction with JCR as the driver for a RESTful web application framework, also makes it a highly enterprise-ready piece of software.

Posted at 12:41AM Jan 21, 2008 by Alexander Klimetschek in JCR  |  Comments[3]