Skip to Content

The Problem Statement:

The are 2 schools of thought around which approach is better, SOA (Service Oriented Architecture) and the RESTful (ROA – Resource Oriented Architecture).

I’ll probably get shot down from a dizzy height for starting up this hotly debated topic but nothing ventured, nothing gained right? It also doesn’t matter if the SOA train has already left the station, let’s call this a certain kind of architecture optimisation.

A Brief History:

ROA (REST) has been around for longer than SOA (I can still remember dabbling with this in 2000 and how painful I thought it was then because I didn’t understand it too well) and it’s strengths are quite well documented and many references have been made to Roy Fielding’s PhD dissertion on the subject, SCN’s very own DJ Adams has blogged quite extensively on the subject and lest we forget, Tim Berners-Lee’s Axioms! We also know that the world wide web (WWW) is essentially based on ROA. It has lots of strengths (I think more from a technical perspective), like:

  • Better indexing
  • Works well with SEO
  • Responses are cached for faster retrieval etc.

SOA on the other hand is touted as a natural evolution of ROA (which I beg to differ on – I think it’s more of a side step to ROA). But where SOA does make a lot more sense to me is in a business process context (I’m also cogniscent of the URL’s are cheap viewpoint). It just makes sense to me to have all related operations grouped together in  one Service. From an integration & development point of view, it makes life much easier when it comes to maintenance, versioning & general governance. It also makes sense if one is adopting a top down approach, there is a natural progression (with traceability) from BPM (Business Process Management in this case) all the way through to the service implementation. So SOA also has lots of benefits (I think more from a business perspective). Now we’re already talking about SOA 2.0 (Event-driven SOA) and Complex Event Processing. Lot’s of it is still hype & the Causal Vector Engine sounds a lot like Fuzzy Logic to me but I can already see the impact on Business Agility this is bound to have.

My Proposal:

Since I love to have my bread buttered on both sides! Why should our school of thought be either ROA or SOA? Why not both? I mean both have phenomenal strengths & are relevant for different tasks so why not harness all the goodness? The tie that binds us would be the adoption of a Reference Architecture that is agnostic (technology, architecture, approach, methodology, etc.) in every sense like Theo Elzinga’s CORA Model (See the 6 part blog series)…

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Sascha Wenninger
    Hi Trevor,

    well, here’s a rant to fuel the flames 😉

    In my experience, SOA is very difficult to implement well because a good implementation demands many things of many people in an organisation, such as a good process model, process ownership, active interest of the business in “IT things”, etc. before you can even think of defining services at a conceptual level.

    The top-down SOA approach requires a huge up-front investment in a broad understanding of a company’s processes before one can chose one or two areas which are modeled in more detail and for which services are defined.

    All of this is hard. Months or years will be spent on this before any tangible value is returned. Often once a service with much-touted reusable interactions is implemented, it is obsolete after 6 months and needs to be reworked. Not because someone made a mistake but because process/service thinking involves very abstract thinking which doesn’t come naturally to most people and it’s all a learning experience.

    By comparison, thinking about resources is much more concrete and thus easier. I bet that more companies have a better understanding of the resources (as in ROA) that they care about than they do about their processes. Ownership is often more well-defined too. And because URLs are cheap, an ROA implementation can grow organically much better than an SOA implementation.

    For example, it is much easier to extend a URL schema or add some hyperlinks to a HTML representation of some kind of ‘directory’ or ‘super’ resource without impacting existing consumers than it is to add operations to an existing service – no WSDL/namespace/schema versioning, etc. to worry about!

    Case in point: My company has a pretty decent information model which defines the entities (resources) the business cares about in a conceptual way and at a high level. It has taken 2 major iterations but by now it’s reasonably broad and not deep enough to be too wrong :-p. It also has remained relevant in the 2 years I have worked there without requiring major revisions. So this makes it a good starting point for an ROA.

    By contrast, the equivalent process model is pretty bad. Since something along those lines is usually thought of as a prerequisite for a good SOA, things get tricky. I don’t feel comfortable using this as a starting point for my top-down service design because I’m pretty confident that the ground will shift underneath me while I’m busy modeling services against that.

    Service/process-oriented thinking is much harder than thinking about resources, so it’s much harder to do well, especially when trying to do this in a large company with 10+ SAP and non-SAP projects running in parallel. I find thinking about resources much simpler, which makes it easier to teach and apply consistently in a decentralised fashion, and probably has a better chance at delivering ROI to the business…

    Regards,

    Sascha

    (0) 
    1. Trevor Naidoo Post author
      Hi Sascha,

      All you points are very valid & highly appreciated. I’m coming from a different angle though, a more neutral one.

      Having said that, I can also make a case for SOA. It can be complex & will definitely involve a substantial capital outlay upfront but having done some work at a company that has significantly more projects running parallel (probably between 40 & 50) I could definitely see the benefits of the SOA adoption route.

      The foundation is only really laid once & then it just minor tweaks (you could tweak on a grand scale if you really wanted to – SOA adds some great flexibility). I found that versioning was really quick too. Naturally, it would depend on the complexity of the operation but a simple operation version step could take about 15 minutes (or less) without any impact to existing consumers.

      “I’m pretty confident that the ground will shift underneath me while I’m busy modeling services”. I think that’s exactly one of SOA’s strength’s. Loose-coupling so that you’re not tied down to some or other solution that’s not scaling with the business for example. It’s okay if the ground moves under you or the sky (or cloud for that matter) moves above you, just plug in another sky / cloud that can manage your business requirements within the SLA’s agreed. Your business process are pretty constant except when you want to create some competitive edge or changing conditions. If you’re using a canonical data model, your service contracts are pretty constant & if you data types are UN/CEFACT CCTS compliant then you data types are pretty constant in all contexts.

      ROA is easier to grasp but where I struggle with it is the amount of work needed during process orchestration or composition. It will cost a lot less initially but it seems like it may cost a lot more longer term (please correct me if I’m wrong on this point).

      I agree with you that getting SOA right is resource intensive, but the key is having the right team getting it right from the onset.

      I guess that all I’m really saying is that SOA & ROA can co-exist & can mutually benefit a business from an ROI perspective.

      Regards, Trevor

      (0) 

Leave a Reply