Shelter

Tech, philosophy and random musings

You are here: Home / Soa Roa Woa Rest Soap Ws Architecture / SOA; ROA; WOA; REST; SOAP : A point about what we’re addressing

22 April, 2008 by Alex

SOA; ROA; WOA; REST; SOAP : A point about what we’re addressing

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.

Filed Under: Soa Roa Woa Rest Soap Ws Architecture

Recent Posts

  • Another bob
  • Another tidbits
  • Philosophical and religious matters
  • Do libraries understand the future? Or how to get there?
  • Before I write what I write before the next time I write

Archives

  • April 2010
  • March 2010
  • February 2010
  • December 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • January 2009
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • September 2007
  • August 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • March 2006
  • October 2000

Categories

  • Alsa
  • Application Design
  • Australia
  • Baroque Music
  • Biology
  • Blogging
  • Book Review
  • Business
  • Canberra
  • Chemistry
  • Coaching
  • Communication
  • Conceptual Models
  • Conference
  • Context
  • Cooperation
  • Cosmology
  • Creationism
  • Crows
  • Cute
  • Data Modelling
  • Data Models
  • Debt
  • Dune
  • Ead
  • Ecology
  • Elegant Code
  • Emnekart
  • Environmentalism
  • Everything
  • Evolution
  • Family
  • Film
  • Food
  • Frameworks
  • Fstl
  • Future
  • General
  • General Life
  • Globalism
  • Grace
  • Happiness
  • Harmonica
  • Holidays
  • Humanity
  • Ia
  • India
  • Indiana Jones
  • Intelligence
  • Java
  • Jobs
  • Juggling
  • Kiama
  • Kids
  • Knowledge Representation
  • Kuala Lumpur
  • Language
  • Laptop
  • Leipzig
  • Library
  • Life
  • Life Lessons
  • Linux
  • Localivore
  • Lucas
  • Marcxml
  • Misc
  • Monteverdi
  • Mood
  • Movies
  • Music
  • Music Production
  • Norway
  • Ontology
  • Ooxml
  • Open Source
  • Oslo
  • Oslo Domkor
  • Oss
  • Philosophy
  • Php
  • Planning
  • Programming
  • Programming Languages
  • Proud
  • Rdbms
  • Real Estate
  • Rental
  • Rest
  • Richard Dawkins
  • Salut Baroque
  • Sam
  • School Closures
  • Semantic Web
  • Semantics
  • Soa
  • Soa Roa Woa Rest Soap Ws Architecture
  • Sound
  • Spielberg
  • Status
  • Stupidity
  • Systems Thinking
  • Talk
  • Technology
  • Terje Kvam
  • Test Driven Development
  • Tidbits
  • Tmra
  • Tmra 2008
  • Topic Maps
  • Ubuntu
  • Ubuntu 9.04
  • Ucd
  • Uncategorized
  • Universe
  • Ux
  • Vista
  • Wollongong
  • Work
  • Working From Home
  • Xml
Copyright © 2021 Shelter.nu