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]
Apache Jackrabbit 1.4 has been released! Congrats to the team! Jackrabbit is a fully Java Content Repository (JCR) compliant implementation, something that could replace your database (at least inside the application code) by a cool hierarchical storage with lots of features that a relational database doesn't have (note: pdf in a zip). And it's open source!
The most notable new features to me are the OCM (Java Object-to-JCR mapping), the SPI interface (a layer below the JCR API for simpler implementation of your own backend or for remoting purposes) and the new DataStore facility for improving storage of that big binary data.
More information can be found on Jukka's post (he is the release manager) and in the release notes.
Posted at 01:35PM Jan 16, 2008 by Alexander Klimetschek in JCR | Comments[0]
Using Jackrabbit SPI to implement a JCR with an Amazon SimpleDB/S3 backend?
As I am currently digging into Jackrabbit's internal architecture (and trying to create some diagrams explaining it) and talking with people about it, I came across the new Jackrabbit/JCR SPI implementation again. It is supposed to make implementing a JCR easier, as it lies in between the complex JCR API and the relatively simple (with no room for optimizations) Jackrabbit Persistence Manager interface. This is probably the best way to implement a JCR backed by Amazon SimpleDB or Amazon S3.
Understanding-more-update: The Jackrabbit SPI interface cuts Jackrabbit's (or any JCR implementation's) implementation at the border of the transient and the persistent part (also see this description in the Javadocs and the image below). The transient part is everything that is stored in memory inside a JCR session before a save() is made - after that it has to be handled to the persistent part that needs to store the nodes and properties persistently, eg. in a database. This way the persistent part is the same for a single workspace and all it's attached sessions.
Posted at 10:34AM Jan 08, 2008 by Alexander Klimetschek in JCR | Comments[0]
Write once, run everywhere 2.0
Sam Ruby: As the decade comes to a close, it is interesting to see the promise of “Write Once, Run Anywhere” move from “write in Java, run anywhere there is a JVM” to “write in Python or Ruby, run anywhere there is C, a JVM, or .Net”. While the latter VMs provide additional runtime libraries, the pressure to run high profile frameworks like Django and Rails ensure that there is a rather large set of common libraries implemented compatibly across the various implementations.
Good point, another reason why scripting languages got quite popular in the last few years. That's why Sling, the flexible RESTful web application framework, written in Java, using OSGi and based on JCR as data and script storage supports all scripting languages available through the Java Scripting Framework (and that includes Javascript, Ruby, Python, etc.).
Posted at 07:41PM Jan 04, 2008 by Alexander Klimetschek in JCR | Comments[0]
The release of Amazon's SimpleDB is another interesting step away from traditional relational databases towards data first - structure later storages, for example content repositories in various flavors. Michael Marth puts it all together and I would add Xenodot [pdf] from resting bird to the list, although it's not released yet.
One thing I miss in SimpleDB is the lack of a tree structure, ie. there is only one big set of items that are unconnected. This has the adavantage of making the implementation easily scalable as each item can be stored on a different machine and the rest is done by the search index. You could use URIs with paths as your item names to create a virtual tree structure (I don't know if long item names are feasible), but there is no way to easily explore your data and structure it with parent-child relationships explicitly.
The idea of creating a JCR-interface on top of SimpleDB is nice, but I wonder if a persistence manager for Jackrabbit would be enough. But a persistence manager could also use Amazon S3 directly.
Posted at 12:54PM Dec 21, 2007 by Alexander Klimetschek in JCR | Comments[0]
Starting new job at Day Software
Hurray, today I started my new job at Day! Actually that was last thursday, but today I went down to Basel by plane in the early morning and got the real start at Day's office. Alex Saar was with me and Lars will follow next Monday as we together will do some interesting collaboration stuff for Day, just as in our last company. It's a jump from a 10-people startup to a 100+ people publicly traded company with a 13 year history and that's quite a difference.
It was a very nice welcome and I think I already really like this company (the admins are friendly and very helpful! . There are a lot of interesting people that work here, e.g. Roy Fielding, author of the HTTP spec and the REST guy, as well as many Apache guys (Bertrand, Carsten, Jukka - just to name a few). All in all, I am really excited about my future work here!
Posted at 05:27PM Nov 06, 2007 by Alexander Klimetschek in JCR | Comments[1]