The World Wide Web Consortium’s glossary defines SOA as "A set of components which can be invoked, and whose interface descriptions can be published and discovered". Clear as mud? We thought so, too.

To understand the concept, let’s think for a moment how the evolution of software development has progressed over the years. In the beginning were languages like Pascal or C, where the user wrote a text file of code and used a compiler to make a machine-readable version that could be run on the computer. Sensible programmers (and the compiler writers, for that matter) placed commonly-used functions in “libraries” – modules that could be included at will in a developer’s program to save having to write the same lump of code over and over again.

The problem with the traditional model was that a function could only work with data types that it had been written for. So it was no good having (say) a function printAsString() that handled decimal values if you wanted to pass it some wacky user-defined type you’d just invented – you had to add a new function to the library. So some bright spark came up with the idea of an “object” – a collection of stuff that included both the data required to represent that object (“properties”) and the functions (“methods”) used to manipulate that object. This approach removes the vagaries of having to maintain central function libraries – you just include all the necessary code, and no more, in each object’s methods. Most of us now work in an object-oriented world – not just with hardcode programming languages like Java but even with things like PHP and ASP, which are happy to work in an OO way even if you didn’t know it.

OK, to write an OO program you work by instantiating (creating) an object and then using its methods and/or passing it around. Now imagine that instead of that object’s definition being in a code file on the computer you’re writing/running the program on, it’s on some other machine somewhere. So your program says things like: “Hey, machine over there – give me an instance of a BOOKING object, and here’s a CUSTOMER object to relate it to”.

That, in a nutshell, is SOA: a world in which we instantiate and use objects that aren’t necessarily on the same machine. If you think this sounds like a fancy name for a web service, you’re absolutely right – with the caveat that web services are a component of, not a synonym for, SOA.

Taking it a little further If you’ve ever written a web service (try it, it’s very easy – particularly if you’re using something like MS Visual Studio, where making a stand-alone function into a web service is as easy as redeclaring it as a “WebMethod”) you’ll realise that in order to call a service at the server end, the client needs to know where to look. Just as you need to know the URL of a web page in order to view it, so a SOA “consumer” (the thing doing the calling) needs to know the address (usually a URL too, in fact – HTTP is commonly used as the intercommunication protocol) of the service it wants to call.

The reason that web services are merely a subset of SOA is that you don’t really want to hard-wire server addresses into your service calls. Not only might you want to redirect traffic to a different server at some point, but you may even have the ability to provide some kind of load-balancing and thus allow a single application to access the same service on multiple servers. We therefore introduce a mechanism whereby the consumer doesn’t have to care about where to look for the service – it just shouts to the network, or preferably to some kind of “object broker” on the network that it needs a particular object or service, and the latter figures out the best place to get the service from.

And a little further still As we’ve hinted, the protocol of choice for SOA is HTTP – the web transport protocol. It’s simple, well-understood and ubiquitous. Services are described using standards-based mechanisms such as SOAP (the Simple Object Access Protocol) and WSDL (the Web Service Definition Language), which simply involves wrapping stuff up in XML documents and flinging them back and forth over HTTP connections. These mechanisms allow you not only to call services from consumers, but even to ask a server: “Please tell me what services you can provide me with”.

The problem comes with the fact that the web transport protocol (which is allowed through most firewalls) has now met business-critical function calls (which you most certainly don’t want to allow blanket access to). Thus security becomes an issue and you need not just to packet-filter the streams that go through the firewall, but to dig at application level into the XML of the calls that are flying around in order to decide whether a given transfer should be permitted or blocked.

In short To conclude, then, the main component of SOA is an object-based service that allows distributed processing by allowing code on different machines to co-operate and intercommunicate. SOA can exist with just this component in place. In general, though, it will be complemented by auxiliary functions that provide facilities such as load balancing, service discovery (figuring out where you can get services), object brokering/management (optimising access to services once they’ve been found) and application-level firewalling in order to maximise scalability whilst maintaining security.