RESTafarian Jihad

I've just been accused of waging a RESTafarian Jihad. I feel that this accusation is unjust, and that it is uncalled for. So I need to explain and defend my case here.

Jihad is a strong word in this context, because it came to mean 'holy war' in the modern parlance. And I'm nowhere near waging a holy war on anything, least of on the non-REST platforms.

To be more specific, I am absolutely not interested in converting the Remote Procedure Call (RPC) people to REST. True, approximately 98% to 99% of all software developers I've ever met cannot imagine building a distributed software system without utilizing some form of RPC, so for these people, Resource Oriented Architecture (ROA) is meaningless.

But as I've already explained in one of my recent posts, I view these people as a write-off. Basically, I think there is nothing we can do about that, and that it's time we cut our losses and move on with our lives.

So you see, I'm leaving the RPC crowd (which means almost all software developers in existence today) alone. I'm not waging any Jihads, I'm not plotting to convert anyone.

Instead, I strongly believe that, as it has always been the case, the simpler system, with lower barriers to entry, will somehow win in the end. I don't really know how, but God's ways are mysterious, so we'll see. But same as CORBA had to disappear because it was just too unwieldy, web services and SOA will also be forced to vanish from the scene.

At that point, ROA will take the lead. Right now, we're preparing for that portentous event. It will come in its own sweet time. We're not rushing anything.

We know that, eventually, people will abandon the ways of the past century, and will embrace the twenty first century ways of employing high technology.

Are Software Developers a Writeoff?

My friend Ted introduced me to the idea that we won't be able to see the real effects of the web until the time when the last person who can remember the days before the web dies out. In his view, if you can remember life before the web, then you're not capable of fully grasping the web.

I tend to agree with him. The web is such a drastic paradigm shift that we're not really capable of fully grasping its significance.

But the young and upcoming generations, who can't remember the days without the web, will be much better equipped to cope with it. Same as I take electricity and indoor plumbing for granted, my children take the web and the perpetual availability of the wireless connectivity for granted.

And that makes them a different kind of persons than I, their father, am. And I find that to be a very fascinating phenomenon.

New Breed of Software Developers

Similar to how my children are a new breed of humans who have a completely different outlook on the web than I do, there is an upcoming new breed of software developers who are diametrically opposite from the existing, entrenched batch of software developers.

The existing developers, as I've been discovering through gruesome series of interviews lately, seem completely oblivious to the incredible powers of the web. All the developers I talk to seem to think that the only way to accomplish something in the software development arena is to use the function calls. They all follow the software vendors' lead, which typically means more complexity, more heavy lifting, less palatable solutions.

Because this tendency is so pervasive and ubiquitous among the existing software professionals, I have reached a point where I'm pretty much ready to throw the towel in. In other words, I'm this close to call all your typical software developers, all those entrenched Java, J2EE, .Net, Oracle etc. developers a big fat writeoff.

I am slowly starting to think that this workforce, as huge as it is, is pretty much useless when it comes to business computing. Some of them may be good for developing certain components of the computing infrastructure. But as soon as we get to the point of utilizing this infrastructure for the benefits of the business, they all turn to be nothing but a writeoff.

And by 'writeoff' I mean more harm than good.

This is why I'm forced to turn my attention to the young and upcoming generation of software developers. We need to ensure that these young people don't get tainted by the tool vendors' agendas and business models. We need to make sure they don't get caught in the remote procedure call hell.

Resource Oriented Architecture and Vendors

Suppose we get to the point where Resource Oriented Architecture (ROA) becomes prominent and gains wide adoption. Given the ubiquity, pervasiveness and popularity of the web, it is not a far fetched proposition. After all, the native web is strictly resource-based, and a Resource Oriented Architecture that utilizes that orientation seems like a perfectly natural fit.

Now, if this re-orientation happens, what will the vendors do?

Vendor Business Model

Software vendors are in the business of making profit from selling software based solutions. Traditionally, the most efficient solution, from the vendors' profitability point of view, tends to come in the form of a tool. This is why we tend to call these vendors 'tool vendors'.

