NetKernel Addresses

All resources within NetKernel are identified by URI addresses. A URI address is defined by the industry standard, IETF RFC 3986 which describes the standard addressing identifier for Internet resources. A URI address is comprised of a scheme-name, the colon character (":") and a scheme-specific part. Here are some example URIs that will be familiar.

The http: scheme is used here to reference a web site:

http://www.1060research.com/

The file: scheme is used to reference a file on a computer system:

file:///home/adam/info.txt

A URI address is logical. Unlike a physical address that references a fixed memory location a URI address must be resolved to a physical software endpoint each time it is used. (The URI address resolution process adds about 3% overhead which is more than compensated for by internal caching.)

Several new URI schemes have been developed for use in identifying software components and resources within NetKernel. The ffcpl: scheme is similar to the file: scheme and locates resources within a NetKernel module. The active: scheme supports the specification of a parameterized service request.

To see how NetKernel uses URI addresses to identify resources use the following demonstration. From the Choose Demo drop-down select a demonstration - doing so will fill in the gray area with a logical URI address. Use the Make URI Request button to issue a resource request to NetKernel. A resource request is the fundamental instruction in NetKernel - it is like an op-code or a Java byte code. Keep in mind that this demonstrates the lowest level in NetKernel. Application development will utilize higher level languages; you will not build a system by programming in op-codes!

When you issue a resource request with this demonstration you will see a new page in your browser. To get back here use your browser's back button. For now, select Customers, Splash Screen and then Message and see the results of the requests.

Choose Demo: Select... Customers Splash Screen Message Greeting Capitalize Greeting Format Customer

Description:

Request URI:

Suggestion:

You will notice that a request for the resource ffcpl:/customers returns an XML document, a request for ffcpl:/splash-screen returns a PNG image and a request for ffcpl:/message returns an audio stream. This illustrates the independence of the logical level and the physical level of concrete representations. For example, the request for ffcpl:/customers could have returned an image instead of an XML document.

There are two important things to understand about logical addressing and resources. First, the returned physical representation is fully independent from the logical address. By this we mean that the logical address in no way prescribes the physical form of the returned representation. (later you will learn how a client can specify a preferred physical representation type in a request). Second, there is no indication as to how the representation is generated. In fact a logical address can be mapped to:

• A static resource
• A Java class that implements code to generate a physical representation.
• Another URI address
• An active: URI that defines a functional program

NetKernel URI addressing is consistent - a URI address always refers to a resource, it is the implementation behind the URI address that can vary.

active Scheme

The active scheme is an internal NetKernel URI scheme that supports service calls with an extensible set of parameters. The scheme-specific part of the active scheme starts the identity of a service, followed by a series of named parameters and their associated value-references. Parameters are demarked by the plus ("+") symbol.

active:{service-name}+{parameter-name}@{uri}+...

In the demonstration area (above) select Capitalize Greeting and notice that the URI is set to

active:toUpper+operand@ffcpl:/resource/data/greeting.txt

When requested, this URI causes the toUpper service to be called with a resource reference to the text to be capitalized. You can change the operand argument. Try substituting a remote resource reference such as http://1060.org/upload/readme.txt

For a final example, select Format Customer in the demonstration. This sets the URI to a functional program that uses the XSLT service to format the customer XML document into an HTML display page.

Resource, Address, Program

In NetKernel a resource is identified by a URI. A URI address can be a functional program that computes the resource representation. In the last example, the URI:

active:xslt
      +operator@ffcpl:/resource/scripts/customerToHTML.xsl
      +operand@ffcpl:/resource/data/customers.xml

is the full functional program for the resource computation and it is also the unique identity of the resource. The implication is that, just like in the Web, the URI identifier can be used as the key in a cache that stores the computed representation. This means that code in NetKernel is executed only when a resource value is not already known. This results in very significant computational savings with the consequence of self-tuning, high performance systems.