Principles of Service Design

This is a bit off topic from my UDDI series, but I felt compelled to write something on the subject as I am about to do another seminar that will cover this.  Throughout my seminar (and in my future series on Service Orientation – which may preempt part of the UDDI series) I will be presenting a back to the basics approach the to core design principles that are critical to service design and development.  Even integration efforts rely on these same principles, but they’ve largely been lost in the hype around SOA and Cloud.  Some of this was originally presented at SOA World 2009 in my session What Developers get wrong when they embark on SOA.  Today I’ll just throw out a few and delve into them in later posts.   

When we talk about the design principles behind services what do we really mean?  Do we just make something a SOAP endpoint and we’re all set?  Of course not, yet that is still what many end up doing.  I generally try not to fall too far into the architectural camp (I want to make stuff that actually works after all, not just theories), but we should really pay some attention upfront to what has been written by the this group regarding service design principles.  These are the essence of what a good service is at its core – both technically and functionally.   

Many of the implications of these principles, and more importantly how to observe them, weren’t understood when SOA took off as a buzz word / marketing concept.  Subsequently there were many failed early SOA attempts that stumbled on these very points.  At this point, these principles can really be considered lessons from the trenches (an oddly fitting analogy due to the fact that incorrectly executed SOA or Integration can very closely resemble trench warfare: costly, futile, and slow). 

Well-designed services are:

•  Loosely Coupled
• Autonomous
• Stateless
• Have an explicit contract (that you have a versioning strategy for)
• Compose able
• Discoverable (see, UDDI is involved here after all)

These all sound like reasonable requirements, but they are deceptively simple.  These same concepts apply for EAI as they do for SOA and increasingly as we realize they do for all programming.  My friend Phil Boardman recently pointed out to me: “The message is the Unit of Work”.  This concept has a lot of weight behind it and I think is the icebreaker between the software craftsmanship crowd and the service architecture camp.  Next we’ll explore each of these principles in depth.   

The seminar I am presenting is a four day course focused on BizTalk Server development.  If you’re interested more information can be found at BizTalk Developer Training