A long time ago, I asked the question: what would Rails need to have to be "Enterprise Ready(tm)?" A lot of the answer had to do with Messaging. Well, the fanboys at ThoughtWorks have apparently been working on just that. The really small sample looks interestingly compact, so compact, in fact, that I have a hard time seeing how and where you might configure it to talk to a .NET/MSMQ hub vs. a JMS provider, but I'm sure if I could get my greedy little hands on the code, all would become apparent.

The project apparently utilizes STOMP from Codehaus. It isn't a full-on MOM backbone, but close enough for government work, and certainly close enough to be useful for many of the needs of message-enabled web sites. If this really comes alive, then, according to my anecdotal research, the other three "must have for Enterprise Readiness" features still lacking are:

• Support for 2PC distributed transactions. But, since only about 5% of enterprise applications, and, like, 0.00045% of web applications, ever actually utilize this, I won't hold my breath or demand anybody else do.
• Internationalization. Huge problem, must be solved soon, many people working on it.
• A real component-based backend for rendering, a la JSF or Tapestry. While I like Tapestry, I am at best ambivalent about JSF and just don't see the point in going this route for Rails. Beyond that, I believe that anybody who makes this a pre-requisite for being "Enterprise Ready" is just looking for excuses. What they REALLY want, it seems to me, is a marketplace for buying/trading chunks of reusable code for website generation, for which Rails offers the plugin model and distribution network.

So, while a half-finished, not-officially-announced-yet messaging backend that isn't a full JMS clone won't make the Fortune 50 swivel around in their evil chairs and shout "Down with Java! Vive la Ruby!", it sure could be a giant step in the right direction. Makes me a lot happier, anyway.