There are concerns, however, over RoR’s ability to scale. Last year, Alex Payne, developer at Twitter, was asked “How has Ruby on Rails been holding up to the increased load?”. One of the things Alex said was “All the convenience methods and syntactical sugar that
makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise”. In other words, “magic” = “slow”.

But these are issues that can be solved with conventional measures. David Heinemeier of loudthinking.com points out:

I’ve said it before, but it bears repeating: There’s nothing interesting about how Ruby on Rails scales. We’ve gone the easy route and merely followed what makes Yahoo!, LiveJournal, and other high-profile LAMP stacks scale high and mighty. Take state out of the application servers and push it to database/memcached/shared network drive (that’s the whole Shared Nothing thang). Use load balancers between your tiers, so you have load balancers -> web servers -> load balancers -> app servers -> load balancers -> database/memcached/shared network drive servers. (Past the entry point, load balancers can just be software, like haproxy). In a setup like that, you can add almost any number of web and app servers without changing a thing.

Ruby on Rails faces the same scalability issues as other frameworks. The solution to the problem, then, becomes relatively standard. Share session information, load balance web servers, load balance application servers.

And let’s face it, enterprise applications will never need to contend with as many users as a web site like Twitter does. The largest organizations have hundreds of thousands of people. Not millions (and viral web sites need to scale to millions).

Given the speed of development and agility of the framework, I Ruby on Rails apps will increasingly disseminate across next generation enterprises – enterprises looking to implement Enterprise 2.0.

I decided to build a Ruby on Rails-based enterprise search application leveraging the Google Search Appliance (GSA) REST API. My aim was to show that A) Ruby on Rails is an agile framework leading to quick application development and B) the extensibility of the Search API (being that it can be leveraged from virtually any programming framework).

Here’s what I did:

