(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Friday, August 31, 2007
  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.
—The War on Bullshit, Service Oriented Architecture is your Ticket to Hell

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.

Comments on “SOA for Dummies:
Ok - so that last bit has SOA as procedural programming and REST style as OOP. I think there are people who take that tack - but the strong preponderance of the REST/SOA (and really it's more of a REST/SOAP or REST/WS-* or REST/XML-RPC) argument is that web based protocols might as well take advantage of the way the web works.

Using SOAP or XML-RPC for instance: the network stuff is abstracted away and the goal is to make it just a function call as though it were a native function in the language of choice. And I can see why this seems a tempting and worthy goal.

With REST api's we basically make stuff work like the web.

So instead of calling a function with arguments like XMLRPC.foo(id,arg1) we do a GET on a url like /myservice/foo/id?arg1=x and it returns data - maybe xml, maybe json, maybe even html or plain text. The point is - the URI's are the interesting things and we can do the things to them on the client side that we do with the rest of the web - bookmark , hand edit (look at /myservice/ to see what other urls are available), etc.

And on the server side we have a lot of expertise and implementations of things built into the HTTP protocol (caching, content negotiation, and so on) that otherwise get re-implemented or exposed at the API or even application level.

I'm not a REST guru. I have found reading people like Ryan Tomayko useful on the whole REST idea though...
SOA is fundamentally different from procedure calls. When I execute a procedure call within a program, I have an implicit assumption that the procedure call will at least get a chance to execute. The message to the procedure won't get lost before it's executed, or the procedure won't simply cease to exist.

The elephant in the room with SOAs is the fragility of the system. As long as everything is up and running, life is good: but I've seen SOA systems which just assume the service call will always work.

As Mike Nygard* puts it: "Every system your program interacts with will, at some point, try to kill your program." Each service in the SOA is a system.

This all said, I think that SOA is the best enterprise architecture solution I've ever seen, simply because it maximizes reusability of produced functionality.

* http://www.nofluffjuststuff.com/speaker_view.jsp?speakerId=5145
I think that SOA is the best enterprise architecture solution I've ever seen

As long as we don't confuse enterprise architecture solutions with enterprise architectures, that is fine with me.

Because SOA is not an architecture any more than J2EE is an architecture or client-server is an architecture. These things are technology stacks.

But then again, I'm a Not So Big guy, not an Enterprisey Buzzword-Enabled guy.
I suppose the first point to make is that SOA is meaningless, you have to use other words to explain what you really mean. See Fowler's post on Service Oriented Ambiguity.

I think the second point to make is that it is really as robert points out: SOA is about reusing a running instance system, as opposed to reusing a program. This tends to lead to a dependency nightmare, which I have called "Service Oriented Gridlock."

My third point is that there is something good about SOA- it tends to encourage applications to think about what sort of APIs they could provide.

The final point to note is that CIO's and other tech execs have been unusually successful pitching SOA projects at companies whose core business is not technology. I think it has something to do with term service, and that the core business wants IT to "serve" them.

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /