A Space to Think...

Now, there's a difficult and flame-aggravating title, so I think first that I'll clarify where I'm coming from.

I am most definitely a Rails advocate. Not to the point of religious fanaticism, as you sometimes see around the Ruby on Rails camp, but definitely a massive fan. Rails, to me, is honestly a technology that makes it very easy to create great web applications and, funnily enough, services^[3].

So why do I say that Rails is not ready yet to be great for SOA? Well, the key in my title is the word 'yet'.

Rails, and Ruby, is a fantastic development environment for creating web services, REST based, SOAP based or otherwise. In fact, when it comes to web applications there's not much (if anything, but you can't be 100& sure) that you can't do with Ruby or Rails.

If, and it's an important if, you are going to have a database.

Rails has a darker side. Think of Rails as being the perfect new housemate until you cross the line of some unwritten rule that you hadn't heard of before you sauntered across their threshold. Rails is what's called "opinionated software"^[1][2] - it lays down some pretty strong rules about what you can and can't do in order to make it easier to develop in by applying some best practices.

Unfortunately, while this "opinionated" characteristic is in fact one of the things that makes me love Rails (I'm also a big advocate of keeping your software platforms 'opinionated'), it's also one of the things that makes me curse it.

So, why does a really helpful SOA platform and an opinionated Rails framework not have in common. The simplest thing really, one word: database.

In a SOA, you don't necessarily need a database. Let me clarify: when you come to implement a service-oriented architecture it is quite probable that a few, if not the majority, of your services will not have a database.

But if you are creating your services in Rails, opinionated beast that it is, you will need to have a database handy if you want to run unit tests. Ok, that's not completely true, you can run rake unit testing on your service, but it takes a lot of hacking and some in-depth know-how (see the "No database" recipe in Rails Recipes, but its debatable as to when this works or not...) to extricate Rails from the assumed presence of a database.

So that's my point. Rails is easy to use, fantastically easy at constructing interoperable web services using any flavor of approach you like, but if you haven't or don't want a database involved in your service, then things can get pretty painful very quickly.

Not that you can't overcome this no-database pain, because you can with the aforementioned hacking, but that in contrast to how beautifully simple the rest of the Rails framework is for most tasks targeted at web applications and SOA, the pain setting up your application to not use a database for its unit tests and runtime is magnified a hundred-fold*

* This is the law of contrasts. When you develop with a difficult-to-use tool, you'll put up with a lot more than if you're used to the tool being dead simple.

"But Rails is a database-driven web framework" I hear the Rails people cry. "It's not meant for you if you're not using a database! Go find something else!". Fair, if often loud, points.

It's true that databases are one of the aspects at the heart of Rails, I understand that. My point is that Rails is such an excellent framework that it is already really close to being great for SOA.

I understand that Rails is opinionated when it comes to databases, I just wish that it was a little more lenient when it comes to recognizing that there are apps, including but not limited to services, where it would be nice if it were a bit easier to ignore the lack of a database.

If that day comes along then I'll be the first to say that Rails is perfect for SOA development.

But, for the time being, that's why I have to say at this point that it is not ready 'yet'...

References

[1] An interview with David Heinemeier Hansson on the O'Reilly Network.

[2] Make Opinionated Software chapter in Getting Real by 37 Signals

[3] My articles on the SOA Ranch