Hang on to your buzzword-safe underwear! There’s a lot of buzz these days in the IT architecture world about whether to pursue SOA, ROA, WOA, do it RESTfully or SOAPy, what bus to drive, and what governance you can throw on top to make it all work.
I am a RESTafarian myself, and everything I do I do in a Resource Oriented way, so you can say I prefer the Resource Oriented Architecture (ROA) which really is a synonym to Web Oriented Architecture (WOA). The SOA way is far less technically defined, as SOA can be created with almost any technology, but there are some traditions and current marketplace geist with the term that associate it with larger stacks that use the SOAP and the various WebServices standards as a mean to “put it all together.”
Right, what’s the fuzz all about? Why are some throwing themselves at the resource oriented way while others stay with the API oriented way?
Did I say API oriented? My golly, I think I did, and this needs some explanation, and I’m going to quote from an upcoming article I’m writing which include a section on what I call the reversal of the address-function space ;
Let’s talk about design of your systems for a minute, as the answer is that all you know about governance, from IT governance to SOA governance, needs to have the same type of reversal of how you think about the services themselves and their individual evolution throughout your SOA space. You’re not governing API design, identity pollination, semantics across APIs and functional silos that addresses “access to things”: you’re governing how to express the “things” themselves. Thinking that services starts and ends at given points in your ROA is severly limiting your options, especially in terms of expressiveness.
This reversal is well known to functional (not to be confused with imperative) and declarative developers, where the focus is on the operational expression of results as opposed to executing a series of commands to get there. Within the RESTful community we often talk about how we use nouns instead of verbs, where we address “things” and relationships instead of “actions” and functions, and we need to be aware of both these angles into how we work with our systems.
If you thought these notions were small and somewhat insignificant, I’d beg to differ. Once you travel down the path of functional operations it’s hard to look back. Indeed, the combination of the reversal of the addressable function space and resource orientation is the very thing that makes the unified interface work so well, and that very interface is extremely important in terms of performance and scaling of systems, but there’s one more thing that needs to be addressed, pointed out and shouted, which is the semantic goodness of pointing to something and say “I want it.”
This is the way we humans foremost operate; first we point, then we interact. We don’t say “You know, cars? Well, you know all blue cars? Of those, there’s some that goes quite fast, and have really cool spoilers? Some of these are of the brand BMW. And of them, you know those that have the letters X, Y and Z on them, and really looks a lot like the car in front of us right now? You see that one? I’d like one of them.” No, we point at the car in front of us, and say “I’d like that one, please.” We don’t start with the generics of our conversations and traverse down until we find the specific thing we’re after, so why should we do this when dealing with computer systems as well?
APIs – or, I should say, the culture that emerge from it – focus on processes, but quite often we’re not interested in processes but results. Why are we defining processes instead?
SOA and SOAP / WS-* are highly process-oriented ways of thinking (“first do this, then that, then this, and finally that“), grown from the RPC (remote procedural call) philosophy of distributed computer systems. It was the natural way to start, but it doesn’t have to be the thing we should keep on doing. When we move into a resource-oriented way of thinking, we’re not defining a process as such, but a result. In fact, we leave the process-part to the backend systems, perhaps as a constraint of loose coupling, and this is an extremely subtle but important point.
I’m not even sure it can be explained as much as experienced; when you shift your thinking from processes to results (and, this is why XSLT programming is so hard for many people; it’s a paradigm shift in thinking) there’s a lot of boilerplate code that magically disappears. Declaring where you want to be instead of defining how to get there is subtle, oh so subtle. I can’t say anything more than just try it yourself. Try something new. I dare you.