Monday, March 24, 2008

A car is a car is a car is a ....

For all practical purposes, a Resource Oriented Architecture (ROA) is a Service Oriented Architecture (SOA) that uses RESTful web services.

The arguments for a difference between ROA and SOA depend upon :-

  • a misreading of SOAs as more than the decomposition of processes to re-useable software services.
  • an assumption that only ROA uses RESTful web services (this is clearly untrue as many SOAs use RESTful web services).
  • an assumption that SOA only uses SOAP / WS-* (this is clearly untrue).
  • there being a fundamental difference between a RPC (Remote Procedure Call) and a RESTful web service (they are instead a specific subclass of RPC).

Whilst I can happily debate the merits of SOA+SOAP vs SOA+REST, I find the repackaging of SOA+REST as ROA both confusing and unhelpful as it does nothing to highlight the differences or similarities.

Renaming an architectural style because of implementation details leads to confusion. Imagine if different names were used for object oriented design (OOD) depending upon which software language was being used. This has all the hallmarks of vendor-led marketing rather than an attempt to move the debate forward in any real sense. I find this disappointing.

My background is in SOA+SOAP and SOA+REST environments and I don't expect REST to be the end of the story. I do not look forward to future debates of the ROA vs SOA vs XOA kind, especially when at the heart of each is the idea of "decomposition of processes as re-useable software services" + implementation detail.

For me, SOAP vs REST is a debate whereas SOA vs SOA is a pointless head banging exercise.

Whilst my local garage might try and convince me that "a BMW is not a car, it's a driving experience", my view is it's a make of car.

6 comments:

Aurélien Pelletier said...

I believe you are confusing RESTful webservice with any use of HTTP+XML. There is much more to it, in particular the resource paradigm, a much more powerfull concept than simple services, hence the name: ROA.

I've just published ten slides on the advantages of ROA, check it out and tell me if you can have those benefits with an SOA.


And there is one more advantage, I did not include it in the slides because it confuse most people. But I know it will raise your curiosity: resources can be designed for serendipitous re-use. This great property is an engine for innovation.


> RESTful web service (they are instead a specific subclass of RPC).
If your web services are a subclass of RPC they are not RESTful.
Rpc is a paragdim that tries to abstract away the network, most rpc solution wants developers to see remote call as if they were local one whereas REST make sure you are aware of the network.

>For me, SOAP vs REST is a debate
SOAP is a protocol, REST an architectural style, the debate is not there. We can have a debate :
- about SOA (the architectural style) vs REST
- about SOA (an architecture, but which one? implemented with SOAP or not? with an ESB or not? ...) vs ROA (the architecture of the Web)
- or about SOAP/WS-* vs HTTP+XML

swardley said...

Hi Aurelien,

I'd ask the question, if you take out the "decomposition of processes to re-useable software services" and RESTful web services out of ROA what am I left with?

I've yet to find anything.

ROA appears to be nothing more than SOA+RESTful web services, everything else is splitting hairs and appears to be argument on definitions and exclusions.

Yes, I tend to shorten RESTful web services to REST (as most people do) and yes REST is a software architecture for accessing services (resources) but then so is SOAP/WS-*. This is immaterial to SOA.

My only objection to using the term ROA rather than SOA+REST, is that SOA+REST is more descriptive of what it is. ROA adds nothing.

Whilst your presentation is very good, it could equally describe a SOA using RESTful web services.

As for the subclass of RPC. Note Fielding never made a distinction between REST and RPC and I suspect for good reasons. At its heart RPC (remote procedure call) is simply a term to describe a technology to allow one system to call a "procedure to execute in another address space". To imply that RESTful web services are not a subclass of RPCs would mean that they do not call a "procedure to execute in another address space". Which of course they do.

There seems to be a lot of window dressing to redefine terms.

Suddenly RESTful web services which do cause "procedure to execute in another address space" are not RPCs.

Suddenly ROA which are "decomposition of processes to re-useable software services" are not SOA.