Because of this orientation, vendors tend to favor system architectures that are complex, convoluted, difficult to fathom and master. Of course, anything can be quite easily made more complicated than it already is. In other words, it is quite easy to muddle the issue, to add complexity, to increase brittleness. You don't have to be very smart of very competent in order to make things more complicated.

As a matter if fact, complicated situations are always a surefire sign of stupidity. If, on the other hand, you find systems that work but are nevertheless very simple and easy to navigate, that invariably means that someone quite intelligent has devised such a solution.

But, since an easy to understand, easy to navigate and use system is non-profitable from the vendors' point of view (i.e. such systems do not require 'tools' in order to be utilized), vendors do not see any value in playing along with them. Vendors prefer murky, complicated architectures. Getting you involved with such ungodly systems and architectures is a very lucrative proposition for the vendors, because then they have a very good justification to approach you and to start selling you their tools.

Do We Need Tools?

Take a practitioner of a well established profession, such as a lawyer, or a mathematician. These professionals deal with extremely elaborate, intricate systems and bodies of knowledge. They are expected to navigate very sophisticated waters of highly formalized systems.

But what kind of tools do they need in order to do their jobs? In reality, very few. For a lawyer may need nothing more than a typewriter, and a mathematician actually needs even less tools -- a paper and a pen will do just fine.

How come? It's simple -- their job is largely conceptual by nature.

Now, the question is: how is that different from software development? Why do we think that software development is not conceptual by nature, in ways similar to mathematical development?

The thing is, software development is not different in any significant ways from mathematical, or legal developments. They are all largely conceptual activities.

And realistically speaking, all these conceptual activities don't need many specialized tools. It is a great fallacy, perpetrated on us by the tool vendors with their business agendas, that software development needs an elaborate set of tools.

Choose the Right Foundation

And since we are dealing with a fairly conceptual activity when developing software, it is of crucial importance that we select the right foundation, the right philosophy, and the right paradigm from where we can operate successfully.

Choosing the right starting point will ensure that we don't get entangled in the morass of complexity, brittleness, analysis paralysis and the like. Otherwise, it would be devilishly easy to slip and end up in the blind alley.

If we now review the philosophy and the paradigms that the tool vendors are offering us, we see that they prefer to side with complexity, heavy lifting and hard work. The vendors are proposing we adopt systems that are architected for ever growing complexity. Theirs is the business model of introducing a big hairy problem, and then selling the solutions that would be pain killers.

So what's the alternative? We propose that instead of aiming at acquiring pain killers from the vendors, we focus our efforts on acquiring vitamins.

And in our vision, vitamins would be the publicly vetted standards upon which the web, as a universal computing platform, is built. The web offers us simple, extensible, scalable, interoperable and linkable architecture. As such, it is very beneficial to us in the sense that it does not introduce the pain of complexity which then needs to be handled with pain killers.

It's Not the How, it's the What

By now, we all know the intentions are older than implementation. There were times when foolish software developers used to think the reverse was true, but thankfully today most of them have been browbeaten into aligning with the program.

So everyone seems to agree nowadays that articulating the what (i.e. the intention) is much more important than articulating the how (i.e. the implementation). So where's the problem then?

Web Development Challenges

While every prudent software developer had by now learned the lesson in separating the what from the how, they still seem to be applying it at too low a level. Similar to how the budding software developers of the olden days used to build those monstrous huge bloated monolithic programs that ended up being totally unwieldy and unmanageable, today's web developers are falling into the same trap of building similarly huge, bloated, unwieldy web sites.

Or, let me put the question up to you like this: what would you rather build -- a huge monolithic tightly coupled software program, or an open-ended set of smallish, self-contained, loosely coupled software units, that are easy to implement, easy to test, easy to troubleshoot and debug, easy to deploy?

Of course, if you are a software developer worth even a tiny bit of your own salt, you'd go for the latter. Some of us still recoil in horror when the flashbacks of bad old days of monstrous monolithic software programs come back to haunt us. Ugh, not a happy memory!

But it's really funny how these time honored principles of separation of labor, inversion of control, etc., do not seem to translate at all when being ported to the web development. Here, when developing web sites, budding software developers are more than happy to fall into the same old trap of indulging in muddling the concerns and seeking a single point of control. Which ends up in incredibly messy, monolithic, coupled and unmanageable web sites.

