NetKernel REST

NetKernel provides a generalized abstraction extrapolating from the core architectural principles of REST. NetKernel REST is a simple, standards compliant model that provides a robust and powerful software development environment.

Resource Oriented

NetKernel manages information as explicitly identified resources. This includes items such as text files, images, etc., as well as executable code, the compiled form of executable code, and most importantly, the computational results of code execution.

Just as in REST, resources in NetKernel are intangible. Resources take concrete form as a representation, an immutable copy of the resource's information. Immutable representations may be intrinsically cached, eliminating the need to re-execute many computations in the normal operation of a system.

URI Addressing

In NetKernel all resources are addressed by URI, including executable code and computed results. URI addressing implicitly requires a contextual URI address space within which resources may be located - we shall see in a moment how NetKernel defines URI address spaces.

Protocol Independent Verbs

In the traditional view of REST, the protocol is HTTP and operations on resources are specified by an associated set of verbs: GET, PUT, POST, DELETE, HEAD, etc.

NetKernel is application protocol and transport independent. It recognizes a simple generalized set of verbs: SOURCE, SINK, DELETE, EXISTS, and NEW. These verbs qualify the action to be performed for a given URI request.

URI Address Spaces

Web addresses, from the perspective of the World Wide Web Consortium (W3C), are considered to be universal and absolute. This is important when you consider the Web from a global perspective. It enables anyone, anywhere to type http://www.1060research.com into a browser and get the same resource representation.

But URI addressing implies that there is a context in which to resolve the resource. In the Web, this context is provided by the DNS system for naming and locating Internet servers. NetKernel is a generalized abstraction independent of network infrastructure and considers the absolute address space of the World Wide Web to be a special case of a generalized model.

NetKernel makes explicit the context in which a URI request is to be resolved and by doing so it allows any number of independent URI address spaces to coexist and interoperate. One of these contexts happens to be the DNS-resolved address space of the Web. From the perspective of NetKernel, all URI address spaces are local with respect to the request context, its just that some contain more resources than others.

This probably sounds a little esoteric and abstract but we shall see shortly that with this generalization, NetKernel supports an adaptable and modular URI address space which can be composed to create solutions.

Active URI

We have stated that code and the computed results from the execution of code are considered to be URI addressed resources within NetKernel. To be REST compliant, the request for code execution must be expressed as a URI address that contains all information necessary to compute the result. From this, it is a small step to realize that the URI requesting a computed resource is the full expression of the program that computes that resource.

1060 Research and Hewlett-Packard have proposed, through the IETF, the "active URI scheme". This scheme makes it possible to construct URIs that describe the computation of a resource.

Here is an active URI that uniquely describes a resource computed from the transformation of an XML document by an XSLT stylesheet...

active:xslt+operand@file:///path/report.xml+operator@file:///path/style.xsl

The active URI consists of a base-part, in this case active:xslt, and any number of named arguments, here 'operand' and 'operator', which are themselves URIs. The active URI is described in detail with examples here.

The "active:" URI scheme is 100% compatible with the URI specification. Significantly, the active URI allows named URIs to be included and these named arguments may also be active URIs. This mean that an active URI may embody an arbitrary functional program used to compute the requested resource.

Each representation resulting from an active URI request is potentially cacheable. With resource requests expressed as a composition of active URI requests, applications written in NetKernel acquire intrinsic and transparent caching at the finest granularity. Significantly the execution of a program is the RESTful evaluation of the URI vector through the URI address space context. If any given path through the space has already been computed then it does not need to be recomputed. This is a very significant breakthrough and completely unlike procedural method invocation and means that the computational cost for any resource is always a guaranteed local minima!

Returning to the URI address space discussion. We now begin to see that the NetKernel abstraction permits us to think in terms of URI address spaces as the bounded set of all possible computations. That is, all resources have a location -- even ones that have not yet been computed. All that is needed to obtain a representation of a resource is to walk the URI vector through the space.

Multi-dimensional Addressing - a new dimension for REST

