12/19/07 :: [REST] REST CREATES STRONG COUPLING [permalink]

Well I got what I was asking for: answers and more. Tim Bray threatened to loose his cool. With all this attention, it is time to make the final argument on REST. I was originally planning to write it in an article, but I would like to write a very short summary of this article here to keep the conversation going. The article is about Revisiting Loose Coupling in 2007.

Before I start, I would like to reiterate that unlike Stu says, I am not against REST. I am a REST + WS-* guy (not a REST | WS-*). I also want to reiterate that have no emotional or financial links to WS-*. I was originally an ebXML guy and believed that it could do a lot of good in the world. Microsoft (later helped of IBM and others) had the great idea to set out to kill ebXML by launching the only 3 standards "you'll ever need": WSDL, SOAP, UDDI. We all know the end of the story: WS-* was completed in 2007, 6 years after ebXML had pretty much delivered a similar (and somewhat more innovative) stack. If you have any doubt about Microsoft's motivation with respect to ebXML, I would recommend that you read this report from John Markoff, correspondent of the NY times in the Silicon Valley. It should echo well with what happened this year at ISO in relation to the Office Format. Note that Microsoft was not alone in wanting to kill ebXML. Ismael Gallimi and Assaf Arkin wanted to do the same with a glass of WSCI.

My issue with the RESTifarians is that they are attempting to do the same coup "All you'll ever need is REST", of course now APP creeps in, and Harry Pierson (alias DevHawk) explains how to add some durability to REST. Harry is funny: he seems to have forgotten that if we are where we are today with WS-* it is 80% the responsibility of Microsoft. I am glad you guys are disillusioned by your own product strategy -I think a lot of people are too. So now, that we have a stack that kinds of works, I would like to avoid the ebXML syndrome and have to throw it all away because some people are on a "mission".

Stu gave me his answer to the most important question: is a uniform interface enough? can we do without additional operations in the contract? Stu agrees with my argument (?). He then continues on by saying that WS-* (which includes SCA for me) is not going to do it. I think I disagree with this point and I will give my answer in the article. He however finishes this discussion by saying:

due to the uniformity constraint, RESTful services naturally have a lot more loose coupling between service implementations than if we defined our own semantic community for service interfaces that include actions unique to a particular business domain.