This, again, is the outcome of blindly rushing in to grab the how! How do I do such-and-such in Rails? How do I do such-and-such in Ajax?How do I do such-and-such in Flex? And on and on...

People never seem to stop to think what. What do I need to do in order to make this work? Forget about how to do something, and focus on the what.

How you do something is really not a big deal. 99 percent of the time it's just a short google search away. So why sweat the small stuff?

The what is much tougher. Google will not be able to help you there. You'd need your own cool head, your own common sense to figure that one out.

The surefire sign that you're charging down the wrong path is if you find yourself building large monolithic web sites. You know the ones that rely on the function calls, with one central point of control? The ones where it gets progressively difficult to introduce any new capability?

You know the ones I'm talking about. I bet you that right now you're working on one such site.

Well stop! Same as you wouldn't work on a single humongous big ass class, but would rather chop it up into dozens and dozens of smaller, more manageable classes, you must do the same with that web site. Abandon it. Chop it up. Give up the single point of control, give up the irresistible need to shoehorn everything through the single funnel of omniscient point of control.

Think back to your other software development skills. Remember how tough it was until you've learn how to properly delegate?

Well, now's the time to do the same delegating, only not with objects, but with web sites. Treat each web site as a single independent component, that specializes in offering some useful resources. Then open us the traffic gates. Let those independent, standalone 'components' interact, and see what happens.

See, I gave you the what; the how should be a piece of cake for you now.

Web Model for Business Computing

After reviewing the Vendor Model for Business Computing, it is now time to look into the web model. To refresh your memory for a moment here, the fundamental differences boil down to how each model treats data vs business logic.

As we've seen, vendor model tends to freely expose the data, while jealously hiding the business logic. It operates on the fundamental premises that data is deadwood that can only be animated thanks to their marvelous business logic. Without their magical proprietary processing logic, the data remains useless and thus worthless.

Consequently, vendor model insists that we pay good money to gain access to their beloved processing logic.

Web Model is for Humans

Unlike the vendor model, the web model was built with human beings in mind. Instead of insisting that some cryptic, arcane and privileged proprietary business logic be the animator of the data, web model leaves data animation to the most suitable subjects -- human users.

This is why products based on the web model have nothing to hide when it comes to the processing logic. They don't deem this logic very important. As a matter of fact, such products leave almost all of the decisions as to how one would like the data processed to the human users.

Which is where that decision rightly belongs, after all is being said and done.

Web Model Hides the Data

Quite surprisingly, as much as the web model liberates us from the slavery of being governed by some secretive proprietary processing logic, it is equally adamant that we don't gain access to the data.

Instead, web model insists that we only gain access to the representation of the data. But as to what the actual data looks like, or how does it really feel like, we remain forever mystified.

We'll talk some more in the upcoming series about why is such arrangement a much better thing for all consumers of software.

Web Model vs. Vendor Model

There are two models of business computing: vendor model and web model. Vendor model is presently the entrenched model, the one that everyone is locked in.

Web model is brand new. Ask any software developer about the web model of business computing, and they wouldn't know what that model is nor how does it work.

But that doesn't mean that the web model is irrelevant. Quite the reverse, it is the most significant thing to ever happen in the world of business computing.

How is the Web Model Different?

Perhaps the best way to understand the web model of business computing is to discuss how is it different from the vendor model.

Before we delve in, let's just quickly recapitulate what are the characteristics of business computing. You may recall that any business computing model must be based on three fundamental characteristics:

1. Identity
2. State
3. Behavior

In the business computing parlance, and for the purposes of our discussion, we can say that the state is equivalent to data, and the behavior is equivalent to the program logic.

Getting back to the difference between the vendor model and the web model of business computing, we will see that the two models fundamentally differ in the way they treat data and programming logic.

Vendor model insists on exposing the data and hiding the programming logic.

Web model, you guessed it, is the exact opposite -- it is based on the architecture that hides the data and exposes the programming logic.

Both models have their use, and in our ongoing series on the Resource Oriented Architecture (ROA, which is the underpinning of the web model), we will be discussing the advantages of the model that hides the data.

