I first wrote about service orientation in the opening chapters of Programming Indigo, where I dutifully enumerated Don Box's 4 tenets and explained them in the context of WCF application programming. That was a whole year ago, and there have been many SOA developments since. I've found myself immersed in many service oriented customer projects and I also regularly present on SOA and WCF at code camps and other events around the country. So it's time to start blogging my thoughts on SOA. To kick it off, I'll give you my opinion about where SOA is today.
First, let's dispense of the silly SO vs. SOA acronym argument. Some folks don't feel the term 'architecture' is justified, others do. Why is that? If I may, I'd like to remind everyone that there's a lot of disagreement on what 'architecture' is. If the word architecture makes you think of something very defined and standardized, like an OSI network stack, then I understand your hesitancy because we don't have a general architecture (noun) like that for service orientation yet. But service orientation is certainly an architectural consideration, and an important one at that; any time I architect an enterprise solution I begin by figuring out the boundaries of communication, security, etc. So I personally find the term Service Oriented Architecture perfectly appropriate. Ultimately, I think SOA will win over SO if for no other reason that it's the more catchy acronym.
How far can we advance SOA when it's still the subject of much debate? I liken SOA to a hurricane. Sure, there's a lot of chaos at the edges as debates rage on, both technically and politically motivated. But in the eye of the storm there is calm, because there is general agreement on the spirit of SOA: message-based communication, loose coupling, autonomy of services. SOA is young and will continue to be refined, but it's real enough to talk about meaningfully and put into practice.
To make SOA real and practical for people, we have to go beyond the 4 tenets. At Neudesic, we've been doing a lot of thinking about all things SOA. One very interesting group exercise we went through was to collectively list everything we could think of related to SOA, then categorize the items into first principles, benefits, and best practices. This was very illuminating, and also very surprising. I expected many arguments to arise as part of the process; instead, there was a great deal of consensus and only occasional differences of opinion. I'll share our findings on this in a separate article in the near future.
One recent development that shows SOA is progressing is William Oellermann's Enterprise Service Oriented Maturity Model (ESOMM). ESOMM describes stages an enterprise can go through to more deeply embrace SOA. At the onset, enterprises have casual hosting or consumption of services. By the final stage, enterprise are aggregating and orchestrating services in sophisticated ways.
One thing that's become very clear about SOA is that in an enterprise setting customers need a central way to configure, monitor, and manage those decentralzed services. Enter the Enterprise Service Bus (ESB), which provides just those capabilities. I'm skeptical enterprises will move beyond fringe use of services unless they have the centralized control (or the illusion thereof) an ESB provides. I'm doing a lot of ESB work and will have more to share about that in the future as well.
WCF is obviously a great technology for SOA work, as it was designed with service orientation in mind. As good as WCF is, we could wish for a few more SOA features going forward. Discovery of services, so we no longer need to have addresses in our code or config files. Publish-Subscribe communication over topics. Dynamic reconfiguration of running services. Perhaps we'll see some of these in subsequent versions. If not, the good news is you can build these things yourself here and now without too much trouble on top of WCF.