01/03/08 :: [REST] A Question of Style [permalink]

Steve, I apologize for having offended you personally, I am really to talking to all the would-be RESTifarians WS-Bashers. You have to understand that my style is the result of a few of constraints that you seem to be unaware of, so I'll make them clear here.

Understanding is the engine of Progress

Some people have tried "other" approaches but that does not "scale".

Software Engineering has never made any progress without advances in the understanding of the "environment". Roy's thesis was about understanding the Web, it is no exception. "Understanding" may mean different things to different people, but for a scientist, like me, it means that within the context of my understanding there are no questions that remain unanswered, or at least no questions or fact that invalidate that understanding. If it happens you either have to reduce the context or you have to modify your understanding to be able to answer the questions.

Newton's theories were not invalidated by Einstein, Einstein simply expanded our understanding as the context grew bigger. Understandings overlap just fine. The people that discovered coal and started to use it did not consider global warming as part of their context. Were they wrong? no, for sure, tremendous progress resulted in understanding how to use coal. However, the beliefs of Alchemy have long disappeared overwhelmed by "understanding".

Questions are the only way to validate understanding   

Don't we wish we had asked more questions and got more answers about a lot of things we thought were understood?

Questions based on facts are the only way to validate an understanding. Questions must be welcomed and thoroughly answered before someone can claim having reached the level of "understanding". I know some scientists don't like questions and a lot of people without formal scientific training tend to ask all the right questions. Asking (and answering) questions strengthen understanding and contribute to progress.

All kinds of techniques have been invented to avoid answering questions of course, but unfortunately this is one my strongest constraints, I can't commit to an understanding until I have answered all the questions I can come up with. I surely never leave a question unanswered when I make a recommendation based on some understanding.

Understanding commits resources

People love power but they hate responsibilities

I don't know why you blog and write articles, but when you make a recommendation such as this one you probably expect people will follow it. When you express such understanding, you commit people's time to validate your understanding and when they apply it to solve their own problem, you, yes YOU commit their resources.

Resources are finite

Though most people act as if they were infinite.

IT does not have an infinite amount of resources to fulfill its needs while trying to expand its understanding to better fulfill its needs. If we as a community make mistakes, it has a cost, today and tomorrow. You personally may never be impacted, even if thousands or more, are. That's actually precisely the problem, the people that commit vast amounts of resources on bogus understanding are never impacted themselves by their recommendations. They casually explain "they were wrong" or they conveniently "forgot" their rationale.


When Tim Bray or Mark Baker write something like "the end of SOA" in such abrasive terms they have no idea the amount of resources they are committing in the wake of their statements which are no less than a caricature of "understanding". SOA is hard and unfamiliar, it requires enough change that a lot of people (including vendors) feel threatened by it: will it make them irrelevant? will they learn fast enough to keep their position or market share? 

Do you have any idea how statements made by Tim and relayed with the benevolence of Sun and the RESTifarians at large can make on such a situation? Yes, I think you guys know very well what you are doing -this is why I am so abrasive-. Your tone indicates that you think it is a game, but way too many people have to live with the consequences of your "understanding".

Just imagine for a second the discussion an IT architect can have with his/her manager while reading Tim Bray's (or your) comments on Web Services? Do you think that he or she can raise questions in front of the authority represented by Tim? Do you think he or she is prepared? he or she has any weight? Do you think he or she has any chance facing a WMD such as the post written by Tim? Do you understand why I am so abrasive? Do you understand your responsibilities? 

Jon Bosak expressed very well in the ebXML vs Web Services days that "Business is complicated, any solution that does not reflect this complexity is not a solution". At IBM, it was Marty Sacks who was doing the same thing. Did we listen to them? No, the industry rather responded to the "abrasion" of Don Box et al who were swaying people with "WSDL, SOAP and UDDI is all you'll ever need" and went on re-inventing most of the ebXML concepts and locked-down inter-actions as much as they could. Now that we have re-invented everything, the RESTifarians come in and want us to start over. You must be joking. Just give me a reason why?

