Requests

NetKernel uses a generalized set of request types - SOURCE, SINK, DELETE, EXISTS, NEW which are internally consistent and independent of any application protocol. Those familiar with REST will recognise this is similar to the HTTP verbs. Commonly accessors will handle SOURCE requests. The file accessor also handles the other request types so it can be used, for example, to test for the existence of a file.

The file: example shows how an entire URI scheme can be handled by an Accessor. However this does not demonstrate how NetKernel performs dynamic invocation of URI service interfaces.

Active URIs

A structured specialisation of the general URI syntax, called an Active URI, is usually used to invoke services. An Active URI may contain multiple named arguments, each argument is a further nested URI.

Here's an example of an Active URI to invoke an XSLT service which applies an XSL transform, specified by the operator URI, to the XML resource, specified by the operand URI.

active:xslt+operand@file:///C:\path\resource.xml+operator@file:///C:\path\transform.xsl

The '+' is a delimiter between arguments, the '@' is a delimiter between argument names and argument URIs. The example active URI should be parsed as

active:xslt+operand@file:///C:\path\resource.xml+operator@file:///C:\path\transform.xsl

Where xslt is the URI of the service, operand is the name of a URI to a resource that is the subject of an operation, operator is the name of a URI to resource that is the operation to be applied. An active URI can use any appropriate names for arguments - "operand/operator" is a convention we have adopted for many of the standard services supplied with NetKernel.

Just-in-time evaluation

The active URI is an important construct. Since a named argument is a URI, then it can also be another active URI. This allows a sequence of requests to be composed into a deep active URI call-stack which need only be evaluated when a resource must be interrogated to determine process flow. So the resolution of an active URI by the microkernel can be thought of as lazy evaluation - in the Java world we're probably better off calling this Just-in-time evaluation.

For those familiar with functional programming, the active URI in combination with the NetKernel URI address space is a functional program.

Fragments

Fragment identifiers (signified after the '#' part of a URI) are a core part of the specification of a URI. Despite the deceptive name fragment identifiers can be used for more than identifying a fragment of a resource. A fragment identifier is a general purpose post-request transformation identifier. Different types of resouces may support different fragment identifier specifications. NetKernel supports plugable components called Fragmentors to support fragment identifiers attached to URI requests.

Making Active URI Requests

The concept of an active URI is applied universally within NetKernel. However in general, by writing processes using a high-level runtime language, it is not necessary to actually use active URIs directly. When writing custom components or scripting processes you will discover that the NetKernel Foundation API also provides convenience methods which assist in constructing and issuing active URI requests - including providing support for pass-by value as well as pass by reference arguments.