FAQ Entry: What's this REST vs. SOA Debate About?
Question: What’s up with this SOA-vs.-REST thing?
Answer: That’s not an easy question. The reason is that “SOA” is not defined by any single source, so different people mean different things when they use the term. Things are a little different for REST, since it’s coined by a single person and defined in a single paper. To be fair, some people point out that there is often a lot of discussion of what is and what isn’t “RESTful” — I believe those disagreements are at a different level … but let’s just ignore this for now and get back to the original question.
When some people say “SOA”, they talk about an approach to managing, organizing and structuring IT systems in a large enterprise context. Instead of applications, services become the central concept; business and IT are aligned more closely; services are submitted to strong governance processes … whether or not you agree with any of these ideas, you can see that they’re pretty high-level and not concerned with any particular implementation approach. When defined this way, you could implement an SOA approach using CICS and COBOL on a mainframe, C++ and CORBA on Unix, Java/Java EE, .NET or whatever option you prefer. Web services, POX and REST (or rather: RESTful HTTP) are also implementation options from this perspective. At this level, SOA and REST can’t be compared — there at completely different levels of abstraction, and address different problems. Let’s call the level this definition of SOA addresses the business level.
Others view “SOA” much more technically. To them, SOA is the abstract architecture behind the Web services stack (SOAP, WSDL, WS-* etc.). There are service providers that expose services that are described with formal contracts; non-functional aspects are described via policies; there’s a registry that contains service descriptions and is used both at design time and run time; messages, containing documents as a payload, flow from consumers to providers and back … this technical description is not intended to be a definition, because until now there has been no agreement what such a definition could look like. But it’s pretty different from REST, because REST defines some pretty strict constraints — most importantly, a uniform interface, identifiable resources, and hypermedia. There is no similar agreement (a set of constraints) about SOA, which is often criticized by RESTafarians. We can call this level the technical level.
Things often become confusing when one side talks about SOA on the technical level and compares it to REST, pointing out differences and arguing about the respective strengths, and the other side is talking about business level SOA. It is absolutely meaningful to talk about the relative merits of technical level SOA and REST as implementation options for business level SOA.
Isn’t the most significant distinction between “Resource Orientation” vs “Service Orientation”? One asks us to conceptualize distributed software systems as webs of linked “resources” (whatever those are, which is continually debated), and prescribes that they be manipulated with a uniform set of operations. In practice, this means the Web (1.0 anyway). The other asks us to conceptualize systems as interlinked services (whtever they are, which is continually debated) to be invoked and composed with one another. I think Werner Vogels http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=388 has the clearest and most reality-based description of what this means in practice: “For us service orientation means encapsulating the data with the business logic that operates on the data, with the only access through a published service interface. No direct database access is allowed from outside the service, and there’s no data sharing among the services.”
One could presumably implement an ROA with CORBA, WS-, etc. as well as HTTP … and one could presumably implement an SOA with HTTP and URIs rather than WS- , etc.
I don’t necessarily agree that “REST defines some pretty strict constraints — most importantly, a uniform interface, identifiable resources, and hypermedia. There is no similar agreement (a set of constraints) about SOA”. The way I see it, REST prescribes strinct contstraints on the operations used to manipulate resources, but says nothing about the representation of the resources (that is, format of the content at the end of the URIs). Service orientation doesn’t prescribe anything about the set of operations that can comprise a service, but does insist that the service interfaces be rigorously specified — the protocols for invoking the services, and the format of any results returned from the invocation.
Mike, all of this, IMO, puts you firmly in the “technical” camp. Within this, we can debate whether or not ROA or SOA is “better”. But I only wanted to point out that before we have a discussion like this, we need to agree that we are indeed talking at the same level.
I fully agree one could implement REST with Web services, although there’s little point in doing so.
When you write “Service-orientation … does insist that the service interfaces be rigorously specified”, I agree that this would be a reasonable constraint to define “technical” SOA. I just want to point out that there is no single definitive, normative source one could point to that defines this — i.e. there is no document in the SOA space that plays the same role as Fielding’s dissertation does for REST.
I think it’s reasonable to ask “what is SOA?” and get a straightforward answer. That there’s none forthcoming is a concern of mine.
Bill - while I agree, it’s hard to discuss the merits of alternative approaches if “SOA” is simply dismissed because of this.
Given the comments posted today, 28th Sept by Jan Algermissen and myself to the Yahoo “service orientated architecture” list, it would be interesting to know whether you regard the ideas of “hypermedia as the engine of application state” as a business or a technical concept,
I don’t mean to evade the question, but I’d argue this is a case where a technical concept can have business implications.
(Personally, I’m convinced that REST has much greater potential to support new business models than technical SOA because of its support for connecting stuff that wasn’t planned to be connected.)
The way I was raised, SOA was envisioned to federate disparate systems within an enterprise. Step one created a canonical data model, step two created a service layer (resource-oriented or not) to bind those systems into the SOA using old-fashioned integration techniques. Interestingly, the few SOA approaches I’ve been able to look at have leaned toward a resource-oriented approach in the service layer. But in the end, these people had to work with what they’ve had, so the interface wasn’t absolutely uniform. The quality of the uniform interface rests largely on having a well thought-out URI strategy, which is rarely done (yet). Nevertheless, I think debating SOA vs. REST is misleading and an injustice to both.
I actually agree that it should not be SOA vs. REST — I strongly believe that REST is the best (or possibly: least bad) way to achieve high-level SOA goals.