A few years ago I architected a system that used a web service that was accessed by different web based and smart clients. At some point I needed to produce architectural documentation and liberally sprinkled the document with buzzwords and acronyms - one of those being SOA. My work was done - the reference to being Service Oriented made it so.
Admittedly I didn't really understand what SOA was and I will boldly admit that I still don't - at least not in terms that others may agree with. There are a few development people, such as Udi Dahan who really understand SOA. Others that tell you they understand are (mostly) either narcissists or people trying to sell you something (expensive). After all, SOA is needed by Enterprises and Enterprises need big shiny expensive SOA stuff to sit in a server room next to all their other big shiny expensive stuff.
So bear with me for a few minutes as someone who may be ignorant about SOA, but is at least not trying to sell you something. Getting a definition about SOA nailed down is a bit tough as there seems to be little agreement, so I won't try and reference any authoritative source. So let's say for simplicity that SOA is:
An architectural approach to building systems that use a collection of loosely coupled, distributed services
That's more of a techie description, but there is something about SOA that is often overlooked -
SOA serves the needs of, and is driven by, business - the services are arranged around the business processes that require the technology.
Let me clarify the last point. There is very little new thinking in the SOA technology stack - loose coupling, services, endpoints, service busses, distributed computing, long running transactions - these are all technologies, solutions and patterns that we have dealt with in the past. We may not use them much but huge chunks of the technical problem have been solved. SOA allows us the opportunity to brush of the dusty manuals and spruce up the technology stack by putting lipstick on a bulldog, pig or whatever the current fashionable thing is to put lipstick on. To me, it is not about the availability of new technology which is driving SOA, although bandwidth ubiquity helps, but the desire by business to create processes that give them independence from technology limitations. Not limitations in a sense that you can't connect system A to system B, but limitations that prevent business responding to the market by being shackled with long development times, vendor lock-in, proprietary interfaces and so on . Think for a moment of all the potential opportunities in these sudden difficult financial times... if it takes your IT department a year to build the system for the product that you envisage you will miss the market and lose the opportunity altogether.
Moving on from the 'business driver' rhetoric (we can leave that up to sales people and other consultants), let me ask developers and architects out there a difficult question.
Do you know how to build a system that is massively distributed, loosely coupled, fault tolerant, available and supporting of long running transactions?
The short answer is a resounding NO. I know that there will be one guy (or girl) out there and comment to the post saying yes, but he is in the minority and his narcissism stopped him from reading this far down the page anyway. Most developers and architects don't actually know how to code up an SOA system. I have reached this understanding by looking at the type of work that people are doing, so lets go through some of them and see if you recognise the type of work that you do:
- Most developers working in a Web-Server-Database are not building loosely coupled systems. I am not referring to the loosely coupled TTD, mockable classes being produced, but loosely coupled from a more enterprisey point of view. The loose coupling in SOA refers to loosely coupled systems, not tiers or layers. Most projects build a single system, with a few external interfaces, to perform a fairly narrow range of functions, rather than building a whole lot of systems that need to work together.
- Most systems that developers are working on are not massively distributed. The ability to scale out a web server using IIS doesn't make a system massively distributed and we can (mostly) get away with it because of the stateless nature of the web anyway. Have a look around the current thinking around using message based architectures for cache expiry in web farms to get some idea of the complexities involved.
- Most developers have not had to build fault tolerant systems. If something happens the user goes back to the home page and must start a transaction again - no big deal apparently.
- Most systems that people are working on involve short transactions, in most cases taking under a second, with a narrow transaction scope that only extends to their own system. Even where there is a possibility of transactions being long (such as including fulfillment as part of the transaction), they are purposefully kept short, with human intervention required to keep them going or roll them back.
The reason why we are not doing SOA development is because we are not really asked to. There is a latency between business drivers and delivered projects. The business needs to ask for things in a way that the enterprise architect will react to - and we all know how long it takes for an enterprise architecture vision to filter down to the systems. Obviously the big IT vendors rode on the back of SOA hype a while ago and seem to have all sorts of offerings that implement SOA. It turns out that most of the early pushers of SOA solutions have actually selling POWA (Plain Old Web Services) or enterprise infrastructure products that by their very nature have a lot of the required elements. This does not mean that there isn't something there - vendors such as IBM must surely know a thing or two about services and distributed computing (although they probably fall short on being loosely coupled).
Microsoft has taken some flak for not banging the SOA drum as loudly as others, seeming to talk more about Software as Service, which is more aligned to their offerings. They have however been gradually providing the tools that we need to build SOA systems. After all, it is the developers who need to build the systems that make up the delivery of SOA and we need to be tooled up to do it. Unfortunately the base technologies that we have been given have not been taken up by developers - there are so many other shiny new things to grab our attention. Windows Workflow Foundation (WF) came out with .net 3 but hasn't had as much airtime as its sexier cousin Windows Presentation Foundation (WPF). SQL Service Broker is under used and even Biztalk is not given a consideration by most developers - being relegated to being simply for integration.
These, and other, technologies that seem to sit in the background and barely make a 10 point font in presentations are the enablers to SOA. Developers need to begin to understand what SOA is driving and how they can pick up the tools and skills to be in a position to deliver. In my next post I'll describe the trigger for this post and speculate on some of the technologies currently in the Microsoft stack as well as those on the horizon and how developers can start thinking about them in an SOA world.
SOA itself may just be hype, and could disappear as part of computing history - but the patterns and styles of systems that will be built under the SOA banner will not only stay around but be around for a while. So maybe it is prudent to be able to code SOA.
Simon Munro