WARNING: This server provides a static reference view of the NetKernel documentation. Links to dynamic content do not work. For the best experience we recommend you install NetKernel and view the documentation in the live system .

Alternative Start

The QuickStart guide presents a quick overview of the concepts of ROC. But if, as you're reading through, your finding the concepts alien then it might be a good idea to switch to the ROC Basics tutorial and try some practical hands on stuff.

This Quick Start Guide will introduce you to the concepts of resource oriented computing and help you start building systems and applications.

If you want an introduction to the fundamentals of resource oriented computing, please read the Resource Oriented Computing Guide. We also recommend that you look at the Tutorials Book for a full range of tutorial and training material.

Brief History

NetKernel is different. To give you a picture of how it is different here's a short story...

A computer program defines functions, invokes functions, receives values, assigns those values to variables (state) and invokes more functions with that state. There are dozens of programming languages, you choose your language, you write your program, you run your program. That's how it is, that's how it has always been.

Step forward to the early 1990's. The World Wide Web was developed as an efficient distributed information system. To begin with it was static, serving files, but soon it became dynamic - when your browser requested a URL the Web server would dynamically compute the state and return it to you.

The Web is a software system that has completely decoupled the state from the implementing functions. Nobody cares if you write your web application in PHP or Java or ... etc etc etc. The only thing that matters is the name of the resource (its URL identifier) and the state of the resource when you request it.

So what?

So what? So, the Web can be instantly updated, the Web scales, the Web absorbs change, the Web is malleable and flexible. These are properties that every well run business would like to share.

So in the early 2000's people started to think this was "a good thing". People started to talk about "Web-Services". There were some absolutely abominable technologies that got labelled with the "Web" label. Fortunately many of them died and over time people have started to realize that these weren't very web-like at all. Today there is growing interest in REST.

REST is just another name for "the properties of the Web".

End of story. Or is it...

So we can expose dynamic business information and business processes (business state) using the Web. But the dynamic information is generated with computer programs that call functions, receive values, invoke more functions etc. Because that's a "computer program" and that's how it has always been.

Not necessarily...

The Browser - A Special Resource Engine

What is a web browser? If we look at the web pages that a browser displays we might see it is an application for rendering HTML, images, styles and additionally the execution engine for associated javascript.

But look further, what if we take off the top rendering surface and look under the hood.

  • The browser is an engine for accessing resource state over HTTP.
  • Using DNS it resolves each URL to locate the physical network address of an endpoint.
  • It constructs a request for the resource and issues that request to the physical endpoint.
  • It receives a response to the request from the endpoint.
  • It uses the associated response Header metadata to determine how to manage the state it receives (the resource representation).
  • Based upon link resource references in the representation it manages a cascade of further resource requests for associated resources (styling, images, javacript...)
  • When sufficient state has been transfered (REST) it starts the process of compositing the resource state so that it may be rendered on the top surface.
  • As we interact with the render surface we trigger further requests - every time we attempt to access the state of a resource the browser looks in its local managed resource state (known as a cache) and if it finds a representation and that representation is valid (not expired) it uses that local copy instead of invoking the remote endpoint.

The web browser looks like an application for rendering web applications. In fact, under the hood, it is a Resource Engine for acquiring and managing resource state.

NetKernel - A General Resource Engine

What if we had a General Resource Engine (GRE)? What if we harnessed such an engine in any business solution? Wouldn't we start to get the economic properties of the Web appearing in any business problem?

Solutions that scale, that absorb change, that are malleable and flexible...

If you want a very simple analogy for how NetKernel works, it is a browser with the top taken off.

But NetKernel is not tied to HTTP. Its Resource Oriented Computing abstraction is a general abstraction independent of network or operating system.

It generalizes the core principles of the Web and applies them internally or externally to the fundamentals of software and software systems.

NetKernel is a General Resource Engine and enables Resource Oriented Computing.

Crazy Idea

It turns out that when you build software with a General Resource Engine you acquire the Web's properties of scalability, maleability and assimilation of change inside the fine granularity of your software. But something else happens too.

A sensible software engineer would listen to this story and consider these ideas and would immediately dismiss them. "You might get architectural decoupling but the performance is going to suck". Yes you would think so, but that is to miss one very significant property of the Web: State can be cached since it has a resource identifier.

More Flexible and Faster

For the computer scientist, in NetKernel's resource oriented computing abstraction all functions have extrinsic memoization. Referential integrity is externally managed by the computation environment.

In resource oriented computing every request that invokes a function has a resource identifier. All state, including all intermediate state, can be cached.

The really interesting thing is that the real world obeys natural statistical distributions. It turns out that more often than not you frequently need the state of the same set of resources. Even inside low-level code. So there is a net value in holding onto state.

Completely counter intuitively, it turns out that decoupling the internals of software actually makes it faster!

At what cost?

I've heard too many cynical marketing stories about the benefits of this technology or that technology.

We all know that adopting a new technology comes at a cost. You have to learn it and you hope that the effort in learning it is going to pay you back.

As encouragement, there's one more property of building software this way. Stepping away from the code and thinking in terms of resources is scale invariant - that is, you can compose higher-order resources from lower-order resources (in the Web this is called a "mashup" - but that's a hideous expression!).

You can apply transforms to resources to create new resources which themselves can be composed.

When you apply ROC to real world software engineering, the scale of problems that you are able to solve goes up but the complexity remains finite. Its like moving from being first violinist in the orchestra to being the conductor.

Research History

Resource oriented computing has a solid historical and theoretical foundation. As described in the ROC Nutshell document:

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.

NetKernel started as a project in HP labs in 1999 to answer fundamental questions about software systems. It became a product of 1060 Research, Ltd. in 2002. When NetKernel 3 was released in 2005, work began on an entirely new kernel and a simplified and more powerful abstraction. The result of these four years of work was NetKernel 4. Building upon this foundation NetKernel 5 integrates over three years of production refinements to the libraries and tools but also provides a new set of optimisations to the core microkernel and foundations.