Resourceful Computing

Thoughts about using Resource Oriented Computing to build simpler software

Archive for the ‘ROC’ Category

NetKernel request execution and threads

leave a comment »

One aspect of NetKernel that confuses developers is the relationship between a request and a thread.

A request is a demand placed on a software system. A request could be triggered by a user interacting with the system, a Cron timer reaching a particular time, or another system in need of information. At the completion of request processing either the state of the system has changed, an information representation is returned, a request is made of another system, or some combination of these occurs.

A thread is an abstract execution context which is implemented by a real instruction counter and registers in a physical CPU core. The Java thread abstraction is simple and relatively straight forward to use. A program (or container) can set up a pool of threads which can be executed on one, two, or more physical CPU cores. Because a thread is an abstraction, the physical level execution can employ highly optimized techniques which remain invisible to the developer.

The thread abstraction has worked really well. As we have progressed from single core computers to two and four cores, developers have used a model of “processing a request on a thread” to build reasonably performant systems. Complexities arise, however, when writing code running on multiple threads that mutates state. Doug Lea’s early work and the later incorporation of this thinking into the Java concurrency libraries has made multi-threaded development and state mutation tenable.

For most developers, this is the “state of the art”. Some have used more advanced patterns to achieve very high concurrency and performance. There are also libraries, frameworks, etc. that support these more sophisticated patterns, such as Node.js. Also of note is Rich Hickey’s brilliant work with the data structures in Clojure.

NetKernel provides a much simpler abstraction.

In NetKernel the concept of a request and thread are completely separate. There is no notion of “processing a request on a thread”. Instead, a request (implemented as a Java object, which, with other associated objects, contains the complete processing context) is issued and the client waits for the requested information to be returned. While a thread actually does the processing of this request, that abstraction is hidden, just as the optimized physical execution of a thread is hidden from a Java developer. The following code show how a request is created:

INKFRequest request = context.createRequest("res:/helloworld.txt");

and this code tells the kernel that it should process the request:

context.issueRequest(request);

Notice the method name – issueRequest(). This is similar to typing in a URL into a browser and requesting information. In both cases there is no notion of a thread – this is just a request for information (in our case for the resource “res:/helloworld.txt”). Of course these two methods calls must execute on a thread – it just doesn’t matter which thread. Requests processing and threads are completely orthogonal.

Compare this with traditional Java multi-thread coding. To create a new thread of execution, several things must happen: an instance of a Java object that implements the Runnable interface is created, the runnable is provided to a new Thread, and the thread is instructed to start:

Runnable runnable = new MyRunnableClass();
Thread runner = new Thread(runnable);
runner.start();

In this model a thread is a visible abstraction – the exact opposite with NetKernel. In fact, threads and thread synchronization are primary and very necessary concerns for a developer.

What does this mean?

The implications of using the NetKernel Resource Oriented Computing abstraction are interesting to consider, especially as it relates to the emergence of 8-core, 16-core, 64-core, etc. computers and the importance of distributed computing. If a developer builds a system that uses ROC requests then the number and location of the threads that execute the work are not even visible. They are decoupled from the request processing code. This means that the size of worker thread pools, the number of cores, and whether they are local or remote, are not coding concerns – they are architectural and deployment / configuration decisions. And all of these decisions can be changed for an already built application independent of the code.

Written by Randolph Kahle

September 18, 2012 at 5:44 am

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

1060 Research Weekly Newsletter

leave a comment »

Peter Rodgers, CEO of 1060 Research, publishes a weekly newsletter that includes interesting comments about Resource Oriented Computing. This page contains an index to these newsletters, a brief summary and, if I have thoughts about the newsletter, a link to a page with my comments.

Date Summary Volume Issue
March 11, 2011 Sometimes Peter Rodgers hits a home run with his newsletter. This week he covered several topics that I found really interesting. First, he announced a new SSH Client Library module which I first worked on for a client in a consulting engagement. Next he talks about the new TransientFileRepresentation which leads to a very simple implementation of support for the SSH transfer of arbitrarily large files. Finally, he provides an excellent discussion about how to think about the ROC architecture of a system and divide the work into teams. 2 20
March 4, 2011 Transactional overlays – introducing the new SQL Transactional overlay and a general discussion about implementing your own. 2 19
February 25, 2011 More about Shakespeare and infinite monkeys. 2 18
February 18, 2011 Infinite monkeys. 2 17
February 11, 2011 Negotiated HTTP Cache Consistency. 2 16
February 4, 2011 Several interesting topics – Asynchronous transports, dealing with corporate firewalls and Apposite, IP6 support and the stability of ROC solutions. 2 15
January 28, 2011 Advanced HTTP Handlers, Asynchronous HTTP Handler, SOAP client enhancements, HTTP Client review, XML Serializer and ROC resource and solution stability. 2 14
January 21, 2011 Brian Sletten’s article about why he uses NetKernel and an update on NetKernel performance testing. 2 13
January 14, 2011 A discussion about the NetKernel Portal Framework. 2 12
January 7, 2011 A discussion about Transport scope confirming that the space in which a transport is declared is the top of the super-stack. It was motivated by a problem ticket describing a transport, declared within a mapper-wrapped space, unable to request its configuration resource. 2 11
December 24, 2010 A year-end summary issue that looks back over the last series of articles and looks forward to the future of ROC. Peter uses a metaphor of bridge building technology to explain the difference between traditional framework and code-centric thinking and an ROC way of thinking for building information systems. 2 10
December 17, 2010 The fifth article about ROC and languages looks at functions and set processing. 2 9
December 10, 2010 The fourth article about ROC and languages examines what code and functions are all about. 2 8
December  3, 2010 The third article about ROC and languages focuses on arguments – Pass-by-Value, Pass-by-Reference and Pass-by-Request. 2 7
November 26, 2010 HTML 5 introduces Web Sockets. While they are not RESTful, they do work well with the Resource Oriented Abstraction supported by NetKernel, as demonstrated by downloadable demos. 2 6
November 19, 2010 The second article on ROC and languages looks at imports and extrinsic functions. 2 5
November 12, 2010 The first article on ROC and languages. 2 4
November 5, 2010 This week there is no commentary on ROC. 2 3
October 29, 2010 An exploration of state balancing and ROC level request routing. 2 2
October 22, 2010 On State and consistency. Golden Thread pattern 2 1

Written by Randolph Kahle

December 20, 2010 at 5:00 pm

Posted in NetKernel, ROC