Steve, at the end of the day, I have nothing against REST of course, REST is a great technology that is experiencing a well deserved success (Though AJAX shows that this is not an end-all be-all technology even at the presentation layer). I simply find the RESTifarians' attitude irresponsible. Talking with Stu, it became clear that he understood the questions and he was trying to find genuine solutions (outside WS-*) as we were discussing, but at least he was acknowledging the problems. Bill de Hora just walked away. Stefan always stopped the discussion at every single issue that REST would face.

To be very clear, Steve, I directly challenge some of the most profound beliefs you have expressed in this article in the context of resource-to-resource inter-actions (I have expressed many times that in the context of human-browser-server interactions what you are saying is valid - I have actually demonstrated why it was valid):

A significant advantage of the uniform interface constraint lies in the area of scalability. For a client to correctly interact with a SOA service, it must understand the specifics of both that service’s interface contract and data contract. But for a client to invoke a REST service, it must understand only that service’s specific data contract: the interface contract is uniform for all services. I can’t overstate this difference’s impact on large-scale systems.

Ironically, the fact that SOA prescribes specific interface contracts actually undermines its goal of splitting interface from implementation because specific interfaces tend to reveal more about underlying implementations than do generic interfaces. Moreover, specific interfaces — by definition — constrain their implementations because varying them often requires interface changes.

I explained in this post that "actions" (and events) are inherent to the concept of resource. It is not like someone can sit down and decide "interfaces" don't exist, the reason is because you need a way to express and create a shared understanding of the "inter-actions" between a resource and its environment. A resource is not always a self standing piece of inert information, say like a web page. You can decide how you marshal actions at the middleware level using a uniform interface (as you know there are many to choose from), but actions and events will still remain actions and events and represent a core factoring of the implementation.

Your statements could not be more fallacious (again in the context resource-resource interactions): you are recommending to replace a bad coupling by a terrible coupling as I explained in this post (REST Creates a Strong Coupling).

Your response to my first point was that: actions and events are "irrelevant" (for whatever it means) and you did not answer the second point. I will let anyone read your article and my posts and come to their own conclusion. They are actually rather trivial to make. This is why I show so much confidence in my "understanding".

At the end of the day, Steve, you have tried to "remote" everything and came to the conclusion, gosh RPC does not work, CORBA does not work, my narrow <understanding/> of Web Services does not work, so why don't we proclaim that "application semantics" are irrelevant (you just need a "data contract") and voila, you won't be wrong this time since REST is pushing the responsibility of remoting something back to the implementers. If something bad happens it will be their fault.

You are a "distributed systems" guy, I am a "connected systems" guy. The difference between you and me is that I don't do remoting, I have understood a long time ago that inter-actions are the only thing which are worth going through the wires, not RPCs, not method calls... only inter-actions. But for you they are "irrelevant" you are just interested in the wires and HTTP is just a wire, you don't care what goes over the wire.

The problem is that your recommendation amounts to stepping back to the mid 70s when all application semantics were hand coded point-to-point without the automation brought by RPC, CORBA, Web Services... IT does not need that. The difference between REST and "remoting" that you seem to ignore is that REST assumed an application model (HTTP is an application protocol) and built the middleware layer for this application model. Unfortunately, even though the Web application model is very good and quite useful for a lot of applications, it is not a good fit in the context of "Enterprise Information Systems", in particular it can't deal with peer-to-peer inter-actions. You code like me, so we both know we can code anything we want. This is not the problem.

The problem today, as you eloquently said, is: the boundary of the enterprise is changing rapidly and constantly. How do you create a programming model and an information system architecture that supports these changes? You are far, very far from the answer. So don't drag anyone with you, and stop FUDding us with "The End of SOA" crap, this is why I feel ok with my "style", it is the reflection of your own style and attitude. You guys have gone way too far in your statements, you are impacting way too many architects and SOA projects, this is my re-action whether you like it or not. These questions will come back at you over and over each time you guys will want to bash WS, I don't think we'll see much more bashing actually.

 

|