In his imitable style, Rocky weighs in on my recent web services rants:
I think this is all wrong-headed. The idea of being loosely coupled and the idea of being bound by a contract are in direct conflict with each other. If your service only accepts messages conforming to a strict contract (XSD, C#, VB or whatever) then it is impossible to be loosely coupled. Clients that can’t conform to the contract can’t play, and the service can never ever change the contract so it becomes locked in time.
Contract-based thinking was all the rage with COM, and look where it got us. Cool things like DoWork(), DoWork2(), DoWorkEx(), DoWorkEx2() and more.
Is this really the future of services? You gotta be kidding!
Loose coupling isn’t about loosely-bound calls, but there is some common ground, and Rocky, I hate to say it, but if we want to avoid the tight-coupling nature of RPCs, then yes, this is the future of services.
Look, in the beginning, there was a maxim that drove a good deal of how the Internet itself evolved: "Be strict in what you send, be liberal in what you accept." It’s attributed (as best I can ascertain) to the late Jon Postel, who was saying that if we really want this world-wide network thing to work, really work, then we need to get off the lawyering-prone nit-picking your-stuff-put-an-extra-semicolon-where-there’s-not-supposed-to-be-one soapbox and start thinking about ways we can accept data even if it’s not quite perfect.
Look at it this way; dspite th obvius errs n ths sentnc, you stll gt th idea, ya? This is because the human brain is wired in exactly that way: liberal in what it accepts, logically trying to piece together parts into a coherent whole that fits. Is it easier to simply force a strict validation on incoming data? Sure it is, and that’s the default mode issued by most Web services toolkits–"You conform to this schema or the call fails." But what happens when you want to evolve that format later, because one of your clients wants to add some new data that your other clients/partners aren’t prepared to handle? "Um, guys….? Would you mind recompiling against a new WSDL contract, please?" Or maybe, "OK, so we’ve got one endpoint for each of our clients, and now two of them want 7 features, 5 of which are identical but the last two are different. Do we cross-wire URL endpoints back and forth between them, or duplicate the code across two different endpoints, or…?"
Just send me an XML message that (more or less) conforms to a format–whether described by Schema, RelaxNG, or just plain-old-whiteboard-chicken-scratch–and I’ll figure out what to do with it from there. It’s worked thus far for the Internet, and I’m betting that it’s going to take us a lot farther than if we try to create One True Schema that everybody who cares about this service must obey. (Because, as anybody who’s ever tried to develop said schema amongst a collection of partners and vendors knows, it’s almost impossible to get that right the first time, and even more impossible to revise it later.)