NetKernel Address Spaces

All resources within NetKernel are identified by URIs which are resolved to a physical software endpoint capable of returning a physical resource representation. Logical addresses are resolved within a context - an address space. Unlike the World Wide Web which has only one address space, NetKernel supports the use of multiple related address spaces.

When NetKernel resolves an address, it examines the address space within which the request was issued. If it fails to find a resource there, it will next examine related address spaces until it either finds the resource or must report a resolution failure.

The following example illustrates how NetKernel's address spaces support true loosely coupled systems. In this example, the primary address space, "A" imports address space "B" and address space "C". Address space "B" contains a Beanshell dynamic language service, identified by URI active:beanshell, which when called executes the beanshell script referenced by the operator parameter. Address space "C" contains an xslt transformation service, identified by URI active:xslt.

When the request

active:beanshell+operator@ffcpl:/fn.bsh

is issued in address space "A" the following steps occur:

• Address space "A" is searched for active:beanshell. It is not found.
• Imported address space "B" is searched for active:beanshell. It is found, the beanshell language runtime accessor is invoked in "B" and it receives the operator parameter URI identifying the dynamic beanshell script to execute.
• The beanshell accessor makes a request for ffcpl:/fn.bsh within its address space "B".
• Address space "B" is searched for ffcpl:/fn.bsh. It is not found.
• The search continues up the address-space stack into address space "A" where ffcpl:/fn.bsh is found. The beanshell accessor receives the script resource representation which it executes.

It can be seen that NetKernel's URI addressing allows dynamic languages to be easily incorporated as a natural part of the dynamic software system. Now let's suppose that the script ffpcl:fn.bsh is written to make its own URI service calls. Lets say that one of its operations is to perform an XSLT transform. It can do this by calling the active:xslt service...

• The script issues a sub-request for active:xslt.
• Address space "B" is searched for active:xslt. It is not found.
• The search continues up the address-space callstack into address space "A". active:xslt is not found.
• Imported address space "C" is searched and active:xslt is found and run - the ffcpl:/fn.bsh script receives the transformation result as the response.

This example illustrates true loose coupling. The active:beanshell service is able to run a script located in a module it does not import. Furthermore, that script calls on a function that exists in address space "C", a foreign address space that is neither imported nor located in the immediate call-stack. Notice also that each service and resource is completely independent. There is no need for any of them to know about the others until final resolution occurs for a request. The context created by the application at runtime is sufficient to ensure that the system is correctly linked.

Address Space Mappings

In ROC and NetKernel it is possible to map one logical address to another. In fact it is possible to map regions of an address space to another. Using such a mapping makes it easy to create layers of logical address spaces and to architecturally partition a system.

For example, the following logical mapping uses Regular Expression pattern matching to create a new service (accessor) named "style-customers" that maps onto the customer formatting demonstrated earlier in the demonstration system. (The "(.*)" part of the match rule captures all text following "+customer@" and makes it available to the "to" rule as the variable "$1".)

Try using active:styleCustomers in the demonstration system.

This example illustrates a couple of concepts. First, layering in NetKernel is very easy. The definition of the "styleCustomer" accessor is layered on top of a constrained use of the "xslt" accessor. Second, like in Unix, powerful new software capabilities can be created by composing simple service-based tools together and abstracting behind a new URI interface.

NetKernel's use of URI addresses supports the composition of very sophisticated applications and services with minimal code and logic.