SOA: One acronym to bind them all?
I must confess that when I first started hearing about Service Oriented Architectures or SOAs, my reaction was "oh brother, here we go again ... more vague mumbling about 'paradigm shifts' by analysts who have predicted 10 of the last 2 revolutions." The definitions one finds didn't inspire confidence ... usually something along the lines of "a SOA is an architecture in which the components are services and the services interact by invoking other services." Sortof begs the question of what a "service" is.
Another thing that did not inspire confidence was that many people who profoundly disagree about lots of other things all seem to agree that Service Oriented Architectures are a Good Thing. If the term is broad enough to include "everything", is it meaningful enough to exclude anything?
I've overcome a good bit of this cynicism lately. Sure, SOA is a kindof fuzzy concept, but after spending much of the last year trying to rigorously define what a Web service really is and is not, I'm more sympathetic to the recursive use of "servce" in these definitions. Likewise, a lot of the discussion blurs the distinction between the definition of SOA and the characteristics of good architectures, service oriented or otherwise. For example, "loosely coupled" and "standards based" are considered two of the pillars of SOA". These seem more like principles of most successful architectures than principles specific to SOA. But there does seem to be a very powerful idea buried down in the current SOA hype: the idea that the central abstraction is this fuzzy thing called "service."
It's hard to define what a "service" is -- it could be some software component written in an OO language and deployed via an application server, or some "glue" exposing a legacy mass of COBOL , or a plain vanilla Web server providing the, uhh, service of serving up documents. But it's a lot less hard to talk about how one invokes a "service" -- you always (I think!) send it messages. So, to implement a "service," take some discrete chunk of functionality and provide a messaging interface to it. All that consumers of the service have to know to use it is the format of the messages they send it and get back from it, the protocol(s) for transmitting the messages, and the "message exchange pattern" of the interaction between the service provider and service consumer. In other words, the critical definition of a service is its interface to its consumers, not any particular characteristic of its design, implementation, deployment, etc. One can develop SOAs with COM, CORBA, BEEP, JMS, proprietary stuff, XML, HTTP, SOAP, and all sorts of combinations of these and many other technologies. One can describe the service interface using some combination of IDL, WSDL, an XML schema language (there are several!), DAML-S or some other ontology language, or if all else fails, a phone conversation.
This, in my mind anyway, explains why so many people who disagree on other things tend to think of their architectures as "service oriented." What they're disagreeing about are things like whether to encapsuate the service invocation messages behind an API or expose the messages directly to the service consumer, whether to handle reliabiility and transaction integrity down in the service infrastructure or up in the application layer, whether to have the service semantics described by human-readable documents or machine-processable ontologies, and so on. But if one looks at the messages, exchange patterns, and data exchanged, a lot of these differences tend to blur into the background.
I think this view of distributed systems architectures helps maintain focus on what is important for scalability, interoperability, evolveability, etc. and prevents us from becoming distracted by extraneous and politically loaded concerns. For example, there is no intrinsic conflict betweeen REST and SOA or SOAP. One can and should debate the specific conditions under which it makes more sense to directly manipulate "resources" by transferring representations of their state using the "services" supplied by HTTP, and when it makes more sense to hide the resources behind a more complex and customized service interface, but let's not call these alternative "paradigms". They're just different flavors of SOA, and developers are free to mix and match them to meet the needs of a distributed application.