Why is the Web Loosely Coupled? A Multi-Faceted Metric for Service Design by Cesare Pautasso and Erik Wilde.
Dom: Just for the records, I have to admit that this paper is clearly amongst my top five for 2009. It’s a paper we can use and cite quite a lot in frame of our web of things projects in order to justify our design choices.
Cesare begins by asking the audience whether WSDL is loosely-coupled? Most people said no which kind of crashed Cesare’s effect (Dom: I guess many people like me pre-read the paper ;-)). Some aspects of WSDL go towards loose-coupling (like the fact that you get language independent) but then it is also not loosely-coupled because for instance there are a million ways to describe operations in a WSDL.
His point is that loose-coupling should be considered as a multifaceted decision where the goal is to find the best-effort solution for your case. Erik goes on talking about the facets they identified such as discovery, identification, binding, platform, interaction, etc. (see the paper for a full list).
Cesare goes on with the first facet: Discovery. Centralized registration is tightly coupled, de-centralized for instance by providing links (Dom: as it is the case for RESTful services) is loosely-coupled. For naming globally unique names are considered to be more loosely-coupled since they do not introduce micro-worlds where names are unique and prevent the need for translation. A platform is loosely coupled if you do not use some abstract and language independent means of describing your functionality. Cesare take the example of using Java only (tightly coupled) vs using WSDL on top of Java (loosely-coupled). Erik talks about models. He says that loose-coupling can be achieved when the model is focusing on what you exchange and on how do you act on it rather than entirely describing the exact semantics of the interchanged data and services.
After describing the facets, Erik and Cesare go on by explaining how they evaluated RESTful HTTP, RPC over HTTP and WS-* / ESB (Enterprise Service Bus). They provide graphs which can be used as a basis to take decision on where to use what technology depending on how important is one facet against another for your own use case. Overall REST wins if all the facets have the same weight for you (Dom: which is unlikely to happen, you should know what’s more important for you!). They explain however that this deeply depends on the particular case.
Erik and Cesare also ask the audience to provide some input on new facets we could think of. I propose considering the “time to first running prototype”, namely the time it takes you to have something running and not too unclean. I also suggest that this could be a nice facet for the world of research where applications need to be designed quickly but still re-usable to some extends. Erik replies that they indeed want to look into more, soft, development-time facets such as ease of development, ease of understanding the system, etc.
Dom:This paper, is a very nice attempt to end the RESTful vs. WS-* (which you could read as X vs. Y) war in terms of loose-coupling since it offers a nice and neutral (although I do know they both like REST very much ;-)) framework to evaluate what technology is best depending on what really matters for you and how much you need your solution to be loosely-coupled. There is no ultimate answer, there are systems you should not use anymore (mainly because they are dead or not supported by any sufficient community, like plain RPC, Remote Procedure Calls) but choosing amongst the still-alive systems is a matter of really evaluating what you need, and this paper can help you towards that goal. In the case of the Web of Things we picked RESTful services but we did this after evaluating the WS-* approach and we also know that in some cases the WS-* approach still makes sense.
Update: the slides of the talk can be found here.