I created controller class called Search Controller that manages the API invocation. This is done in an action handler method called on_search. This method invokes the GSA API, then converts the XML response into a REXML::Document object (part of the Ruby on Rails library.

url_escape is a nifty little method I found here that converts a search term like, say “technology integration” into “technology%20integration”. If you don’t do this things will break. params[:query] contains the search term the user enters into the search box on my search.rhtml page. Last the @search_results object is stored in the session and is a container for a collection of search results plus some global information about the search (like result_count and search_time). This object is bound back to my search.rhtml page to display the search results.
Next, I had to pull relevant information out of the XML response and add it to user-friendly objects that are then used to display the results on the view:

This method leverages ‘rexml/document’ to parse XML, i.e. search_response.elements["GSP/RES/M"].text. “GSP” is the root node in the GSA XML API response document, and in this example I’m pulling out the result count, appropriately called “M”, inside the “RES” element under the document root. Parsing continues where I iterate through each search result, pull out the relevant information (snippet, url, title), add it to a SearchResult object, then add said object to the results collection in the SearchResults object (which, again, is stored in the session).

That’s it. In two quick and easy methods I can invoke the GSA XML API and parse its response into usable objects that I bind to my view. There is a lot that I’m not doing (i.e. good error handling), but I’ve at least proven what I wanted to. I’ve done this before in Java, and it took me less time to do it in Ruby even though I was learning the framework as I went.

I love Ruby on Rails.

Anyway, I found the recent post at rc3.org about RubyonRails being slow very interesting. I posted a few months ago about Java’s ability to scale with the long tail and recently received some well put comments indicating that the speed of Java is just fine, and that speed issues are generally caused by bad architecture. I argued that the popularity of PHP and Rails over Java in the Web 2.0 space seemed to show that those languages/platforms were perceived to scale well with the long tail (whereas Java seems to be king inside the Enterprise, which tends to have a much lower user base).  It seems that, at least with Ruby on Rails, the perception was based more on hype than fact.
Twitter’s recent popularity has been a good Stress and Volume Testing ground for Rails, which is a relatively new platform, and it seems that Rails is much slower than Java, PHP or Python platforms. This idea is raised at rc3.org, where Rafe Colburn writes:

I do wonder, though, if this kind of information [Twitter's statement that Rails is slow] is going to push some startups over to PHP or Java, even if they’d prefer the development efficiencies offered by Rails.

I’m pulling for Java.

Within about an hour my RSS aggregator was buzzing with updates. My team started posting messages (blogging), comments and content through the Writeboard (kind of like a wiki).

“Is this Enterprise 2.0?”, I asked myself.

Not quite, but close.

Basecamp is perhaps more structured than I’d expect an Enterprise 2.0 solution to be as it’s centered around project management (the notion of “Milestone” and “TODO” seems to me to be project oriented). But the collaboration and capture of tacit knowledge elements are certainly there, and the signals, boy do I love the signals. Maybe we can call this “Project 2.0″.

Anyway, I think the folks at 37 Signals have done a great job and I’m eager to try out their other products.

The issue is scalability.

I’ve spent the better part of my career with my head down, headphones on, techno music thumping, banging out J2EE-based (and some .NET) EAI solutions for large enterprises. These applications, at best, were scoped to target a user base of 10,000, and we never expected to have more than a couple hundred concurrent web-based user sessions.

Contrast that to google.com which deals with a couple million concurrent user sessions. And I know google.com is not JEE-based. It’s likely built with a light-weight scripting language (probably Pearl or Python give my experience with Google and their enterprise applications) with a lot of load-balanced servers behind it.

I haven’t done any official research, but in my experience most of the web 2.0 sites I’ve come across have not been JEE-based either. Most seem to run PHP (digg.com). Some seem to run Ruby on Rails. There’s one web 2.0 site that I know of that’s run on the JEE platform, and that’s zoho.com (the “.do” at the end of some of the links on zoho.com, i.e. http://wiki.zoho.com/jsp/ wikilogin.jsp?targetURL=%2Fregister.do, is a “verb” in Struts, an opensource JEE model view controller from Apache).

The question is, can JEE scale with the Long Tail? With internet access being nearly ubiquitous, websites will potentially have to handle hundreds of thousands of simultaneous transactions. Is JEE, a framework that’s great for the enterprise where there are a relatively small amount of simultaneous transactions, appropriate for coping with world-wide scale?

I hope so. But maybe lighter-weight, narrow-purposed scripting languages are more ideal.

Anyway, if you have experience with JEE dealing with “internet-sized” volumes, or if you know of any other JEE-based web 2.0 sites, please let me know.

So, I bought Agile Web Development with Rails – Second Edition. I read every page and did every tutorial (building a shopping cart application with a little AJAX magic).

Rails impressed me. Ruby did not. Ruby was invented in Japan in 1992 and was used without Rails until Basecamp came along and built Rails to “webify” Ruby. From what I’ve seen thus far, the Rails (and GEM and Rake) framework could have been created for any language. It seems that Basecamp had a bunch of Ruby programmers who one day decided to make Rails for Ruby because that’s what they knew. If instead Basecamp had a bunch of Java programmers we could be dealing with Java on Rails (although Java requires compilation, Ruby does not, so Rails might have ended up a little different).

What don’t I like about Ruby? For one thing, the method naming convention drives me nuts. In Java the convention is to use camel-casing, i.e. getCustomer(). But in Ruby, the convention is to use an “_”, i.e. get_customer. Furthermore, I can optionally insert the “()” (get_customer()), it doesn’t matter. Unbridled, the free-form and “flexible” nature of Ruby syntax could lead to unwieldy code, where one Ruby programmer finds it difficult to maintain another Ruby programmer’s code due simply to style differences (i.e. optional use of the return statement, optional use of {}). Furthermore, it is always better to detect and debug errors at compiletime rather than runtime, as runtime errors can often go unnoticed or be the result of something that happened 3 method calls ago (Ruby is a scripting language and is thus not compiled).

Ok, perhaps I’m just stuck in my ways. But, after reading my book I wanted to see if I could implement some of the cool AJAX and Scriptaculous features in a JEE application.

The first MVC (model view controller) I learned was ASP.NET. After 2 years of that I switched the JEE world and found a roughly comparable framework in Java Server Faces (JSF), and specifically Apache’s MyFaces implementation. JSF has a lot of support from the heavyweights in the software engineering industry including Sun, Oracle and IBM.

As of version 1.1.4 of MyFaces, AJAX does not come with it out of the box. So I found a great opensource project called Ajax4Jsf which essentially AJAXifies JSF applications. After resolving some version conflicts I was away, AJAX and all. Last I added visual effects with Scriptaculous and I was away.

The moral of the story is it is certainly possible to build Web 2.0-style interfaces using JEE, so there’s no need to abandon your Java programming skills just because people say “AJAX”, “visual effects” and “Ruby on Rails” in the same sentence. And certainly with mainstream adoption of data access frameworks like Hibernate it’s possible to simplify the process of database interaction in Java.