ROA (REST Oriented Architecture) is just a fancy name for a SOA (Service Based Architecture) using REST services.
The main advantage of SOAP-based SOA over ROA is the more mature tool support; however, this could change over time. Another SOA advantages include the type-safety of XML requests (for responses, ROA can also use XML if the developers desire it).
The main advantage of ROA is ease of implementation, agility of the design, and the lightweight approach to things. In a way, SOA and SOAP is for people in business suits; that's what you'll find used in the banking and finance industries. Conversely, somebody that needs something up-and-running quickly, with good performance and low overhead, is often better off using REST and ROA.
For example, when explaining why they chose REST over SOAP, Yahoo! people write that they "believe REST has a lower barrier to entry, is easier to use than SOAP, and is entirely sufficient for [Yahoo's] services" (Yahoo! Developer Network FAQ, as of February 2008). This is true not only of REST vs. SOAP but also of ROA vs. SOA in general.
Another advantage of REST lies with performance: with better cache support, lightweight requests and responses, and easier response parsing, REST allows for nimbler clients and servers, and reduces network traffic, too.
As REST matures, expect it to become better understood and more popular even in more conservative industries.
A few words on hype vs. reality. In the comments below, I've linked to Pete Lacey's excellent criticism of SOAP, "The S Stands for Simple". And here's another one, by Alex Bell, published in Communications of the ACM (vol. 51, no. 10, October '08): "DOA with SOA".
13 comments:
Hello Doctor,
That was a nice article. But with all due respect I do not concur with you first statement that ROA is SOA with REST services.
ROA and SOA represent 2 different architectural styles. In SOA "service" or the "verb" is given importance and it is on the basis of these verbs that the services are designed and organized.
In ROA or resource-oriented architecture, the importance is given to the resource. In this case the entities or "nouns" are given importance and services are organized giving importance to resources.
REST is an architectural style or a design pattern which can be incorporated by using SOAP too. We cannot say SOAP-based SOA either as SOA is an architecture or a blueprint for us which we implement by any of the relevant technology (not just SOAP).
Hello Shruti,
Indeed, it is also possible to view SOA and ROA as (different) architectural styles, and some prefer that approach.
In many ways, I think the best acronym for SOA is "Shame On Analysts", who had been pushing this stuff for years now, with little justification in many cases. Now they're making up terms like "SOA 2.0" to further push... what? Unjustified mess?
A good related reading is "The S Stands for Simple".
So, in most scenarios, REST is clearly better than SOAP (in my humble opinion), but does this mean ROA is any better than SOA? Is it really different, deep inside? Only time will tell, I think.
I think there is one additional distinguising characteric of SOAP based services versus REST. SOAP has a fairly robust body of emerging standards for QoS, the WS-* standards. If these need to be supported in REST it will be a custom solution.
Hi Josette,
All those WS-* standards are both a blessing and a curse. A blessing, because they show what can be done, and how. A curse, because not all are implemented, not all are fully supported, and some implementations are incompatible.
The most important point is this: most applications don't need even a fraction of all those WS-* standards, and are better off rolling their own simpler, easier solutions. Yes, there are exceptions; I wouldn't use roll-your-own for banking-level-critical issues. (And for the record, I dealt with SOAP/SOA implementations in banks.) But most web service usage scenarios are so much simpler; connecting legacy systems to new ones, joining heterogenous systems after an acquisition, and so forth, and these are better off with simple REST in most cases.
Dr Elkstein,
Both ROA and eventing are important developments in SOA. Is it possible to combine the two? I mean with traditional SOA/SOAP one can use WS-Eventing and WS-Notification, is it possible to integrate eventing in ROA/REST?
Hello Ranier,
I'm not familiar with the specifics of WS-Eventing and WS-Notification (by the time these specs were released, I've long since gave up on WS-* as something that's written by committees rather than by real developers).
I assume you want the server to notify the clients about events.
The basic question is, can your server initiate connections? Complementing this, can the clients listen to a port? If so, the client registers (sub), and the server notifies of events (pub). Both the registration operation and the notification events can be RESTful.
You need both server-initiated connections and listening clients. If either is not an option (e.g., because the client is a web browser), you will have to make do with polling. Design your polling carefully: the server response to the polling event should indicate a minimum delay before the client may poll again. The initial implementation of the server can return a constant for this delay value, but later on (assuming the clients are well-behaved) this will allow you to control the load on the server, differentiate between critical and less-critical clients, and so on.
(My answer is based on my reply in this StackOverflow question. You might wish to read the rest of the discussion there.)
hello,
I want to implement a wiki docia(somthing like wikiPedia) with web service technology,I read very pages and posts in very sites, but I’m very confused, because i don’t know i use REST or SOAP. please help me for my application which is best?(SOAP or REST)?
Thanks alot
I have very less knowledge in this domain. As of my knowledge, I completely agrees with Shruti.
We can compare REST and SOAP. REST or SOAP are just methodologies to implement SOA. Ultimately our architecture is service oriented or not, that is what it counts...
I am a bit annoyed that, after all these years, people still associate Web Services with SOA. That is complete, utter rubbish. I know that the big vendors have been perpetrating that lie for ages, but if one reads any reputable book on the matter (books by Thomas Erl pop to mind), one would understand that services are conceptual and not tied to an implementation. The implementation of connectivity to enable an SOA, be it RESTful, SOAP-based, .NET services or Ruby object calls, is COMPLETELY IRRELEVANT to real Service and Service Ecosystem design,
REST surely does not replace the best aspects of SOA design, such as dynamic service discovery and true service agility. It simply enables easier exposure of services without necessarily easier to catalogue or re-use services they provide, I am very open to being corrected on the final point, asI would love to hear how RESTful resources could be exposed as discoverable, reusable services in a diverse, non-Web Services exclusive dynamic true SOA.
I think the SOAP - REST debate is rapidly going the way of older debates around CORBA. REST will win because it is de-facto. Everything is else is just theory or vendor hype.
Robert
http://soaprobe.blogspot.co.uk
I'm making a lot of confusion. So, is REST a web service based on SOA architecture or ROA architercute?
In many article it seems that the development of a rest given rise to ROA, instead the opposite. can someone help me?
At the risk of fanning a fire, it seems to me that the argument of "nouns vs. verbs" is valid, but not directly correlated to "REST vs SOAP". Technically, you can do "noun" based architecture with SOAP, and "verb" based architecture with REST. In reality, it appears (I am new to REST) that REST propagators tend towards nouns (ROA) and SOAP towards verbs (SOA) but that is convention, not requirement. My point is that any discussion that equates SOAP with SOA and REST with ROA is, in my humble opinion, one of those pointless Internet arguments that go on forever without resolution.
Thanks, nice post
Post a Comment