Thursday, September 21, 2006

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

Friday, September 08, 2006

Other Side of the Fence

Phew! I've passed the Java certifications in JSP, Servlets and EJB and can now return to the normal way of life using Microsoft technologies to my heart's content. I'm keen to get back to IIS although I wouldn't mind working with some of the J2EE application servers to see value-add features that each vendor has been able to provide (all my exposure so far has been to Sun's bare bones reference implementation). Expect more Microsoft-related posts soon!