What is SOA?
We in the IT industry in very real danger right now of destroying the value of Service Orientation. There is too much assmption that SO(A) is Web Services (WS). In many arenas, you’ll even hear the two terms used almost interchangeably. Many companies and vendors are adding the term SOA into almost every marketing brochure and web page that they own in order to catch onto the coat-tails of this new buzz-term. This is very dangerous for two reasons:
- Nobody has yet clearly and universally defined what SOA is
- By muddying this term with too much spin, we'll loose the essence and value of what we're trying to promote.
SOA… what does it mean? Can you find two definitions that agree? I can’t! Is it Service Oriented Architecture? Applications? Analysis? Aardvaarks? I don’t know and I am pretty sure that there are few others who can successfully elucidate a generally accepted definition. This is why we don’t use the term SOA and opt instead for “Service Orientation” (SO). We’re not trying to change the game here – we’re trying to say what the game is in terms that are relevant to the real-world and can be applied to real problems and situations.
SO is a “pure abstract” design and architectural concept that talks just about the goals we want to achieve when building systems that are less prone to the multitude of issues that plague distributed systems today. These are just a few of the goals that SO is trying to deliver:
- Assume a "Sphere of Control": We need to actively understand what portion of our systems we have control and influence over. We can only control so much, and yet today, we (inadvertantly or deliberately) make all kinds of assumptions and build-in all manner of dependencies around the ability of others to support given protocols, levels of reliability, etc. What if they can't / don't do what we need? Outside our sphere of control, we can trust no-one and should plan accordingly.
- Minimize the impact of choices: Today, we have to make hard decisions around how to achieve the highest levels of performance, security, interoperability, availability, etc., but have to sacrifice too much in order to. We shouldn't have to make so many hard choices. We should be free to architect our systems once and, so long as the design is sound, we should be able to change transports, protocols, security mechanisms, etc., without requiring change to the implementation of a service.
- Interop, Transports and Protocols: "How will we provide access to our <insert platform of choice here> based system from other platforms? Will we provide bridges and translators or dumb-down our systems to the lowest common denominator?" In the future, our systems should be able to expose their capabilities via a number of transports and protocols without requiring code/implementation change, and where possible, requiring little/no administrative effort!
- Autonomy & Coupling: How “independent” are the services within your system? Today we build systems that (despite best efforts) often end up as tightly coupled intertwined complex monsters. We’re aiming to build services that are independent and maintain the data and processes necessary for their successful operation and are yet highly co-operative with other systems in their environment
- Resilience & Availability: How does a system deal with failure, both within its sphere of control and beyond? What happens if a service on which you depend for part of your operations crashes unexpectedly? In SO systems, we aim to be able to gracefully detect and handle such problems in a manner that is recoverable and does not crash our own system.
- Performance: Which parts of which platform should I use in order to achieve the desired levels of performance? If I choose to make my service interoperable, does that mean I have to sacrifice performance? These are the kinds of choices we shouldn’t have to make and ones which will be decreasingly important as platform vendors deliver technologies that make it easier to compose systems built on their platforms.
There are many other such considerations, but it's these kinds of issues that SO aims to resolve. Designing with an SO mindset helps us take fewer limitations introduced by having to make technology/implementation choices too early in the design process by giving us more flexibility and freedom.
SO is all about designing and building distributed, connected systems the right way and the further away from this goal we travel, the less likely it is that we'll arrive at our destination. Let's get back on-track!
