Yaron's Definition of Service Oriented Architecture (SOA): Networked code is good. The rest, as they say, is just commentary.


What Is SOA?

True, "networked code is good" has been understood literally since at least the dawn of modern computing and if I wasn't too lazy I'm sure I could find Sci-Fi examples that predate modern computing. What's changed is that it is now so unbelievably cheap and (cough) easy (cough) to hook remote systems together that it has become possible to change how the average application is written, specifically we can significantly change what re-use means.

Once upon a time 're-using' someone's code meant that you copied their code/function/component/jar file/whatever into your code. But in a networked world re-use means reaching out to another application and using its functionality remotely. Networked re-use is likely to be more successful then the 'code' re-use because, if nothing else, it's easier. Code re-use means having to take someone else's environment and replicating it in your own. With SOA re-use one just has to master the on-the-wire behavior which is a much more limited domain. In addition SOA re-use means that as the dependent service is debugged, expanded, etc. one's own service (cough) automatically (cough) gains the benefits of those changes. I'm not suffering from the illusion that SOA will make re-use easy, just easier.

I don't overly worry about what 'service' in SOA really means. Services, much like resources in HTTP, are in the eye of the beholder. Furthermore I don't accept the view that a service architecture is either new or revolutionary. The idea of breaking chunks of work into pieces and handling those pieces separately isn't exactly new. After all, Dijkstra had a paper on process based computing in 1965 and UNIX had a Fork command by the 1970s. Once you have processes you are well on your way to the concept of a service oriented architecture.

What Isn't SOA?

  • SOA is not HTTP.

  • SOA is not XML.

  • SOA is not REST.

  • SOA is not SOAP.

  • SOA is not WSDL.

  • SOA is not XML Schema.

  • SOA is not Web Services/WS-*.

Various folks for various reasons try to restrict SOA to only consist of their preferred technologies. The RESTafarian crowd would have us believe that 'true' SOA must be REST based and just use HTTP and XML. The Redmondtonians and the Big Blue types would have us believe that SOA has something to do with the billion specifications they are pumping out their network ports as fast as they possible can. But SOA is much bigger than any of these approaches. When WS-* is just a bad memory and HTTP has gone to the great protocol museum in the sky, SOA (under whatever name) will still be around. SOA simply means networking is good and as a consequence re-use is important, what technology is used to achieve networking/re-use is secondary.

Still, there are easy approaches to SOA (HTTP/XML) and unworkably hard counter productive approaches to SOA (WS-*). In my future articles I will explain ways to achieve SOA's goal of networking/re-use that I think are the easiest.