AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth


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

Comments RSS TrackBack 5 comments

  • Ethical Software by Alex Bunardzic » World Wide Web is About Self-Serve

    in June 19th, 2008 @ 00:09

    […] Almost two years since I’ve proposed the term Resource Oriented Architecture, I am still amazed at how no one seems able to grok the concept. Posts such as this one, or this one etc., illustrate total lack of even the basic insight into the nature of the world wide web. […]

  • Fish

    in June 19th, 2008 @ 03:13

    Hi Alex, really nice of you to link back to our post. ROA is a great
    concept but contrary to your post we think we do ‘grok’ it very clearly.
    You, like most parents, think your child is the best. ROA to us is not a
    religion, just like we don’t preach java or ruby or RPC or well you get our
    point. They all have their pros and cons, and should be used when
    appropriate, not despite their inappropriateness. You argue that there is no
    such thing as a service, that’s a pretty myopic view in our opinion. You
    use the public library system as a metaphor for the web, where people GET
    books they want to consume. This is a great example but you forget that you
    need to sign up for a library card before you can checkout anything.
    Signing up, registering, issuing, these are all services. Got a question
    for the librarian? That seems like a service to me also. Sure, you can
    convolute any of these into a resource if you really try but back to our
    earlier point, why force fit a technology, an architecture, or a pattern?
    We would rather have lots of cool tools in our toolbox, like ROA, and use
    the tool that is appropriate.

  • Jorgen Thelin

    in September 26th, 2008 @ 06:16

    > “Resource Oriented Architecture is a term coined by Alex Bunardzic in his August 8, 2006 blog entry.”

    I think you’ll find that the first recorded use of the term “Resource Oriented Architecture” occurs in my blog posting from February 2003 – pre-dating the entry on Alex’s 2006 blog post by over three years!


  • kasyno

    in October 13th, 2012 @ 07:22

    Anywhere I actually go through a similar post currently, as well as Now i’m asking yourself if the lady had written this plus the very same man. Precisely the same style which i indulge, even transferred very similar feelings. You write content articles in a few other website?

  • Bonuses

    in October 23rd, 2012 @ 12:42

    A motivating discussion is definitely worth comment. I do think that you need to publish more about this issue, it might not be a taboo matter but typically folks don’t discuss these subjects. To the next! All the best!!