Most web based systems are architected with three pieces: (a) a user-agent, (b) a web server for processing, and (c) a database for storage. Of these three, the user-agent is typically considered as a presentation node, with almost all the computing performed on the web server node. In this model, each node has some special characteristics:

• The user-agent is a mutli-threaded and dedicated node with reasonable computing power entirely under the control of the user
• The web server is a multi-threaded or multi-process node that is shared across several users
• The storage node is also a multi-threaded or multi-process node that is also shared across several users (via the web server)

In hosted environments, nodes (b) and (c) are expensive. For instance, while a typical shared hosting of an application costs under $100 per year, dedicated servers cost over $200 per month per node. Hosting an application on shared hosting systems therefore introduces some scalability problems that can not be solved cheaply. I was faced with this problem recently, and I had to make some choices to scale the application without requiring additional computing power on the server side.

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.