subbu.org

No, this is not about Rails vs Java/JEE. There have been a number of Rails vs Java/JEE debates over the past couple of years, and I realize there is not much left to be debated. Most of us have settled into one camp or the other. I will also leave it to others to debate whether Ruby on Rails is just serving a niche area, or whether it has become or will become mainstream for enterprise developers. This post is about a few of features that I wish JEE borrows from the Rails framework to make matters easy for enterprise developers.

One of the biggest problems that enterprise applications deal with is the number of moving parts. It is not entirely JEE’s fault that there are too many moving parts within and across applications that need to be configured and tuned. Not every enterprise is a typical two-tier web app, and there are other occasional components like message queues, web services, background jobs and so on. By preferring convention over configuration, JEE could have simplified the number of configurations that need to be set in various deployment descriptors. But configuration can’t completely be eliminated. In retrospect, I think JEE erred in two ways.

First of all, it underestimated the efforts needed to keep the moving parts in sync across environments. It offers no set procedures or guidelines about how to manage deployment descriptors. Tuning or configuring a JEE app means changing descriptors here and there, and there is no easy way to replicate those changes across environments. It is true that app servers like WebLogic Server have been trying to solve this problem, but I don’t think the solutions are mainstream yet. To make matters worse, JEE encourages ear/war format for moving applications from environment to environment. It theory it looks nice since there is just one file that deployers have to deal with. Since archive files are supposed to be self-contained, it should be trivial to move apps from development to staging, and staging to production. But JEE forgot about two things - databases, and hot deployment. Along with the app, changes made to the database also need to be propagated across environments. Secondly, sometimes, you just want to update an existing app without rolling out a new ear or war file. But if you are using war or ear files for deployment, you need to crack them open to make changes to deployment descriptors or code. This process is not trivial on production systems. Needing to make such changes is a reality, and using war or war files for deployment created new complications for app servers to solve.

How did the Rails world solve these problems? Migrations and tools like Capistrano. The other night, I spent a less than hour to setup Capistrano to move a Rails app I am writing from my machine to a hosting server. Subsequent propagations now take just one command run from my box, and that takes care of code and database changes straight from a version control system (Subversion) to a production environment. Of course, my app is much smaller in size than a typical enterprise app, and it does not have too many moving parts. But the point I am trying to make is that there are some things to be learned from Rails as far as application propagation is concerned.