Monday, December 25, 2006

Contracts and Coupling in Resource Oriented Architecture

We've seen that most software developers in operation today are besotted by the vendor model. One of the symptoms of that malaise is the deeply ingrained idea of a contract. Basically, it would appear that, in the minds of typical software developers, there cannot possibly occur an interaction between software components without a predefined contract.

Of course, the contract they are talking about follows (albeit covertly) the implicit revenue model as ingrained in a typical software vendor's business plan. Software vendors make their living by locking into a contract with their customers.

But in cases where the utilization of the software product is not tied with any revenue model, the notion of a contract tends to lose its appeal. Like, for example, in cases where an open source community is bettering the services by utilizing the publicly vetted web standards and protocols.

There are no Unilateral Contracts

The web is a platform that publishes its capabilities in a unilateral fashion. Similar to any other publicly vetted service, the web is calibrated to serve the least common denominator.

For example, in all developed countries in the world there is a publicly vetted service called traffic. Various vehicles are free to enjoy the commodities that the public roads offer, mostly free of charge. However, the reason this service is made so freely available without strings attached lies in the fact that it comes with an extremely pronounced and unbendable bias. That bias states that all vehicles moving along the public roads must keep to the right side of the road.

If this system wasn't calibrated in such a way, it would be impossible to offer the amenities for conducting the public traffic.

So we see that the utmost flexibility of an infinitely complex system, such as public traffic, is only possible if that system is heavily calibrated in a non-negotiable fashion.

And because that calibration is non-negotiable, it does not qualify as being called a contract. In other words, if you're driving your car down the road, you're not holding the traffic contract in your hands that outlines all the details that bind you and the road owner. The road owner (i.e. the public) dictates the rules, and does so unilaterally. You have no say in whether you accept to keep to the right side of the road while driving. You simply must obey the unilateral rule, or suffer the consequences.

To put it more mildly, you must 'get used to it'.

Same principles apply when you're 'driving' around the web. The web specifies upfront the non-bendable rules and regulations, and you have no say in whether you like them, don't like them, whether you're planning to obey them or disobey them. The web doesn't expect you to make your stance known, and the web absolutely doesn't care.

Because of this unilateral set of rules, there cannot be a contract between the sever software on the web and the web client.

The Web is Uncoupled

Because of the lack of a bilateral contract between a web server and a web client, it is not possible to talk about any form of coupling on the web. Tight or loose coupling, which are terms tied with the world of software vendors' applications, lose any meaning on the web.

There are two reasons for this change:
  1. On the web, the server need not know anything about the client
  2. On the web, the server is blissfully unaware of the existence of any other server
All that is known on the web is that it is a sprawling collection of resources; these resources are easily accessible via the publicly vetted protocol (i.e. URI), and these resources know how to represent themselves and how to make their own state transition upon request.

Thanks to this particular bias, the web is the most scalable, the most interoperable, and the most robust, resilient and comprehensive computing platform ever.

Saturday, December 23, 2006

Resource Oriented Architecture and Quality

In his recent post exposing imaginary limitations of the REST paradigm, Udi Dahan laments the lack of explicit dialog that would discuss the benefits of adopting REST. More specifically, he writes:

"What I haven’t heard is how I can use it (i.e. REST) to build large-scale distributed systems that are controlled by complex logic."

Here, I believe he is talking about his definition of quality. Building large-scale distributed systems that are controlled by complex logic sounds like a very costly proposition. Something one would not attempt just for the heck of it, just to kill a rainy weekend.

Because such a project entails a price tag of hundreds of thousands, if not millions of dollars, it is not to be taken lightly. Also, it is not something that happens very often. I would venture out to say that most of us have never been involved in such a project, nor will we ever find ourselves involved in such a thing. It is not very often that businesses embark upon building such complex distributed systems. Yes, eBay and Amazon etc. are such systems, but you could almost count these beasts on the fingers of one hand.

So the question that mystifies me a bit here is: why? Why worry about building such a large-scale distributed complex system? What's the business case for it? How many of those are you planning to build next year? What's your compelling reason for going after such a risky venture?

But assuming that Udi has his valid reasons, and that he has millions of budget dollars to back him up (which, frankly, I seriously doubt), let's engage him in his quest, for the sake of having fun.

What I'm assuming here is that, to Udi, large-scale complex distributed systems spell quality.

So You Want to Build a Multi-million Dollar System?

Why would a system we're building end up costing millions of dollars? There are several possible reasons:
  1. We are using primitive technology, and thus it's taking us too long to build
  2. We don't understand what is the system supposed to be doing, so we're making things up as we go
  3. The scope of the system is on a runaway curve, and so we end up with explosion of features (i.e. featuritis)
In the case of primitive technology, we can imagine trying to dig the Panama canal by giving each worker a wooden spoon. That technology would be considered very primitive for the intended job, and would therefore result in the astronomical cost of the project.

Similarly, if we attempt to build an equivalent of amazon.com or ebay.com using assembler, we'll end up paying astronomical price for using such primitive technology.

In the case of not understanding the goals that the system under construction is supposed to deliver, 'fishing for results' would invariably turn out to be prohibitively expensive.

Finally, in the case of scope runaway, featuritis and bloat are well known for being insanely expensive.

