Where is Service-Oriented Design?

Home | Blog | CSLA .NET | CSLA Store

28 September 2004

There’s a lot of talk about Service-Oriented Architecture (SOA), and Service-Oriented Programming-related constructs like web services and SOAP. There’s even a

bit of talk about Service-Oriented Analysis. But where’s the discussion of Service-Oriented Design?

<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” /> 

I am quite convinced that service-orientation (SO) is no less of a force than object-orientation (OO). For over 30 years our understanding OO has been evolving and slowly, ever so slowly, gaining mindshare in the industry. I think we can apply a (slightly modified) Grady Booch OO quote to SO as well:   “Let there be no doubt that service-oriented design is fundamentally different than traditional structured or object-oriented design approaches: it requires a different way of thinking about decomposition, and it produces software architectures that are largely outside the realm of the structure or object-oriented design culture.”   The bits in bold are my alterations/additions to this famous quote.   OO includes architecture, analysis, design and programming. Understanding and use of all these components is required to make effective use of OO in an enterprise. Precious few organizations ever pull this off. It requires a major culture and skill shift, which is one key reason why OO is still a popular sideline approach rather than the mainstream approach. (The other key reason is lack of tool support for OO design and programming, but that’s another topic.)   If SO is as big a thing as OO, and I suspect it is, then SO has decades ahead of it on the way to becoming a popular sideline approach for software development. Maybe in that time OO will have become mainstream, but I’m not holding my breath…   As an aside, I very much hope that OOA/D/P do become mainstream at some point. After all, we will need to create services, and a service is just an application with an XML interface (vs HTML or GUI). Creating services requires programming in a more conventional sense, and we’ll end up choosing between data-centric and OO just like today. Personally I really want to see more OO, because I believe it is far superior. But I’m pragmatic enough to know that it is far more likely that services will be created using the same data-centric (Recordset, DataSet, XML document) mindsets that are prevalent today in Windows and Web applications…   In my wilder dreams I envision a new programming language that is specifically geared around the creation of services. It might be neither data-centric nor OO, but rather would directly include language constructs to represent service-oriented concepts. I know Microsoft is grafting some of these concepts into VB and C# through the WSE and Indigo technologies, but that’s like prototyping for something that should come later. Perhaps S#? A language with natural expressions for the ideas inherent in SOA/D/P?   In any case, I am convinced that over the next many years we’ll need to develop SO architecture, analysis, design and programming as disciplines. Processes, techniques and tools will need to be created around all these areas. Perhaps we can do a better job with SO than we did with OO, but that remains to be seen.   But the focus of my question today is this: where is service-oriented design? There’s lots of talk and debate about service-oriented architecture. There’s lots of movement around the creation of technologies (like web services, SOAP and the WS-* stuff) to support service-oriented programming. There’s tiny bits and pieces of discussion about service-oriented analysis. But I have yet to see any serious discussion of service-oriented design.   Service-oriented design is critical. Doing service-oriented programming without service-oriented design is sure to lead to all sorts of unfortunate and unproductive results. Any modern developer knows that you need to translate your architecture into a tactical design for the architecture to be useful. You also know that programming without a design is a sure-fire way to end up with lots of rework and wasted effort.   Service-oriented design isn’t about the enterprise messaging standards, or about the transport protocols (HTTP, MSMQ, Biztalk, etc.). Nor is it about the application of WS-this or WS-that.   Service-oriented design is about the design of service-based applications. It is philosophy. It includes the design of services, service clients and other service-related software constructs. It must focus on concepts like  
  • relationships
  • encapsulation
  • message structures
  • data flow
  • process flow
  • coupling
  • cohesion
  • decomposition
  • functional grouping
  • abstraction
  • the service interface
  • the service implementation
  • granularity
  • shared context
  • and more…
 

Click here for an interesting discussion of procedural vs OO design. I think we need to have a similar discussion around SO design. What is it that makes SO unique and different from procedural/structured and OO design? Intuitively I tend to think that it is unique, but at this point it hasn’t been fleshed out and so we can’t have intelligent or objective discussions about how or when it is different.

  In the end, I think that SO will require a comparable culture and skill shift to OO. In other words, moving to SO from either the procedural/structured or OO worlds will require major cultural and philosophical changes, and substantial retraining and relearning. Does this mean OOA/D/P are dead? Not on your life. Neither are procedural/structured design or programming. Most software today is built using procedural techniques, mixed with half-hearted OO code. As we move (over the next 30 years) toward SO, you can bet that procedural and OO will be along for the ride as well.