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...

NetKernel and Resource Oriented Computing

Software developers build applications and systems with NetKernel by making requests for information resources and receive back representations of the state of those resources.

If you want a very simple analogy for how NetKernel works, it takes the core principles of the Web and applies them internally to the fundamentals of software.

Crazy Idea

It turns out that when you go down this path 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.