Beautiful Architecture - Resource-Oriented Architectures

Chapter 5 of the book Beautiful Architecture dealt with a architectural "style" I was not familiar with which they called "resource-oriented architecture". The chapter describes the current popular SOA approaches (which I am not very familiar with either) to the architecture of business system and how these fail to solve the problem of reducing complexity for the developers. The chapter also claims that SOA approaches to a degree also fail to reach their goal of allowing heavy reuse of business services in different contexts. They then present an alternative modeled on the world wide web which is what they call resource-oriented architecture or ROA.

My understanding of ROA, which will likely reveal my ignorance as I have only had limited exposure to the business system development world, is that it moves the primary focus from the services (behavior/verb/action) to the the data (content/noun/thing). In a sense I see this as weakly analog to the move from structural programming to object oriented programming. The first emphasized functions that perform some action while the latter emphasize the things that are being modeled (I believe the original goal of Simula was to model things in the real world in order to simulate them more intuitively). Stretching this analogy too far a SOA is similar to providing function pointers that implements services while a ROA would give you a pointer to an interface of an object which you could then use (and reuse) to query/set different properties independent of the underlying implementation.

Of course ROA resource links, like objects, provide services allowing manipulation of and access to different representations of the data (GET/POST/PUT/DELETE - what is wrong with good ol' CRUD?), but the first class concept is the statical dimension (the content pointed to by the URLs) as opposed to the time dimension (the action to perform on that content). As E. W. Dijkstra observed in his letter arguing why goto sentences are harmful "My second remark is that our intellectual powers are rather geared to master static relations and that our power to visualize process evolving in time are relatively poorly developed" (yes I'm a bit of a sucker for good quotes). I think this is an insightful and rather pragmatic observation and one we should make use of.

The chapter also discuss more practical considerations such as security being more easily handled by design in a ROA system as it passes links around instead of data. The clients could therefore request and get a link to a resource. This link could then be used several times by the client and could potentially even be shared with other clients without worrying too much about authentication, authorization and encryption. The access control is then be performed when one of the clients try to use this link, which in many ways is how it works on the internet. Another benefit they discussed was that ROA made it easier to handle caching, which seemed to be grounded in the observation that it is easier to cache a resource than a "service".

Finally, Will Leinweber put forth the question of whether always putting data up front is a good idea. It was an interesting question and I thought about it a bit. My instinct is to not believe in silver bullets, but for an information handling system I would be inclined to say that I think it is a good idea as it is easier to conceptualize and aligns the architecture with the goal being solved (I.e. accessing information).