Friday September 30, 2005

For some odd reason, long lost in the fuzzy recesses of my memory, I agreed to give a talk last week at Oracle OpenWorld on SOA. It's a topic that I'm not an expert on. There are lots of people around who know far more about it than I do. A lot of my unease about giving the talk was that I was very confused about what SOA is, and that ended up being what I spent most of my hour onstage talking about.

There are a lot of corporations, analysts, consultants, experts, "experts" and pundits saying a lot of things about SOA, without a lot of consistancy about the meaning of the term. When you expand the acronym to "Service Oriented Architecture" you get a pretty good, but broad, picture. The Wikipedia definition is one of the better ones out there. In most descriptions, SOA has become a broad cellectiom of techniques that go far beyond just architecting systems as services. The topic feels a lot like that quote from Through the Looking Glass:

'When I use a word,' Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean--neither more nor less.'
'The question is,' said Alice, 'whether you CAN make words mean so many different things.'
'The question is,' said Humpty Dumpty, 'which is to be master... that's all.'

There is a collection articles that insist that SOA is not OOP (or OOP-ITL [Object Oriented Programming In The Large]). They draw weird distinctions that mostly demonstrate how little they understand of OOP. A common misunderstanding is the belief that everything that can be done to an object must be a method on the object - for example that "play" must be a method on a "MusicCD" object, tying the service to the object. In this example, the right way to have done it is to represent the CD player as an object distinct from the CD itself, which would be played with a statement like "player.play(cd)". OOP is a modeling tool, how you choose to model a situation is a matter of taste, the situation at hand, and engineering judgement.

Then there's the camp that defines SOA as just being the same as OOP. I rather like this because it meshes well with the phrase "Service Oriented Architecture", which is the way that I tend to think of most good OOP designs. Using the previous example, rather than having verbs like "play" be methods on the CD object it's usually better to try to restrict methods to things that are intrinsic to the object. One could argue in this world that perhaps SOA could be thought of as a subset of OOP, since there are many other architectures that can be modeled within OOP.

One of the concepts here that is often not made clear in these discussions is the distinction between a server and a service. A server is an implementation artifact: usually a machine. A service is an abstract concept that may be implemented by some number of servers (perhaps zero, perhaps many). The mapping between services and servers should be dynamic, depending on factors like load and quality of service - implemeted in things like the N1 Service Provisioning System.

The last bit of confusion for me is that in most discussions, SOA is about more than just architecting around services. The "S" in SOA should expand to "Scale", since so much of what is talked about is how to archtect these systems for large scales. Statelessness and idempotence are techniques that have been around for years (both appear, for example, in the design of NFS from 20 years ago) are usually considered key components of SOA architectures.

In the end, there's a big bag of techniques that you may or may not want to use. Whether the collection you need fits someone's definition of SOA shouldn't matter - do what's appropriate. Statelessness and idempotence are tough and only really valuable at high levels of scale. Proper OO structuring is always a good idea.