05/26/08 :: [SOA] Web Services is an RPC-Oriented Technology [permalink]
I remember when I was a young graduate student in the late eighties thinking about IEEE as some kind of powerful temple of knowledge and source of wisdom. Having anything published in an IEEE journal was a distant dream of mine (that never materialized).
Then comes Steve Vinoski, a senior member of the IEEE and a member of the ACM.
He and Stefan skillfully keep avoiding the question about how actions are modeled (and implemented) in REST. In this excellent interview (great job Markus), Stefan shows how knowledgeable about HTTP and REST he is. But when Markus asked him, "Stefan, tell us how you implement "Submit Order" and "Cancel Order" in REST", he starts answering how to "Create a resource" with a POST and with great skills, quickly changes subject before answering the real question, how are actions modeled in REST? We know better today they are not.
In his latest column, Steve goes one step further in the misinformation, after a summary of the benefits of REST and HTTP, this is what he claims:
RPC-oriented technologies such as Web services are intended primarily to extend programming language idioms and patterns across the network.
By doing so, they hope to make the developer's job easier; unfortunately, this comes at the cost of significantly reduced scale, greater client-server coupling, and more difficult system modification and maintenance.
Boy, isn't the review process broken at IEEE? I would not want to publish anything there as long as this kind of boloney can pass through publication.
I'll pass on the section that Steve calls "Specialized Data Issues", this section was written to comfort the REST followers in their beliefs. Steve uses a very well know technique: You talk about the problems that Web Services took on to solve (and for the most part solves) and you play them as scare-crows.
Then, you take the great things about REST, and you play them in raw fashion as incantations (BTW, half of them WS-* can do). That's when the followers cheer. Then you close, with modesty, saying, there a still a few issues with REST but we are working on it, or you claim "the world can't be perfect".
Now, these two guys are really smart, I would even argue a lot smarter than me (and I mean a lot). But at this point, how could we trust what they say? The kinds of things that Steve (such as the quote above) or the kinds of convenient omissions [1] are no longer "honest mistakes", they are meant to deceive.
That being said, I find Steve's quote really symptomatic of what has happened over the last 50 years (though I still don't think this is an honest mistake [1]). My theory is that "computers" were, well..., originally ... computers. Meaning they "computed". Programming languages were invented to crunch numbers nothing less, nothing more. Having been the first guy to hack an implementation of "Factor Analysis" on a 640k PC in the late 80s, I can safely say that. The "processor" is deep at the roots of all programming languages. All our programming abstractions were invented to make it easier to shift bits around. And yes, Steve is right, there was once a group of people in the industry that focused on "extending programming language idioms and patterns across the network". He was part of them, and we all know how that ended. Insidiously, he is trying to use REST to keep the CRUD-oriented Synchronous Client/Server programming model alive for a few more years.
The disconnect at the programming language level comes from the fact that computers were not the systems of record. It is not until the advent of mass storage that the "computer" slowly evolved into an "information system". In the most ironic fashion we talk about "Information Technology" when we should be talking about "Programming Technology". None of the programming languages evolved during this transition and this is the root cause of most of our problems today. They remained for the most part unchanged since the early 60s. I believe that the core rationale for keeping them unchanged was that both actions and functions could be modeled with the same programming idioms. The advent of SQL in the early 80s only comforted this design decision by relegating all information related stuff to constructing a "string" and calling an RPC "exec" to the RDBMS.
This seemingly harmless and simple design proved to be a tragic mistake. We lost states and transitions in the process: they never made it to the programming model even though they were core to information systems (but totally useless for "computing"). We also pushed the responsibility of sorting actions from functions on the developer which eventually did not make any clear distinctions between the two leading to the "distributed mess" Steve is talking about. OO was no better, it was a "programming technology" deceptively disguised in an "information technology" which only sealed the problem by creating bubbles of data over a relational information sea.
The bottom line is that Information systems never got a chance.
The reason why I am extremely upset at Stefan, Steve and Tim (I do think all the other people in the REST community are genuinely looking for answers not followers) is that the software industry is very close to have a programming paradigm that would constitute a new and solid foundation for information systems using idioms such as resources, inter-actions, state, transitions, trans-actions... and new programming constructs such as a bidirectional interface, orchestration... all built on top of an asynchronous programming model. We could have been there for nearly 10 years at least if only interoperability nuts would have left us alone instead of "extend programming language idioms and patterns across the network" using XML and HTTP, now some REST nuts are keeping us behind by pretending there is no need for actions, you can CRUD your way in anything you want. It is a bit harder for the REST nuts to get away with it because they have a "resource" at the core of their programming model, so it is going to be impossible to keep pretending there is no "actions".
Steve, you are going to kill both REST and Web Services by making the claim that Web Services is an RPC-Oriented technology and forcing people to use REST in a CRUD-oriented way. You setting us back 40 years, to your world. This is ubuesque.
The need for this new programming model is exacerbated today by the emergence of "composite information systems" where no single software agent can be the sole system of record. How do you think that a programming model invented in the 60s is going to survive that?
[1] Before anyone flames me, please read this section of Steve's paper:
Resource representations contain hyperlinks to help applications know how to perform application state transitions. For example, a resource designating a list of employees might return a representation containing a list of hyperlinks, each referring to a separate resource for each employee in the list. An application looking for information about a given employee need only follow the relevant hyperlinks using data and metadata within the representation as a guide.
This section means that Steve (like Stefan) understands very well (too well) the question of "state" and "transition" and how an action can cause a transition from one state to another. It would sure be a bit more trustworthy if they would explain clearly how an application (not a human) "need only follow the relevant hyperlinks".