01/19/08 :: [SO] Drawing some Conclusions [permalink]
Let's wrap up this otherwise useless REST vs WS-* discussion with some observations.
I started to look at REST more closely last fall when my manager showed me Tim Bray's infamous post on "the end of SOA" which was circulating in my company -with of course the objective to create some doubt about our SOA effort. So I immediately tuned to one of Stefan's presentation on REST to better understand Tim's position and discovered that a debate that I thought was long forgotten was actually picking up steam.
I tried to engage some discussions here and there but got nowhere until it was painful enough to actually get to the point where we could have a discussion, believe me if I had a choice, I would have rather had a polite and constructive discussion.
This pattern has been consistent for the last ten years. When you talk to someone the caliber of Steve, Assaf and probably Tim (though we never inter-acted) you get the "I am never wrong" answer, "it is my way or no way". When I was working at eXcelon in 1999 I met for the first time people like that. I was hired to build a process centric B2B engine in an Object Database company. I was young and naive to think that people would always focus on the problem first and then on how they solve the problem. I wrote a white paper to explain a bit the problem and I used a "pie" chart picture to describe a "3-tiers" system. You have to understand that for a French "tier" means "one-third" and I was really thinking they would find funny that a French guy would use "brie" shapes to represent tiers. Boy oh boy, these guys have no humor, at least not anything close that we can share. But at the end of the day none of these guys understood what "inter-actions" and "peer-to-peer" meant no matter which graphical representation you would use. The paradigm shift from OO to SO and from the database tier to p2p middleware was just too much.
This morning I was reading Rayan Tomayko's essay on Insects and Entropy, and I also observed how the REST community is re-acting (adjust) to the fact they can't rely on a uniform interface as much as they thought they would.
First the re-actions. Wow, the whole REST intelligentsia is (performing its auto critic) saying we need an IDL of some sort :
Assaf, always equal to himself, just as good as in the BPM or JDO days (hold a position until you can't no more):
We do need an IDL, or maybe more than one, I’m not seeing evidence to the contrary.
Stefan leaves us a tiny bit of room to step a toe:
I’m not at all opposed to what Dare is suggesting — but I claim that an Atom service documents and link constructions in HTML GET forms is so wildly different from WSDL, IDL and other description formats for specialized interfaces that calling all of them “a description language” confuses the issue.
REST relies on hypermedia. An Atom service document does, too — WSDL and IDL don’t.
Oohh, WSDL bad, bad WSDL. Ryan of course still gives his last scratch to WSDL while kind of admitting that an IDL of some sort makes sense.
WSDL is basically every bad idea anyone ever had related to service documentation/description, schema, and/or discovery all rolled nicely into a document classified as a "recommendation".
Hey, even Steve leaves the door open enough (see comment 9):
as John explains above, you’d want the language to help define interaction details based firmly on RESTful foundations, rather than focusing on object interfaces, operations, parameters, and inheritance relationships as OMG IDL does.
Guys, at least WSDL can describe inter-actions (Steve?) and participate in "assemblies". Not every IDL can do that. WSDL can also be used to describe the inter-actions of BPEL which now can be viewed as a inter-action oriented programming language. Did that escape you? Is it still escaping you or are you in the "I am never wrong" mode I was referring to earlier?
Now, to Ryan's essay. Ryan's essay is symptomatic to our industry. I wrote my first line of code almost 28 years ago on a TRS-80. You have to realize that at that time in France most people have hardly seen let alone used four operation calculator, so a 16 year old having a personal computer and doing something with it... Ever since that day, I always used coding as a skill like "writing" or "counting", i.e. to solve problems and do things. I don't spend all day counting or figuring out better ways to count. I love to understand and get personal with the problems I am trying to solve.
Ryan's essay is symptomatic to our industry because it represents the strongest beliefs of some developers, and I believe the majority of developers, they are thinking about their skill outside of any problem reference. Their belief is the simpler their skill can be the more widely it can be applied, though everything proves the exact opposite, because people keep re-inventing tools. Ryan's essay wants to lead you to believe that complex skills and approaches leads to solution that don't solve problems and therefore you should seek simple skills and approaches to everything you do. I would agree if Ryan would say simple but not simpler, but this is not what he means, he really means simple as in can be applied anywhere, regardless of the problem.
At the end of the day, what I have witnessed over the last ten years is that most people think they can't deal with complexity, they are afraid of complexity, the way they often deal with complexity is either by being sloppy and massage the code until it does something useful (a.k.a as the Matcuidsu approach) or they take a solution that works somewhere else and apply it to the problem without ever looking at the problem.
I have news for you, when a problem is complex, well the solution is generally complex. Say you want to build a 100-story building. Either the tools are basic (shovel, hammer, ropes, basic materials ...) and it will take you quite some time, or you create complex tools (crane, welder, prefab elements...) and it will take you less time. Duh?
As I mentioned several times, the problem of our industry is that the people that build the tools don't know anything about the buildings, they don't care about it, and they don't want to know about the buildings, they are in love with their tools. Fielding's approach to "understand" the Web is the exception not the norm. See how successful it is? Now the Web is a pretty interesting construction, an enterprise information system is for me a slightly different kind of building, I can use some of the same tools of course, they are tools, but who would think that tools to build information systems from mostly static pages (or pages assembled dynamically from static elements) -i.e. the Web- would work just as well for Enterprise Information Systems. Duh?
So let me generalize my statements:
- Don't generalize from one or two data point (LoL). People that do so are generally wrong. This is true for Ryan's essay or for statements like REST works everywhere or you'll never need an IDL.
- Don't be fooled by the people that never applied their tools to solve your problem. Look for simple tools, not simpler tools. The RESTifarians are still hanging by a thread at the argument, "simpler is better" (they really say "simple is better") and we all know how this is going to end up, so don't hold your breath.
- The more time you spend understanding the problem, the less time it will take you to find the best tools and code a solution for it. Hence, the fundamental role of an architect is to create or simply manage the creation of a global understanding that will enable every workman on the project to execute his or her part the best way possible without creating their own (and possibly diverging) understanding.
- Complexity never goes away no matter how simple the tools you choose. Limiting complexity introduced by the tools is a valuable strategy up to the point where the complexity moves into your implementation
If people were still working on their cars or around the house and in the yard, they would have no problem understanding what I am talking about.