Stay tuned (and don't feel shy to ask any questions).

Resource Oriented Architecture -- Growing Pains

I've already discussed the problems related to how traditional software development workforce seems incapable of grasping Resource Oriented Architecture (ROA). Today, I will tackle another of the misconceptions that seem to inevitably keep popping up in the software development circles.

Someone who very appropriately claims that adding simplicity is an engineering mantra, wrote about the Promise of SOA, REST, and ROA. Here, we will only focus on his view of ROA:

ROA is an intriguing proposition. Applications are freed from worrying about services at all. A resource, which is effectively an entity, exposes the state transitions it is willing to accept. Applications don't even care what the resource is, they simply decide whether they are interested in the state transitions available. The level of omniscient inference with this approach is difficult to even explain. So, if the resource is a tennis court and the state transition is reserve (is that a state change or operation?) an application can decide, without caring about the resource per se, that it wants to reserve it. Of course if this is a seat at a concert you may be committing to a financial transaction. At the very least, the state may change back without the applications knowledge (except it's omniscient so that isn't possible).

Let's pick this apart, to see if we could identify sources of confusion.

Applications and Services

The post quoted above states that: "Applications are freed from worrying about services at all." First off, it is important to understand that ROA is not about applications. This was hinted at in my post on the golden age of software applications.

ROA is, as its name implies, all about resources. Some people claim that it's basically the same as being all about services, but I strongly disagree.

Resources and Entities

He continues: "A resource, which is effectively an entity..." Maybe I should let this slide, but let me just point out that a resource is effectively a resource. No need to drag entity into the picture.

Acceptable State Transitions

Moving along: "[Resource] exposes the state transitions it is willing to accept."

This is absolutely incorrect. Resource only exposes its representation, not the state transitions it is willing to accept.

Applications and the Attempts to Simplify Reality

"Applications don't even care what the resource is, they simply decide whether they are interested in the state transitions available."

He is again talking about applications. And by 'applications' I suspect he means blobs of pre-compiled code.

Again, this is the old, vendor-dictated school. ROA, on the other hand, is the new, vendor-averse school.

Unlike the vendor-giddy applications, ROA does not waste time in the vain attempts to simplify reality. ROA recognizes and realizes that reality is unthinkably complex. And so ROA lives with it, is based on it, grows from it.

So ROA is not interested in any intricacies of the state transitions that are specific to any of the involved resources. The reason for this is that it would be absolutely impossible to be interested in such things, given their astronomical complexity and volatility.

ROA therefore throws the towel in at the very outset. It is non-competitive by nature.

Not Knowing is the Most Intimate

The author goes on: "The level of omniscient inference with this approach is difficult to even explain."

There is a famous Zen koan in which a Zen Master asks a question, and his student responds: "I don't know, Master".

"Not knowing is the most intimate!" replies the Master.

What is a State Transition?

Seems like traditional software developers are clueless when it comes to grasping the state transition model in ROA. For example, the author of the above post continues:

"So, if the resource is a tennis court and the state transition is reserve (is that a state change or operation?) an application can decide, without caring about the resource per se, that it wants to reserve it. "

There is no such thing as a state transition called 'reserve'. In Service Oriented Architecture (SOA), yes, one can envision such state transition. But never in ROA.

Furthermore, here is that pesky application again. Who is this application, on behalf of which vendor is it entering the picture, and how is it deciding what to do?

The State Changes

Finally, there is (at last!) one thing that both the old school and the new school of software development agrees upon: the state may change! Hallelujah!

"At the very least, the state may change back without the applications knowledge (except it's omniscient so that isn't possible)."

The above sentence actually doesn't make any sense. Who is omniscient? The application? Who made this application?

The whole point is that, when talking about resources, the old school developers are actually not talking about resources (the above quoted article illustrates this rather poignantly). Then they wonder out loud how come they don't get ROA?

All that the old school developers seem capable of thinking is applications. This belies their state of being brainwashed by the tool vendors.

I am fairly positive at this point that unless software developers manage to deprogram their brains and escape the tool vendors' programming (i.e. brainwashing), they will remain completely lost for the world of Resource Oriented Architecture.

Just as well.