Resource Oriented Architecture and OLTP

As the Resource Oriented Architecture (ROA) is slowly but inevitably starting to gain momentum, there will inevitably be loads of misunderstanding popping up from all sides. Today, we'll look at the grievances posted in the Give it a REST article by someone's "Chief Architect" Udi Dahan.

Here is what Udi claims:

If REST wants to conquer the enterprise, it had better get down from its "internet-scale" high-horse and start talking in terms of OLTP.

This is like saying "if OLTP wants to conquer the enterprise, it had better get down from its RDBMS high-horse and start talking in terms of registries and bits and bytes."

There is always something that is at the lower level than the system under study. Just because there is a lower level, doesn't automatically mean we should stoop to it.

The entire point of the REST and the ROA is precisely the liberation from the need to stoop down to the lower level. Using these principles, one gains the necessary discipline to resist the ingrained challenge to stoop to the lower level.

In case this is not clear to you, keep in mind that REST stands for 'representational'. Representational means representing something that is at the lower level.

And since we have the representation to play with, we don't have to worry about the underlying lower level.

So, in this case, you can envision ROA being a representation of an OLTP system. Yes, we know that behind the ROA veneer there is an ugly OLTP system. But we don't want to really go there.

Just as we know that behind the OLTP system, there is an ugly flat file, assembler code system. And we equally don't want to go there.

So try and train yourself not to stoop to the lower level. Enjoy the privileges and the benefits of the freedom that ROA brings to the table.

Rails 1.2 Drives the Final Nail in the Database Coffin

This morning's announcement that Rails 1.2 is about to hit the streets signals the beginning of the end of the database as we know it. Providing that no major roadblocks be discovered and that the Release 1.2 candidate firms up and becomes a real product, we're looking at the most important advancement in software development since the invention of Ruby 10 years ago.

You Don't Have to Hold Your Breath Anymore

I've been advising my friends, associates and customers to hold off their transition to Rails until Release 1.2. The reason I was doing that is because I didn't want them to be forced to learn something and then unlearn it and relearn a completely different approach. This is now the perfect time to jump into Rails, hook, line and sinker. There is absolutely no reason to hold back anymore.

Resource Oriented Development Changes Everything

The reason I think that Rails 1.2 is a death knell for the databases lies in the fact that it brings full fledged resource oriented development into the mainstream.

To quote "that other guy" from Seinfeld (from The Dealership episode; KRAMER: Listen to me. When that car rolls into that dealership, and that tank is bone dry, I want you to be there with me when everyone says, "Kramer and that other guy, oh, they went further to the left of the slash than anyone ever dreamed!"):

"Things will be different from now on."

Why do I think things will be different from now on? You won't know until you try the resource oriented development for yourself. Same as with Ruby (and LSD), if you haven't tried it, you won't know what is all that fuss that people are talking about.

A very significant side effect of this kerfafel is that databases are from now on going to undergo progressive trivialization. It'll take a lot of time for me to explain why is this process inevitable -- I'll save you the time by suggesting that you go and install Rails 1.2 and see for yourself.