Resource Oriented Computing is general purpose computing abstraction. It can be regarded as a generalization of the World Wide Web's REST architecture and the foundation concepts of operating systems such as Unix. But with an eye to history one sees that it traces its origins back even further to Turing and his seminal papers on the Turing and Oracle-machines (Turing 1939) but even beyond that it ultimately rests on the core mathematics of set-theory and Godel's world changing thesis on incompleteness and computability.
Fortunately, Resource Oriented Computing (ROC) is both simple and consistent. Once you have learned the model, the following diagram is all you will need to remember its essential features.
In ROC, information is modeled by resources. For example, a conference information system would have a resource modeling information about registered attendees and one modeling information about speakers.
Each resource can be located using its identifier. While an identifier can be any sequence of characters, it is common practice to use a Universal Resource Identifier (URI). Using our conference example, our two resources could be identified as
A resource in ROC is abstract.
The representation of its information becomes concrete only when it is requested.
When you think about it, this makes sense.
You can talk about "the list of speakers" in an abstract way and
you don't need to know who is actually on the list nor the exact form of the list.
If you do need the information you can ask for it or
request the resource
When you do,
you will get a concrete copy or representation
of the information.
If you request the information again you will again get a
(possibly updated) copy of the resource.
Information systems support more than information retrieval. An ROC system allows you to create new resources, delete them, test if they exist, update as well as retrieve them. These actions are specified by the verb of a request. In addition to URI identifiers, an ROC system supports the verbs SOURCE, SINK, NEW, EXISTS and DELETE in a request.
In ROC all resources exist within a space. When a requestor needs to interact with information it issues a request (consisting of a verb and an identifier) into its space. As resources are abstract we must consider what is responsible for interactions with the resource's information. In ROC a request for a resource is handled by an endpoint, physical code that executes to service a request.
When a request is issued into a space, the space searches for an endpoint associated with the identified resource (that is, the resource is in the Abstract Resource Set). In this process of request resolution, each endpoint in a space is presented with a resolution request until one of the endpoints determines that it can handle the request and it responds affirmatively (it resolves the request). The endpoint that resolves the request is then sent the request for processing.
If no endpoint in the space is able to resolve the request then what happens next depends on the larger processing context. Some request contexts include a scope - a set of parent-child space relationships. If a request does not resolve in a child space then it may be sent up to the parent space and the resolution process examines all endpoints in that space. Ultimately an endpoint is located or the request fails due to a resolution failure.
Once resolved and in receipt of the request, an endpoint may do any number of things including inspecting and using the details present in the request and/or make further requests for other resources. Ultimately, based upon its implementation logic, it will construct a response which is returned to the requestor. A response usually (but not always) contains a representation, or immutable copy of the resource's current information. (A SINK request would send information to the endpoint and expect none in return).