TSS Interop Blog: Contract-First or Code-First Design - Part 5

This is the fifth and final of a multi-part series on Web services, in which Ted Neward asserts: "You cannot try to force XML into a "type system" through XSD!" A snippet:
Adrian: I think it's fair to state that it's the exception, rather than the rule, for an organization to use just one language, right? Far more often, many organizations will require a blend a number of different languages, for a lot of different and valid reasons. Some languages (e.g. C#, Java) provide good support for code-first approaches; while others (e.g. C++) do not. It seems inappropriate to place interface specification (and consequently, implementation) in the hands of just one part of the organization (those that use a preferred language). Also, it impairs your ability to redeploy new implementations of services in different languages later on: the new language may generate a different interface contract. Ted: Well, I could take that argument and run with it further, suggesting that it's unfair to place interface specification in the hands of somebody speaking a language (e.g. XML) that doesn't cleanly map to any of the implementation languages, and that you're basically just exacerbating the problem further, not simplifying anything. And while I might challenge the idea that C++ isn't a good language for doing code-first approaches, I won't, since that's not something I have particular facts on at the moment....Frankly, I think if you’re serious about trying to separate implementation from interface, then you have to consider the idea that XML is just a data representation, and not a type system of its own, and that therefore you cannot try to force XML into a “type system” through XSD. And I think the argument about interface and implementation being separated from one another is a red herring–I’ve rarely run into situations where we wanted to have distinctly different implementations to the same interface in a distributed scenario. When dealing with CORBA and RMI and .NET Remoting, that was necessary to facilitate the compiler’s type-checking of the arguments passed in to the remote call, but now we’re in a different space, where we don’t want the tight coupling that the old CORBA/DCOM/RMI-based approaches brought us. If we’re serious about trying to build services that will stand the test of time, we need to take a step away from the old model of object RPC, and go back to the world’s original loosely-coupled technology, that of message-passing.Contract-First or Code-First Design - Part 5