SOA for Dummies

Suppose you are a programmer and you have to build a large, complicated application. You have to break up the code into pieces so you can keep everything straight and not get lost. For years, programmers have divided code into interconnected hierarchies of objects, a practice called object-oriented programming. Service Oriented Architecture is an alternative code organization, based on services. For example, you might have a weather service that returns weather conditions, given a city. A service is a chunk of code that has several properties:

1. A service can take requests


2. Given a well-formed request, a service will send a response


3. A service can use other services

Service Oriented Architecture has become a major buzzword in the software design community, and everyone and his code monkey is claiming to use it. So if it doesn’t do what’s promised, a lot of people are going to lose a lot of money.

Many people have noted my interest in software architecture and steered me in the direction of the big new thing, Service Oriented Architecture. I am always bemused by SOA, not least of which is that I can’t help but think that the acronym is unfinished and really needs a “B” on the end.

I am pleased to tell you that SOA really does work, and has been proven to work in the field, under rigourous conditions, by real programmers and not just consultants touting books or neophyte programmers trying to inflate their resumés.

Those of you born after 1980 will be surprised to hear that SOA was first invented in the 1960s. They called in Procedural Programming in those days, and it featured this nifty abstraction where:

1. A procedure can take requests called “Procedure Calls”


2. Given a well-formed request, a procedure will provide a response


3. A procedure can use other procedures

It worked remarkably well, so well that in 1976 or thereabouts, somebody got the bright idea that you should be able to call procedures on other systems, so that a program talking to the user on a system in their office might invoke a procedure on a different computer running a database.

This was called a remote procedure call, a remarkably simple name: you take the name of the thing you already understand and merely explain how it is slightly different.

The industry sliced and diced this idea, reinventing it many times. For example, one company was not satisfied with calling things procedures and remote procedure calls, so it invented the new acronyms COM and DCOM.

I am told that academics have proven that a computer program which prints all of the variations of this idea cannot be proven to halt, possibly because we invent new ones faster than we can list the old ones. But I am quite sure that SOA is nothing more or less than that old idea, wearing new clothes worthy of an emperor.

And when I see criticism of SOA, I am quite sure that it is fully congruent to valid criticism of Procedural Programming. For example, when told that SOA can cause Strange Loops, I think of John Lakos’excellent book Large-Scale C++ Software Design, where he spends 896 pages explaining how to eliminate the loops from large C++ programs for speed of compilation and testability.

Or when told that SOA hides the implementation of services, so that clients cannot be sure when the behaviour of services change, I am reminded of a very old debate about Leaky Abstractions. I do not expect this debate to go away any time soon, even if we discard SOA in favour of the next shiny consulting toy.

Of course, Procedural Programming was supplanted in the mainstream “Blub” community by Object-Oriented Programming. I am not surprised to see that the main opponents of SOA advocate something called “REST.” REST’s chief feature seems to be that it favours decomposing large architectures into a taxonomy of entities with well-defined interfaces (PUT, GET, DELETE, and so forth).

Alphonse Karr said it best:

Plus ça change, plus c’est la même chose.

  ¶ 3:22 PM