Yes, says Bruce Tate, CTO at IT consultancy WellGood LLC., where he is leading development of RESTful SOA applications using Ruby on Rails. However, for all of its capabilities as a dynamic language that facilitates RESTful development, Tate, an early advocate for Ruby, says there has been one stumbling block.
"It only works if you can deploy it and make it scale," he says.
That is why he has co-authored a new book, Deploying Rails Applications: A Step-by-Step Guide with Ezra Zygmuntowicz, founder and chief architect of the EngineYard.com hosting service, and Clinton Begin, software consultant and creator of the iBATIS SQL-centric framework for Java.
The book is intended to help developers learn to successfully deploy Rails applications so they scale and can be performance tuned. It walks the reader through application setup in Rails/Nginx/Mongrel cluster for high scalability, Tate said.
"We cover setting up virtualized boxes instead of regular dedicated boxes to separate the components of your architecture," Zygmuntowicz explained. "So you have separate virtual machines for your database tier, separate virtual machines for your application tier, separate virtual machines for your Web server tier. So you don't have these monolithic Linux boxes with many, many services running all mixed together."
Putting each individual service on its own virtual machine facilitates scaling and performance tuning, the EngineYard architect said. "It allows you a much better way to do performance tuning of your application because every tier of your architecture is individually scalable," he explained.
Begin said the book will be helpful in getting developers started in deploying Rails applications in the real world. But as the author of a previous book on iBATIS, he points out that all books for coders have their limitations, not the least of which is that technology changes so quickly that most programming manuals are outdated by the time they are printed.
"What I hope our book teaches developers is how to look at Rails deployment and understand why it's deployed this way," he said. "They should be able to walk through a deployment as we do it in the book."
Following the old maxim that rather than giving a hungry man a fish, it is better to teach them to fish so they can catch food for a lifetime, Begin said developers should see the book as a starting point on how to architect these sorts of lightweight systems.
"What I want them to be able to do after reading the book is think for themselves," he said. "Take what we do in the book and go out an apply that and maybe use a different application server than Mongrel. There's one out there called Thin. So maybe that's the app server they use."
He said even though Thin is not covered in the book, he believes developers who read it will have the basic understanding of Rails deployment to be able to work with the app server of their choice.
"I want them to be able to read this book and not take everything too literally," Begin said. "I want developers to be able to get this information and be able to generate new approaches to their own deployment that fit their needs. We're not trying to do a one-size-fits-all."
If developers can learn to affectively deploy Ruby on Rails applications for enterprise SOA, they can take advantage of capabilities that the authors argue are superior to what can be done with Java or C#.
For those planning to take a RESTful approach, Ruby on Rails has built in advantages, Tate said.
"One of the contributions of Rails is its ability to be a very efficient REST platform," he explained. "As you enter the earliest pieces of script to generate pieces of your application on the fly, REST automatically gets generated from the Rails resource generators. What makes the platform nice from that perspective is you can have one application that can handle HTML and XML requests. And that's out of the box before you start building additional pieces and customizing your application."
Although in his consulting Begin has worked extensively with Java, he is adamant that Ruby on Rails is the best choice for real world SOA.
"The reason I think dynamic languages, not just Ruby but in general, are important is that currently with Java, or C#, or any other statically compiled language, the problem with them is there is no way to code against the Web service without generating a lot of code," Begin said. "I have one Web service that calculates tax. It generates over 50,000 lines of code just for one Web service. It's 2.4 megabytes of Java code. That's one Web service. We have 20 Web services. And I haven't even started my app."
Begin doesn't hold with claims that Ruby on Rails will make a developer "ten times more productive," but based on his experience having worked with Java, Rails has intrinsic advantages, some of which can't be quantified, such as his opinion that Rail is "a more enjoyable platform to work on."
Based on his experience with Rails, he said, "It is simpler and in general I think you'll be more productive. Instead of spending time writing SOA layers and adapters for Web services talking to Web services internally in your environment, you'll be spending more time on the customers' needs as opposed to technical needs. That's where I think the benefit of Rails is, in the quality of the end product."