Services Share Schema and Contract Not Implementations

It hit me like a 10 ton truck, while trying to architect an grid computing framework for Microsoft .NET that will be service-oriented. It is wrong for a client of a service to depend on any behaviour of its own implementation of, for argument’s sake, an input parameter. The initial grid’s design saw heavy usage of the Command pattern to pass not only data but behaviour across the service boundary. It all falls apart however as soon as you have to make the service boundary more explicit (i.e. J2EE servicing .NET clients) – at that point I realized I needed to revisit the four rules for service-orientation. I now know why wsdl.exe generates you a new set of data transfer objects ... and why SOAP defines request and response messages the way it does. And it's all becoming very clear to me, and funnily enough typing this blog reminded me that this was an interview question I was asked over a year ago by Josh! I’m going to stick the four tenets of service orientation on Post-It notes to my monitors.

Boundaries are explicit
Services are autonomous
Services share schema and contract, not class
Service compatibility is based upon policy