You might well have expected to see this confusing graphic1 to be from the NetKernel page on 1060research.com given the way we appear to be simultaneously teasing visitors with the promise of refreshing cool water of IT nirvana whilst blasting them with either technobable or mind twisting concepts (depending upon your level on cynicism.) This can act as a barrier to all but the persistent.
I’ve recently spoken with quite a few people who have persevered and have told me their story, so in this entry I wanted to just reset things a bit and build up the story of what Resource Oriented Computing (ROC) is and why it’s worth the effort to understand. That is not to say that we should not endeavour and are not endeavouring to improve our communications.
Resource oriented computing grew out of the Resource oriented architectural (ROA) approach long before that term was coined. However we broadened the scope from networked computer systems running within the world wide web down to the software that runs on those computer systems too. The reason we did this was twofold. Firstly we saw an impedance mismatch at the network boundary. Secondly we saw that the malleability of the web to change over time was significantly better than traditional approaches to software. Bridging the two with a scale-invariant abstraction had the potential to give significant economic benefits.
In this post I want to just go through the basic principles of ROC in a logic progression without any justification to show you just how simple the essence is. In a future post I will then endeavour to show the first order implications of these principles.
- Everything is a resource - A resource is any useful information to the software. It may be information held outside the software in the file-system or server, it maybe information held in memory, or may be derivative information somehow computed from other information. Importantly, it must be uniquely identifiable, this is done with sequence of characters called an identifier.
- Endpoints embody resources in software - To make resources usable, ROC encapsulates them in a software component called an endpoint.
- Requests act upon resources - The only way for anything to interact with a resource is by issuing a request. Requests are handled by the endpoint for a resource which then returns a response. Endpoints have no API other than that to receive requests. Requests specify a verb, which is a mode of interaction, from a small set including source (get a snapshot of the state of the resource), sink (update the state of the resource), delete and exists.
Representations transfer state - Representations are immutable data structures which transfer information in and out of endpoints within a request or response. Unlike in ROA, representations don’t have to be sent over a network so rich in-memory data structures are often used.
Spaces host endpoints - Spaces are containers for endpoints and thus provide an address space with all the identifiers for the resources that those endpoints embody.
Request Scope determines the resolution of a request - Resolution is the process whereby an endpoint is found to handle a request. A request scope is the list of spaces that are used in order to resolve a request. If no resolution is found in this list the request fails.
Endpoints can issue requests - Endpoints can be symmetric peers which can issue requests as well as handle them. The endpoint for one resource can issue a request to another resource in order to fulfill its request.
Transreptors2 can be used to convert representations from one form to another - Transreptors are a special type of endpoint which can be used to adapt the representations passed in requests. Transreptors are a generalisation of parsers, serialisers and compilers.
- Photo was taken a the Chipping Sodbury Quarries close by to the 1060 office.
[return] - Transreptor is contraction of the Latin prefix trans and representation. [return]