We mentioned earlier in the REST discussion that one of the challenges of implementing RESTful applications is mapping the application data model into the constricted and linear URL path. With named arguments in the active URI scheme we are free to add as many independent dimensions (paths) to the URI address as we desire. Therefore we may readily take any information model and cleanly express a RESTful URI interface - making it straightforward to meet the RESTful requirement for explicit information passing.

Stateless Services

Executable code is embodied in NetKernel as services or functions that can be invoked by URI requests. Code is seen as the gateway by which the representation of a resource can be accessed - hence NetKernel's service components are called accessors. Just as in REST, the scalability and future flexibility of NetKernel solutions is guaranteed if the service implementations are stateless.

Language Runtimes

NetKernel constitutes a new development philosophy we have called 'Resource Oriented Programming'. One consequence of this is that executable code itself can be considered a resource. A class of services we call 'Language Runtimes' provide language/code execution services - the code is RESTfully transferred to a service for execution - that is, code is transferable state.

A wide variety of language runtimes are provided with NetKernel so that existing coding skills can be used to develop NetKernel solutions. Languages range from general purpose scripting languages, through resource specific languages (notably XML languages) and on to declarative languages for routing and mapping requests in the address space. Languages are unified by the common pattern that code is transferred to a language execution service for processing - when the code is completed the language runtime returns to being stateless.

Of course, since code is a processable resource, it is very easy to write code which writes code. Whilst such patterns are not always advisable, they can often lead to elegant simplifications as the boundary between configuration and code blurs.

Loose Typing

In NetKernel all services are untyped - they are URI locations that return a resource representation. As in REST, the client to the URI service is responsible for determining how to process the returned representation. However NetKernel is implemented on top of the Java virtual machine so resource representations have embodiments which are implemented with a resource object model - we call such concrete immutable instances of a resource representation: aspects. An aspect is a view (a perspective, a structure) of the information of the resource. The idea of Aspects does not exist in REST since you can only send binary data over the wire.

Representational Aspects must be immutable since they are cacheable concrete instances of a resource - and as such they will be shared and could be distributed to many other services. In object oriented terms, Aspects are (immutable) Value Objects.

Transreption

When a requesting client makes a URI request it may also indicate the object model interface (Aspect) that the resource representation should have. The called service will return the resource representation with an Aspect that is locally appropriate for it - typically an object model that it has been implemented to use. If this is not the aspect that was desired by the client then NetKernel will recognize this and will try to locate a registered component that can furnish the resource representation with the desired aspect. This operation is an isomorphic transformation - only the structure and not substance of the information is changed - this concept does not exist in REST or any other computation environment. We call this 'TransRepresentation' or transreption, for short.

Transreption is powerful since it decouples the relationship between client and service within the software system. It is also leads to great efficiency since in essence it performs a reduction in entropy of information - by ordering information into higher forms it becomes more efficient to process. Since all resources are cacheable then the cost of transreption is usually a one time hit that subsequently is not paid by any future user of the resource.

Finally, it transpires that compilation is an example of transreption in which source code information is ordered into an efficient machine executable form. As a consequence, all of NetKernel's languages and services employ dynamic compilation using transreptors.

NetKernel Summary

NetKernel is a new computational model that makes REST based development suitable for systems of any scale - from very small embedded to global sized applications. Enhancements and refinements to the REST model introduced by NetKernel yield extraordinary properties that have resulted in rapid development of very high performance applications that have a low life-cycle maintenance cost. Because these enhancements significantly extend REST we call the NetKernel embodiment NetKernel REST.

NetKernel REST and the Internet

As explored earlier, REST within the context of the World Wide Web is a constrained version of NetKernel REST. At the boundary, all of the principles of NetKernel REST and REST map cleanly and in fact, distributed applications that push the more flexible NetKernel REST concepts across computing nodes and across the Internet are possible.

In addition, NetKernel and NetKernel REST are application protocol (transport) independent. This means that RESTful system properties can be brought to any category of application. For example RESTful email applications are easy to conceive and create in NetKernel. To see how NetKernel REST can impact application design and how NetKernel enables the creation of custom resource models within the NetKernel REST domain explore the RESTful version of the Ping Pong game included in the NetKernel distribution.