Simon Fell says that he has trouble understanding some of my arguments, in particular this one where I attempt to outline the value of pipe-and-filter style composition over a choreographed solution. Let me elaborate here then.
It’s long been recognized that composition of components is simpler and more tractable when those components share an interface, if only because you can reuse glue code. For example, the code written to late-bind the Unix commands “ls” and “more” into “ls | more”, is split between the stdout-using code of “ls”, the stdin-using code of “more”, and the binding code in the shell that processes “|”. All of that code is reusable in more contexts than piping “ls” into “more”.
My examples were meant to show the strong similarities between Unix style composition, and REST style composition. REST, by itself, supports two styles that I’m familiar with, which I described there; composition-by-URI, and intermediary routing. The latter is more powerful and flexible, but the former easier to use, though at the cost of not being standardized (not that it should …).
From what I can tell, the Web services answer for composition lies with choreography (and some in that thread appear to agree with that). I believe this approach will ultimately fail, and that routing (ala WS-Routing, PEP, Idokorro, KnowNow) will prevail.