Services Really Are All About Interfaces

Steve, I agree that service-oriented programming is absolutely better and more interesting than old-skool interfaces. However, I disagree with you with your analysis. Interface-based programming has never implied binary compatibility. Interfaces are about making guarantees as to the nature of the input and output of a method. Back in the days when men were men and pushed around bits and cobbled together assembly to make things go, the interface was specified soley in documentation. As we got smarter, we invented things like C and header files and compilers to relieve some of the human burden by makeing those interfaces machine readable and machine enforcable. Component technologies like COM, CORBA, and even Java and .NET interfaces are the next evolutionary attempts at the same thing. Binary compatibility just happened to be the way all this was implemented, and it was not without many already mentioned limitations.

When you get down to it, when you call a web service with a certain input, you expect a certain output. Period. You don’t expect that to change. The semantic nature of the input and output is still transmitted via documentation, but the syntactic method of input/output exchange has evolved to utilize flexible, extensible technology, transport-agnostic technology called XML. So instead of things breaking at the slightest change, we get “[stability] in the face of change.”

Bonus for us, because the old way sucked at change; but it is also a heck of a lot easier to implement, not to mention way faster. (No matter how you slice it, a few pointer lookups will always be faster than string manipulation.) The advantages of XML come at the cost of performance and ease-of-implementation. So unless Don Box works some unbelievable magic with Indigo, we can expect to see them both around for a long time.