Resourceful Computing

Thoughts about using Resource Oriented Computing to build simpler software

Archive for the ‘Thoughts’ Category

What language should we use to talk about ROC?

with one comment

Humans thrive on communication and we have invented many different forms. For example – music, dance, written communication which includes novels, poetry, short stories, essays, blogs, etc., as well as visual forms such as paintings. For particular domains, such as mathematics, we have developed symbolic languages that allows us to succinctly express our ideas. In the field of information systems we have different ways of expressing ourselves from the highest altitude view to executable code.

Resource Oriented Computing is an approach to conceive and implement information systems. It is natural to start with a familiar language to discuss the abstraction and then extend the language when required. In the eight years I have been working with Resource Oriented Computing I have wrestled with this language. It is frustrating because the concepts behind ROC are very simple and yet, we do not have an agreed upon set of words or notational system. I now think that the ROC community needs a new language.

I realize that the language we use helps us articulate out thoughts and shapes our thinking by facilitating and constraining. A language facilitates thought by making available words or symbols that have an agreed upon meaning and which allow us to easily note what we want to communicate. If that language lacks words or symbols for a particular new thought, then it constrains us and it forces us to either extend the language or take more time to build a line of reasoning.

Which languages have we tried? I have used pictures with address spaces (that look like clouds), endpoints (that look like rounded rectangles), and requests (that look like arcs). These symbols were first designed by Peter Rodgers for the NetKernel documentation. In conversations with Peter he has shown me a more mathematical and symbolic way to describe ROC. Tom Hicks has shared his ideas about a Lisp-like notation. I have experimented with a DSL to extend the Groovy programming language. The NetKernel explorer tool uses a graphical rendering. The NetKernel nCode composition tool presents a graphical view of endpoints and relationships but ignores address spaces. And finally, to create a running NetKernel system, one uses a text editor to create an XML document.

My final complaint about our current state is that no language supports a discussion about information flow through a NetKernel system. All of the languages are about the composition of spaces, endpoints, and request / response processing. What actually happens in a NetKernel system is that information flows through the ROC architecture. Isn’t that the whole point of an information system? If so, why is that not the primary focus of a language?

I leave this as a challenge to the NetKernel / ROC community. Let us create a new language for ROC.

Written by Randolph Kahle

September 1, 2012 at 7:29 am

Posted in ROC, Thoughts

ROC – A Tale of Two Phases

with 3 comments

In the resource oriented computing (ROC) abstraction, resource requests are processed in two phases – the Resolution and Evaluation phase. In the resolution phase a search is conducted to find an endpoint that will resolve the request. During the evaluation phase, the endpoint found in the resolution phase is asked to perform whatever computation it requires to create and return a representation of the requested information.

Each request triggers these two phases, which means that a subsequent request for a particular information identifier could resolve to a different endpoint. This is a critical feature of ROC that we will argue later provides architectural flexibility.

The following diagram illustrates the resolution phase. The endpoint acting as a requestor issues a request into its containing space and a  search is conducted to find the first endpoint that resolves the request. In the diagram, the search reaches the Import endpoint which forwards the search into a related space. Within that space we see an endpoint finally resolving the request, which ends the search.

ROC Request Resolution (logical)

The next diagram illustrates the start of the evaluation phase. From the perspective of the endpoint acting as the requestor, a temporary relationship is established with the resolved endpoint and the request is sent for evaluation.

ROC Request Evaluation (logical)

When the endpoint creates a representation, it returns it to the requestor and the relationship between the requestor and the endpoint is forgotten.

ROC Request Evaluation (logical)

The cycle of searching for an endpoint followed by request evalution and then amnesia repeats for each request. This is fundamentally different from what most of us are used to. Most software systems work hard to optimize run time efficiency by remembering relationships instead of forgetting about them. Traditional compiled languages such as C, C++, Pascal, etc. generate compiled object libraries that are linked together by a linker. In Java, a Classloader brings class definitions into memory and created objects are linked through method address resolution tables when methods are first called. If we want to introduce dynamic relationships in these systems, we have to work at it and introduce points of indirection. Some languages make this easier, such as Groovy and its Meta Object Protocol (MOP); however, what is different with ROC is that the separation of a requestor and a service endpoint is fundamental.

The implication is that with ROC, we can create software that is reconfigurable at run time. At any level of an application architecture. In fact, all facets and any level of a system can be reconfigured dynamically. In the next post we will look at an implementation of ROC and explore why its performance is not all that bad while future posts will examine how we can harness this flexibility to our advantage.

Written by Randolph Kahle

April 1, 2010 at 4:03 am

Posted in Thoughts

Tagged with

Resource Oriented Computing

leave a comment »

This blog explores the use of Resource Oriented Computing to build simpler software. So, what is ROC? This post takes a preliminary, high-level look.

The fundamental abstraction is illustrated in the following diagram.

Resource Oriented Computing Abstraction

In ROC, requests are made for information by a Requestor by issuing a request into a Space. Information is modeled as Resources and each resource has one or more Identifiers. The diagram shows a resource request for a member of a Resource Set being resolved to an Endpoint. When the endpoint evaluates the request it returns an immutable copy of the information in the form of a Representation.

This diagram illustrates how the World Wide Web works! A browser (requestor) issues a request for information and identifies that information with a URI (the URL of the resource). The domain name service (DNS) resolves the identifier (within a global space) to a web server (endpoint) and then the browser issues a request directly to the endpoint for evaluation. The web server (endpoint) evaluates the request and returns a copy of the current information in the form of a web page (representation).

The ROC abstraction becomes particularly interesting when implemented as a very small software platform to support software applications development. The resulting software takes on characteristics of the Web, such as scaling, flexibility and malleability.

In the next several posts we will explore many of the facets of ROC and see how they impact the quality and simplicity of software.

Written by Randolph Kahle

March 29, 2010 at 12:01 pm

Posted in Thoughts

Tagged with

Resourceful Computing

leave a comment »

I don’t enjoy complexity.

This blog will be an exploration of resource oriented computing with a particular focus on its ability to reduce complexity in software systems.

While this will be a record of a journey of exploration, I do welcome comments and feedback.

Let’s see where this leads…

Written by Randolph Kahle

March 20, 2010 at 1:48 am

Posted in Thoughts

Tagged with