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.
