SOA and REST operate at different levels of architecture

Blogger: Anne Thomas Manes

VP & Research Director

Application Platform Strategies

I often hear questions such as:

If SOA is about "services" and REST is about "resources", aren't they fundamentally different things?

I also often hear the REST proponents claim that SOA is not really an architecture because it does not define specific architectural constraints.

But that's because SOA and REST operate at different levels in the architectural spectrum.

• SOA is an enterprise architectural style that focuses on understanding what services the business needs, rationalizing those services into capabilities, and deciding what software should be implemented to support those capabilities. But it stops at the point of specifying how to go about implementing a capability. It does suggest that the approach taken when implementing the capability should support concepts like loose coupling, interoperability, flexibility, reusability, and evolvability. 

• REST is a software architectural style that can be used to implement those capabilities. If you abide by the constraints defined by the style, your resulting systems should benefit from a number of desirable qualities, such as simplicity, scalability, performance, interoperability, and evolvability.

It should be clear that SOA and REST are complementary.

Mike Glendenning puts it beautifully in this post to the service-orientated-architecture discussion list in Yahoo! Groups.

The language of business design is very much about services, or the three questions of:

1) What will you do for me (the service)?
2) How will this help my business?
3) How much will it cost?

So, we might have marketing services, finance services, HR services,
manufacturing services and customer support services all making up
our business. In choosing service suppliers, you care only
incidentally (through the SLA) about how the service is implemented.
Instead, services are considered as self-contained "black boxes".

Historically, the language of IT has been all about implementation
platforms and technology, with terms such as the mainframe,
client/server, SQL, Java, WSDL, REST and so on. In the context of
trying to design the [whole] business, this is largely irrelevant.

Now, if we can use the same language to talk about the operation of
the business as well as the IT systems then we are in a much better
position to understand and decide what IT systems are needed to
support the business. We can see immediately how these IT systems
will work with the other parts of the organisation to achieve the
aims of the business. And we can use the same methods for evaluating
the financial cost and benefits as we use elsewhere.

The rest of Mike's post is excellent, so I recommend you read it all.

If you're interested in learning more about REST, I highly recommend attending a half-day workshop, REST Easy, that Burton Group's Pete Lacey will be giving at Catalyst next week in San Francisco.

Comments

[Benjamin Carlyle]

If we take 4+1 View architecture as our model, I think you are saying that SOA is the logical view. It decomposes functions from the user perspective, and aligns to how you might compose a requirements specification.

The REST vs SOA argument is perhaps happening in the process view: The view that concentrates on exactly which processes and threads exist in the design and how they communicate with each other.

At this process-view level REST looks like an architectural style, while SOA looks like unconstrained distributed Object-Orientation.

I personally still talk about services in the process view of my REST architecture. I even talk about REST being a constrained form of SOA. An SOA architect might draw a service as a UML class with WSDL-defined methods. I would draw the same service, but I use URL templates with uniform GET/PUT/DELETE methods aggregated under the service to provide service functions.

Benjamin.