SOA vs ROA
Two architectural approaches commonly applied today are the Service Oriented Architecture and the Resource Oriented Architecture. When considering these as a basis for your platform, the decision is not whether one is better than the other but rather which is more appropriate for the intended functionality, portion of the platform or entire platform. We will start by defining and explaining each of these architectures and then give some advice on how to make the right decision in light of your specific needs.
Service Oriented Architecture describes designing a system by modeling business processes as services or “actions”. Each service is a distinct unit of functionality and does not interact with the other services. In other words, calls between services are discouraged. As with object oriented programming wherein a major goal is reuse of code, the goal of SOA is to allow large chunks of functionality to be rearranged to form new applications. The size of the chunk of functionality is important because the more functionality that is included in each service, the fewer interface points that are required to implement a particular functionality and the fewer interface points there are in any particular functionality the lower the probability of transactional failure and improvement in performance. That said, very large chunks of functionality may not be granular enough to be easily reused. SOA is geared towards applications that are activity-based, such as a banking application where users are most interested in performing transactions such as deposit, withdrawal, open accounts, etc.
Resource Oriented Architecture is a term coined by Alex Bunardzic in his August 8, 2006 blog entry. It is now generally considered a specific set of guidelines for an implementation of REST. REST, or Representational State Transfer, comes from Roy Fielding’s Doctoral Thesis “Architectural Styles and the Design of Network-based Software Architectures” and describes a series of constraints that exemplify how the web’s design emerged utilizing the Hyper Text Transfer Protocol. It is difficult to discuss REST without blurring the lines between the technology of implementation and the ROA architectural principals. ROA is ideal for applications that are resource-based such as an RSS reader where feeds are the “resource” that the user is interested in getting information about and then updating the status of that resource.
A closely related technology decision is whether the implementation will be REST, SOAP, RPC or various other technologies. As discussed above, REST is often associated with ROA while SOAP is often associated with SOA. However, they are not mutually exclusive, in that it is possible to implement an SOA architecture through a RESTful implementation. Another confusing point is the difference between SOAP and SOA. SOAP, which originally stood for Simple Object Access Protocol, is a protocol for implementation whereas SOA is an architecture. The SOA and ROA concepts are the structure of the application and what information flows – they are descriptions of how something should work. REST, RPC, WS*, and other technologies are how the application actually works, or how they are actually implemented. We will talk more about these technology implementations in a later article.
The language analogy is that SOA focuses on exposing many verbs (actions) and ROA is focused on exposing many nouns (resources). Of course most applications, like sentences, are not all actions or all resources but rather they are a combination of both and have actions and resources. The predominance of the application should dictate the architecture. If you find yourself in a position of having a platform requiring a mix of actions and resources it may be useful to consider blending (albeit in separate environments) the two architectures. For instance, you might have a site that has reporting functionality that is primarily resource based and commerce functionality that is primarily action based. In this case your site could be comprised of two separate and distinct architectures that form a holistic client service including both commerce and reporting.
Ardent adherence to one architecture or another is not prudent. As we mentioned in our posting on Technology Agnostic Design (TAD) the professional technologist chooses the right tool for the job as should be the case for architectures, technologies, design patterns, programming languages, etc.the professional technologist chooses the right tool for the job as should be the case for architectures, technologies, design patterns, programming languages, etc.
If you have had a good or bad experience with either architecture let us hear about it