Suddenly services ("whatever they return") are different from resources.

In my world, I like to keep things simple.

* ROA = SOA + REST.
* RESTful web services are just a subclass of RPCs.
* Resources are just service outputs.

I'd be happy to change my view, but I do need to have someone explain why ROA is not simply the "decomposition of processes to re-useable software services" and RESTful web services.

Aehso said...

> The arguments for a difference between ROA and SOA depend upon :-

> * a misreading of SOAs as more than the decomposition of processes to re-useable software services.

Which definition of SOA you subscribe to?

> * an assumption that only ROA uses RESTful web services (this is clearly untrue as many SOAs use RESTful web services).

I'd argue that ROAs are the subset of SOAs that adhere to the constraints imposed by the REST architectural style. SOAs that employ non uniform interfaces or never use HATEOAS are not ROAs for example.

> * an assumption that SOA only uses SOAP / WS-* (this is clearly untrue).

Agreed. But if SOA endorses non uniform interfaces, stateful coupling of clients and servers etc then it will always be a larger and more unwieldy beast than ROA.

> * there being a fundamental difference between a RPC (Remote Procedure Call) and a RESTful web service (they are instead a specific subclass of RPC).

The issue is not wheter a RESTful web service is a subclass of RPC. The fundamental difference is that RESTful style requires a uniform interface whereas SOAs that encourage definition of RPC interfaces conflict with this constraint. If you throw out the uniform interface constraint then you loose the ability to build network scale caching, layered systems etc (like www)

Timely, have a read of Roy's latest blog piece - http://roy.gbiv.com/untangled/2008/on-software-architecture#more-10

Aurélien Pelletier said...

> I'd ask the question, if you take out the "decomposition of processes to re-useable software services" and RESTful web services out of ROA what am I left with?

Resources with ids, representations and links. All of them non-existent in an SOA world.


"decomposition of processes to re-useable software services" is a fine definition of an SOA. Yes services are about processes, when you design an soa you think about verbs, what can be done with the service and how it will be possible to use it.

When you design an ROA, you don't think about the processes first, you think about names, what is interesting in your system and you give them id, representations and you link them together. This let you design any process on top of your ROA even the one you did not thought about first.

ROA give you less control than an SOA but so much more possibilities for re-use and innovation.

I try not to talk too much about REST, because it's at a very high level of abstraction (above the architecture) and it's polluted by the SOAP vs REST troll. I talk about resources, a different way to design web services and applications.

swardley said...

Hi Aheso,

I'd agree with the OASIS definition for the SOA architectural style as being :"A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations."

I completely agree with you that ROAs are a "subset of SOAs that adhere to the constraints imposed by the REST architectural style."

I also agree that non-uniform interfaces and stateful coupling of clients and servers will always lead to an unwieldy beast.

Finally I'd agree that one of the fundamental differences between a "traditional SOAs using SOAP/WS-*" and REST based SOAs is that the "RESTful style requires a uniform interface".

Thanks also for the link to Roy's latest piece.

My post started as a result of a comment which suggested that many industry figures were arguing that "SOA isn't working and ROA is the future".

The issue here for me, is that ROAs are SOAs and rather than being considered a refinement or possible evolution of thinking, we need to reinvent a new term such as ROA and almost disgard what has been before.

Whilst I find the term SOA+REST more useful and descriptive than ROA, my main objection is to the SOA vs ROA debates.

swardley said...

Hi Aurélien,

Interesting points.

"ids, representations and links." and "designing with nouns (a consequence of uniform interfaces) are simply aspects of RESTful design. I don't see why this is excluded from an SOA?

As for "when you design an ROA, you don't think about the [business] processes first, you think about names", again this is merely the constraint issue of RESTful design. You're still acting on these nouns, just with a more limited vocab.

I certainly understand the benefits and disadvantages of uniform interfaces, but I'm not sure that such a constraint is unique to ROAs and that ROAs are not simply just a "subset of SOAs that adhere to the constraints imposed by the REST architectural style."