Service Oriented Ambiguity Redux

I've been neglecting this blog in favor of my non-tech screeds for far too long now.  When I have posted, I've done so only to point out some particularly interesting (to me) ideas and opinions from others.  It's high time I put something out there that I'm particularly passionate about, so here goes ...

One of the things that has irked me over the past five or so years are the many myths and misconceptions around Service Oriented Architecture (SOA) (or, as Martin Fowler rightly labeled it, Service Oriented Ambiguity).  I'm pretty much in agreement with Fowler (as I usually am) that SOA has long become a hopelessly sprintered term that means everything from "SOAP" to "Business/Technology Organizational Transformation" and should be abandoned to the dustbin of techno history (not necessarily the things people mean when they say "SOA" but simply "SOA" itself).  Still, though the rampant hype has died down and replaced as the buzz word de jour by the equally ambiguous "Cloud Computing", SOA has stuck around.  So I'd like to at least state what it means to me, strictly from an technology architecture perspective.

Generally, I tend to follow Tom Erl's literature when it comes to service orientation, particularly his principles and the manifesto he spearheaded.  It quite literally means that your architecture is built and operates through the consumption and production of services.  Yeah, yeah - services don't necessarily mean web services.  Except that 99.9% of the time they do.  They certainly don't mean just any web services: RPC-based SOAP "services" are too often simply procedure calls wrapped up in http and XML dressing.  RESTful Services tend to be the most pure when they are really RESTful rather than just labeled that way (they all too often degenerate into "returning a bunch of shit wrapped in JSON/XML in response to a random http request").  Of course, the best RESTful services often follow a Resource Oriented Architecture (ROA), which is somewhat different.  REST != SOA.  REST is an architectural style, not an architecture.  Read RESTful Web Services for more details on ROA.  And check out the Web Oriented Architecture (Un)-Manifesto, which is not just about REST, but WOA is to my mind much more interesting than "SOA" ever was.

To get back to the point I'm trying to make, service oriented architecture means that the architecture of the system/platform/application itself is oriented around and talks services internally.  It does not necessarily mean that the system/platform/application exposes services for use by external entities.  You can have an architecture that exposes all kinds of wonderful web services for use by external clients and it might still be an ages-old monolith or a modern and perfectly reasonable component-based model. It's not necessarily service oriented.  I'd call it service exposed.  Likewise, you may expose no interfaces outside of the system itself, or you might publish an RPC API, but the internal architecture itself could still well be service oriented.  The interfaces exposed to the client should be orthogonal to the architecture of the underlying system implementing them.  Now, practically speaking, the two are likely to influence one another strongly, but the point is that they do not have to.

Software as a Service (SaaS) - and its offspring, Platform and Infrastructure as Services - also get intermixed into this equation. SaaS as a term predates SOA by many years but is more popular than ever now, while its much-hyped children, PaaS and IaaS, are even more the rage with Cloud Computing at the forefront.  But each of these qualities of architecture have their own inherent characteristics, many not necessarily the most paramount or even applicable to service orientation (multi-tenancy, availability, scalability).

Too often I see all these architectural characteristics lumped together or used interchangeably and thought that at least for my own clarity, I'd get my 2 cents on the matter down "on record."