Let's say Udi is unphased after reading this, and still wants to proceed with building his multi-million dollar large-scale complex distributed system. He is now curious how can REST and ROA be of any benefit to him. Let's explore.

Can REST and ROA Help?

My knee-jerk answer is: not really. But let's not give up so easily.

First, let's make two things clear:
  1. If we don't understand what is the system supposed to be doing, then no amount of technology can salvage us from dying a miserable death
  2. If we contract the featuritis disease and start bloating, there equally is no technological cure; we'll be doomed to collapse under our own weight
So let's assume here, for the sake of having fun, that Udi is immune from the two forms of malaise mentioned above. Let's say he has a very clear understanding of the goals of the large-scale distributed complex system he is trying to build, and let's also assume that he is immune from the featuritis and bloat (both assumptions being extremely unlikely, by the way, but let's pretend they've been licked).

Seeing a Problem where there isn't Any

OK, so Udi is concerned about the following:

"There are business rules that control which data should be returned and when. All this has been known for quite a while and has been modeled around transaction isolation levels in the OLTP sense, and needs to be handled at the application level when it comes to intelligent caching. I haven’t heard anything about REST that deals with this."

My question is: why on earth should REST be expected to deal with that? REST and ROA, as their names imply, specialize in dealing with Resources and their Representations. They don't specialize in dealing with the infrastructure that is the underpinning for the resources.

For all we know, that infrastructure might very well be implemented as OLTP, or perhaps as something else. Same as the ability of the RDBMS to index the data stored within it might be implemented using various algorithms. But in reality, who cares? The important thing is that it works and meets our expectations.

Next, Udi asks:

"If, as a result of updating one entity, other entities are affected how is that information propagated back to the caller?"

This is simple: the caller consumes resources by dealing with their representations. This is the essence of REST. The ground rule in ROA is that raw resource can never be touched by the client, or by the caller. All one is allowed to work with is the resource's representation.

Udi talks about updating an entity. I'll try and translate this into ROA speak. Instead of updating an entity, in ROA we speak of requesting a state transition for a resource. The way it works is as follows:
  1. A resource gets identified (via the URI)
  2. That resource then gets located (via the corresponding URL)
  3. A request is then sent to that resource to change its state (i.e. to make a state transition)
At the end of that chain of events, other resources (or, 'entities' in Udi's parlance) may or may not get affected.

His question, then, is: how is that fact (i.e. that other resource got affected during the state transition) propagated back to the caller?

The answer is glaringly simple: it all depends on the use case. If the use case requires that the caller be notified of the state transition, then the appropriate representation of the new state will be presented to the caller in the form of a response.

One really feels like stopping at this point, and asking: what's the big mystery? Why is it that all these highly paid software architects are having such hellish time grasping this extremely simple concept of resources, their states, and their state transitions?

I am indeed forced to conclude that they seem to working really hard on trying to see the problem where there isn't any. Is that why they get paid those big bucks?

Here's the Skinny

Udi even gives us a tiny homework:

"Let’s say I have a simple rule: When the sum of all orders for a customer in the past quarter increases above X, the customer is to become a preferred customer. Do I PUT the new order resource to the customer resource, or should I have a generic orders resource that is “partitioned” by customer Id? Once the change to the customer occurs, should I PUT some change information somewhere so that the initiator can find out where it should go look for the change? And how should I be handling transactions around all these resources?"

Again, he is confusing apples with oranges. Let's break it down gently:

A customer is a resource. We don't know how is that resource implemented behind the firewall, and we really, really don't want to know! This point is crucial to understanding ROA. Please keep in mind that ROA is definitely not about the how.

OK, we now need to understand that a resource (i.e. customer) has state. For example, the resource could be in the state of being a preferred customer, or not being a preferred customer. However, we don't know, we have no idea how is that state implemented. Also, we don't want to know anything about those gory details.

On to how does that state change. Recall that REST stands for "Resource State Transition" (actually, this is incorrect, and this section talks about ROA, not REST; please see the correction notice at the end of this post). So 'state transition' is the crucial phrase here. Obviously, a resource is capable of making a transition from one state to another. Such as making the transition from the state of not preferred customer to the state of preferred customer.

How/when does that state occur, you ask? Well, that transition is driven by a particular event that must be described in the use case scenario. Like in Udi's use case above, in case of an event when the resource's state (such as total value of accumulated orders) reaches a predefined threshold, that resource knows how to make the transition from not being the preferred customer to becoming a preferred customer.

Again, we don't know how is this transition taking place. There are millions of conceivable ways that transition could take place, but the important thing is that it does.

All of Udi's questions surrounding this hypothetical scenario boil down to how, but that's largely irrelevant. Somehow the resource knows the proper way to make the transition from one state to the other state. When the client then makes a request for getting that resource, the resource in question will know how to represent its state, including the newly won 'preferred customer' feather-in-the-cap.

Correction: I've just realized that, in my eagerness to explain the encapsulation that Resource Oriented Architecture offers, I've made a mistake and erroneously ascribed state transition to REST. Actually, REST stands for Representational State Transfer, not Resource State Transition. The latter is a characteristic of ROA, not REST.

Sorry for the inadvertent error.

Thursday, December 21, 2006

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.

Friday, December 15, 2006

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.

Wednesday, December 6, 2006

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.

Tuesday, December 5, 2006

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.

Monday, December 4, 2006

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).

Saturday, December 2, 2006

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.