Service Oriented Architecture (SOA) - what’s the point?
Of all the questions I get asked these days, the most often asked and most difficult to answer is perhaps “What is SOA?”. There are many reasons for this, principle amongst them being that Service Oriented Architecture is such a bad name. It isn’t really an Architecture, Oriented means online “Aligned with” so doesn’t tell us much and Service is such an overloaded term that no two people really ever have the same understanding of what it does mean. I will expand on this issue at another time however, at the moment I wish to write about what I think ought to be the most asked question, which is “Why should I care what SOA is?”.
I find it interesting that when I ask people, “What is the point of SOA; what are we trying to achieve with it?” the answers that I get are generally along the lines of better interoperability. I couldn’t disagree more. I have been told be many that should know better that SOA is a new thing and the Web Services are absolutely fundamental requirements for it. Perhaps the prevalence of this point of view is what leads to the belief that it is all about interop. If you subscribe to this point of view, I would like you to imagine an IT shop that is entirely Microsoft or entirely a specific flavor of Unix and does no electronic business with other companies. There is absolutely no need for interop in such a mythical shop but would there still be a benefit to be reaped from SOA? I believe so.
I think of SOA as a paradigm, a way of thinking about the interaction between component parts of a system, in the same manner as OO but with a completely different perspective. Instead of imagining discrete bundles of both data and operations as “Objects” that know how to do things to themselves, we are breaking the solution down as a set of “Services” that know how to understand “Messages” and do something useful with them. The separation of data from the operations performed on that data is key here and it is not new at all. Let’s explore for a moment the “Four Tenets of SOA” as proposed by Don Box:
- Boundaries are Explicit
- Services are Autonomous
- Services share Schema and Contract, not Class
- Compatibility is based upon Policy
The first Tenet states that the author of the each service defines exactly what messages it will and will not react to and the only interfaces available to send or receive these messages are those defined by the author. The second explains that these services are not subservient to other code, this is to say that a service reacts to a message – how that message was created and what will happen to any response the service creates is immaterial to the action that this service will take. The third Tenet states simply only messages pass from service to service, code does not and that these messages are not random but a sequence of one or more that have been agreed upon. Note that Schema mentioned in this Tenet does not necessarily imply XML Schema, merely that the message format is explicitly defined. The fourth is interesting; we are saying that each Service has a set of Policies that it expects to operate under and it is not prepared to operate unless these Policies are satisfied (a policy might be: I will except messages from any source, but if the message is not from my subnet then it must be signed and the only signature I will accept is X509). Of course this has always been true because systems are always designed such that individual parts work together under a set of policies, but usually these policies are implicit (I will do xyz for any component that calls my interface using C notation and send me two integers with in the range I can handle) - Tenet 4 implies, although doesn’t actually state, that this should be explicit and further more if it is both explicit and machine readable then truly great things can come of it, but that is for a future blog.
Many of us have built systems that comply with all of the above Tenets long before XML and Web Services where ever thought of so very clearly this is not a new thing. All that said, I do think that Web Services, XML Data, XML Schema and the WS-* protocols bring an ideal environment in which SOA may flourish. For whatever reason, XML has become the de facto standard for sharing data across system boundaries, XML Schema allows these “Messages” to be described in a language independent manner and the WS-* protocols provide an excellent opportunity to make Policy both explicit and machine readable - I think this is the driving force behind the resurgence of SOA.
So I have covered a lot of ground about what SOA is and what it isn’t, but I still haven’t said why I think it is important. All this stems from what I believe is the actual goal of SOA. It isn’t interop; if that is all you want then sprinkle a few Web Service interfaces on your existing design and you will have opened up your application to all platforms - but you will not necessarily have benefited from SOA. The whole reason for doing this in my opinion is to be able to Manage Complexity. Note that I didn’t say reduce complexity. Actually I believe a well designed Service Oriented system may well be more complex than it might otherwise be, but what it will be is manageable.
Because of the Autonomous nature of the Services, because of their Explicit Boundaries and because the Message Flow is defined by Schema and Contract, component parts can be moved, augmented or even replaced as the needs of the organization change. If the Policy is explicit then the impact of these changes can be readily assessed and indeed if it is machine readable then a toolset can be develop to ensure it is done consistently and correctly – that I do not mistakenly attempt to hookup a component to another that can not understand its messages, or run a component service in an environment under which it can not operate.
Lofty goals? Perhaps, but achievable I think – at least they will be if we know what we are trying to achieve.