Stu, I may misunderstand your point but you seem to say that one thing (we need actions) and the opposite (a uniform interface gives more loose coupling, therefore don't use actions). Anyways, it is not too important, I really want to comment on that point tonight: loose coupling and REST. Hopefully, we can all agree after this discussion about a number of things.

1. Defining Loose-coupling

The goal of loose–coupling is to create autonomous components that are modular enough that they can be composed into different solutions. These components should be able to evolve (to a certain degree) without breaking the solutions that rely on them. Finally, components should allow for a certain degree of variability, i.e. they can participate in more than one type of solutions, and at least in more than one solution.

This leads to the four tenets of loose-coupling:

  • Autonomy
  • Modularity
  • Evolvability
  • Variability


2. Visualizing Loose-Coupling

(Please click on the picture to magnify)

This picture represents that loose-coupling is about making two (or more) pieces of code interact with each other by achieving these properties:

  • either the consumer or the provider can operate without each other using independent technologies and can be developed at different time by different groups of people
  • they can be composed together to perform collaboratively one or more units of work well after they were implemented
  • they can be evolved independently of each other to a certain degree
  • they can each participate more than one solution, together or separately

The picture represents a provider and a consumer. They are both peers, the consumer is  the one who initiates the interaction. They have both been implemented at a different time (a mash up is a typical example). Because they have both been developed at a different time, they both assume an "internal" representation of the other side. This is their view of the interaction. Ci is the consumer internal interface and Pi the provider's one. Since they are developed independently we can never assume that Pi = Ci. So architecturally we introduce a second set of interfaces: the external ones: Ce and Pe. These interfaces are isomorphic and are defined to work together, at t=0, Ce = Pe.

Now, there is a bunch of things that happens to achieve loose-coupling (LC) within the consumer and the provider to bridge Pi with Pe and Ci with Ce. This is represented by LCc and LCp (LC = Loose coupling). Note that in this picture "loose-coupling" is achieved on the edges. I like this model better, but nothing says it could not be centralized. Loose-coupling is really achieved when LCc and LCp are achieved with minimal effort. Tools are good, but code is cool too, it just has to be as painless as possible (compared to going back to the implementation of the component and modify Ci and Pi to match with each other).

3. How do the different technologies achieve loose-coupling?

So now, that we have a model to achieve loose coupling, let's do a little bit of investigation.

  • Loose coupling and CORBA: CORBA implies that Ci = Pi, so no wonder, this is probably the highest level of coupling you can imagine (Actually RMI is the strongest since you don't have the platform independence). Yeah... CORBA is bad - let me get a round of applause.
  • Loose coupling and REST: the argument is more subtle. Let's start with the case when a human is in the loop. In that case (think mashup), Pi is actually running in the consumer, so this is the lowest degree of loose coupling you could ever achieve. Yeah... REST is good, let me get a second round of applause. (RESTifarians are cheering in the background).

    Let's look at the case when no human is in the loop. So what REST means is that Ce = Pe (Whatever the component is). This is super loose coupling: you can connect any component to any component, they can talk. (RESTifarians smiling). Ah... wait a minute, what happens to Ci and Pi in REST? well they are undefined. You mean that if I change the implementation, I can't really test that Pi or Ci has not been impacted? Hum.. so how does a REST implementation work then? In effect Pi and Ci exist (no matter what, you can't write the implementation without an understanding of the other side's behavior), this is what Stu agrees too, but Pi and Ci are not explicit in any way.

    So, NO Stu, RESTful Web Services indeed offer a coupling worse than CORBA, much worse, because at least with CORBA you have an explicit interface to re-write the implementation on the opposite side. So in REST, if Pi changes, someone has to communicate to the other side (pick your method: email, blog, telephone, SMS...) what has changed. But again there is no machine readable way to do that. Worse of the worst, you can't test the two components independently because there is nothing to test against, you have to test the two implementations together. You can't version, because there is nothing to version. Even wors-er than worse, you have to code and recode standard application semantics such as actions and events protocols on top of the uniform interface. For crying out loud, when will you put your glasses on? REST is the absolute worst technology to develop loosely-coupled distributed components. (and Don, XQuery + XML is no better). As a matter of fact, thinking that any uniform interface is going to do the job is the biggest fallacy of the decade. Eliminating Pi and Ci is the worst architectural choice you can make. It means a) your implementation is directly wired at the Pe and Ce levels and b) you constantly rewrite application semantics protocols on top of this uniform interface. REST gave you the false impression that it worked when a user was in the loop because Ci(Pi) could be constructed mechanically without effort. (RESTifarians crying, loosing their temper, cursing me, vowing to burn the heretic). Guy, this is no heresy, this is a fact and you know, facts are stubborn: our world is made up of actions, it is not "uniform".
  • Loose-coupling and Web Services: if all you do in your day to day activities is to use WS-* like CORBA, or if all you understood when you read the WS-* specs was <CORBA/> please go back to bullet 1). If however, you want to spend some time understanding what XML, XSD, WSDL, SCA, BEPL, WS-CDL (and ebBP), WS-TX(and WS-CAF), WS-Security, WS-Eventing... are about and can help you minimize LCc and LCp, please read my article in January.

4. Conclusion

So where does this leaves us? I hope that by now the RESTifarians will leave the REST of the world alone. They will understand that they have a lot of work to do, very hard work (not just to establish a robust communication infrastructure), to come even close to what WS-* has to offer today (not tomorrow, not in ten years). I stand by my arguments, now: shoot or shut up.

I have a simple solution for you, it is not perfect, but I can live with it, and I am sure a lot of the common folks like me who are trying to do their job day in and day out will agree. This solution is called REST+WS*. I will detail it in my paper early January (Stu I will also respond on choreography -I am not caught up on choreography, choreography is just another way to express Pe and Ce in a single artifact. It also adds some sequencing of operation compared to WSDL alone).

A word for Tim. Tim I actually don't mind if you loose your temper, if you had any idea of the magnitude of the FUD created by the kind of crap your are saying these days, you probably would think twice about saying what you are saying. I respect your contribution to XML immensely, but I am very sorry to read the kind of things you have been writing lately.