The Web is simply the biggest, most successful, most usable distributed systems architecture ever.
So why is it that people keep proposing alternatives that struggle to succeed? First I had this with the Grid, watching people giving talks saying “we’re nearly there”, “it’s a long game”, “distributed systems are difficult” and there’s me thinking “but… but… the Web works!” Cloud services are making my point nicely now. But I’m still getting it with SOA, where on the one hand some surprisingly unquestioning people tell me it’s clearly the right way to go, while on the other I hear stories of real SOA achievements really quite low down in the maturity model. Is the Emperor’s wardrobe so full of new clothes? Ok, I’m the first to say it’s horses for courses, but the neglect of the Web baffles me.
I think the reason for the dominant acceptance of the SOA architectural style is that it’s programmed into the profession. We know how to write programs with procedure calls so we know how to do remote procedure calls. We understand objects so we can do remote objects. SOA is principled and you van buy training courses and get certificates. And it’s become a buzzword. And I think the reason it struggles is that first you have to servicify legacy apps – not so easy – and then later try to recompose services (flexibly, dynamically, … you know the mantra) – which turns out actually to be quite difficult because SOA services are complicated.
By their nature Web apps are also client-server, and people have become rather good at coupling things together. But there seems to be confusion over the principles of the Web architectural style, which is a pity given it’s the most successful distributed system ever. There have been efforts to capture it, starting with Fielding’s REST model. Rest has become misunderstood to a point which is damaging, so introducing a new word is probably a good idea – I like Resource Oriented Architecture. For example, the O’Reilly RESTful Web Services book attempts to establish some Resource Oriented Architecture Principles beyond Fielding.
Actually ROA is very easy to understand. You have a resource (think URI) and a small number of predefined methods that you can use with it – like GET and POST. The web infrastructure is massively optimised to make these methods work really well. When you want to do other stuff you don’t add more methods but rather you add more resources. Voila – Resource Oriented Architecture. Everytime you navigate the Web you are using it.
In SOA you instead add methods and thereby create complex interfaces to individual entities, interfaces that must be maintained client- and server-side. In pursuit of simplicity this can add complexity. Great if you want lots of code (though ironically the idea of SOA is to avoid the alternative of writing lots of code!)
So why is it we don’t have principles of ROA that architects can wield like those of SOA? Well actually I think we could, and I would love to help people capture them! I think the challenge is that the success of the Web architecture is precisely because it has been allowed to be organic. So the ROA principles will have a different nature to the inorganic principles of SOA.
I think we could start by doing what the Web 2.0 design patterns did. Web 2.0 wasn’t created by a bunch of architects sitting down and saying “ok we have Web 1.0, let’s design the next version”. Rather the design patterns are a set of observations on how the Web is actually being used, by people, today. I think we could come up with a set of ROA patterns in a similar vein (indeed, surely, they would be related!)
Until we have these, SOA will dominate in any software design process that involves trained engineers. SOA isn’t broken – it’s an entirely plausible way of writing a lot of code to build systems when you don’t have a better way. But I think it has to be challenged – for any given system there may be a better architecture, and ROA is a candidate. Maybe ROA is good for people coupling things together and SOA is good for machines. Or maybe we need a resource-oriented variant of SOA.
So I think we should do two things:
1. Identify the design patterns that characterise ROA.
2. Compare and contrast ROA and SOA systems (preferably using the same systems built both ways!) to work out where and when we get the benefits.
My favourite example at the moment is a big sensor network project (SG4E) which is going to have an SOA middleware and REST on top for rapid application development. There’s a compelling argument for this classically 3 tier model - you know the one: Web 2.0 is flaky and needs robust services underneath so let’s put a properly-engineered SOA there. But this is very deeply a resource-oriented project (it’s about things, in the physical world), and surely could be ROA all the way down. What’s more, the project uses RDF (i.e. Resource Description Framework) – one might expect that to sit most comfortably in a resource-oriented model! This pervasive ROA question gives rise to a great thought experiment: What is the REST API for planet earth?