Tim offers some extremely excellent advice (as usual) regarding what really matters when you write your services. If I may paraphrase what he says and perhaps embellish it a bit, starting from the implementation language and generating your contracts from it is just plain wrong, wrong, wrong, at least for systems of any appreciable magnitude, reach, or longevity. Instead, focusing on the contracts first is the way to go. I've written about this for many years now, starting well over a decade ago.
When you start with the code rather than the contract, you are almost certainly going to slip up and allow style or notions or idioms particular to that programming language into your service contract. You might not notice it, or you might notice it but not care. However, the guy on the other side trying to consume your service from a different implementation language for which your style or notions or idioms don't work so well will care.
Last summer a customer told me that he had read and heard my advice about starting with contracts, not code, but that he didn't understand it at all until others from elsewhere in his large corporation started trying to use his contracts to write new services or new service consumers. It wasn't until then, he said, that he was able to see how many idioms and assumptions and implementation details had crept into his contracts. His new approach is to still generate his WSDL contracts from code or IDL, but to then take the generated WSDL and go over it in detail to try to remove all those unwanted assumptions and implementation details. He says this approach results in simpler, cleaner, and much better abstracted service contracts. That result doesn't surprise me at all.
Also, I'd like to add a third piece of advice to Tim's list:
3. "SOA" does not stand for "Special Object Annotations."
Which is better: implementation code polluted with a bunch of weird square bracket annotations that inextricably (and also inexplicably) hard-wire your code to what goes on the wire, or nice, clean service contracts that keep implementation details separate? I prefer the angle brackets to the square ones, thanks.
Comments (1)
But the point is, if the tools are "tight" and produce 100%-pure/standardized/agreed-upon contract, should the developer still need to go and tinker with it?
Angle brackets are for consumption by tools and not humans.
Posted by MS | February 11, 2005 4:23 PM
Posted on February 11, 2005 16:23