Thinking About Resource-Oriented Architectures
There is a lot of buzz around Resource-Oriented Architectures. Often these are promoted in conjunction with RESTful Web Services. However although really complimentary, they are independent. The primary focus of Resource-Oriented Architectures is that accessing data is king. All data is represented as a resource and can be directly addressed. The focus is entirely on the data (or nouns) and processing type functions (verbs) are secondary. Another key point is maintaining a distinct separation between nouns, verbs and representation.
It’s becoming a bit embarrassing these days that any user can access huge amounts of data on the Internet easily and efficiently. However if you go to an companies IT systems or ERP system, finding and accessing ad-hoc data can become extremely difficult or impossible. Why is it easier to access third party data over a public network than it is to access data on your own systems that you have full control over? A lot of it comes down to how traditional ERP and IT systems are architected versus how the Internet is architect ed. The Internet is all about addressing data, searching for data, linking data together and forming relationships. IT and ERP systems are all about executing SQL statements efficiently, normalizing relational databases and building IT silos.
Resource-Oriented Architectures try to take the best ideas from the Internet and use them to build a solid foundation and framework for developing ERP and IT type applications (among other things). Basically taking the focus away from SQL databases and putting it back on the data itself. In these Architectures each data element is a resource that can be addressed, and every resource can be accessed and manipulated by a standard simple API. This is where RESTful interfaces come in. REST is a Web Service protocol that addresses data as URLs (hence every bit of data has its own URL). Then REST offers 4 verbs to access and manipulate this data. Basically a very simple protocol that manipulates every resource in the system in a consistent, standard way. Many traditional software engineers balk at such a simple interface to resources, yet extremely powerful and flexible systems have been designed and implemented this way, including many of the main popular web sites on the Internet.
Part of the power, flexibility and scalability of Resource-Oriented systems comes from their simplicity. You can build higher level resources easily out of the lower level resource and easily use them since the interfaces are standard and the higher level resources then share the same interface. Even items like reports can be addressed as resources and the same API used to process them.
A key point is to have a separate meta-data system that can fully describe all the resources. This allows much of the processing to be meta-data driven rather than code driven. It also allows flexibility in representing the data. As new formats come along, the system can render the data in the new format using the meta-data. Or various clients can negotiate with the system which representation of the data they would like, HTML, RTF, XML, etc.
Generally Resource-Oriented Architectures are at the heart of some of the most flexible, scalable web sites and it certainly behoves anyone looking at architecting a new system to consider this.