We have seen that the fundamental operation in NetKernel is the resource request. Most application development work will involve composing systems at the logical level using resources and services. While working at the logical level is productive and leads to flexible and fast applications, actual computational work is done beneath at the physical level. The following diagram illustrates how an Accessor sits at the boundary between the logical and physical levels.

When a resource request is sent to NetKernel the URI address is resolved within an address space to a software endpoint, the accessor. The accessor is presented with the request and associated parameters. The accessor then uses whatever physical level data, objects and libraries it needs to perform its work and then returns a response with a resource representation. Accessor code may be written in any supported language in NetKernel including Java, JavaScript, Beanshell, Python, Groovy or Ruby. (When you visit the Code First introduction you will see Java, Beanshell and JavaScript examples of accessors) Even requests for static physical representations using the ffcpl: scheme are sent to an accessor - in this case the accessor that implements the ffcpl: scheme.

We have already seen how the active: scheme is used to activate services and pass parameters in a single resource request. Let's take a closer look at how this works at the boundary between the logical and physical layers.

When a request for the URI

active:xslt+operator@ffcpl:/src/format/style.xsl+operand@ffcpl:/src/book/chapter.xml

is sent to NetKernel it resolves active:xslt to the xslt service endpoint. It then sends the request to the physical level code.

The following diagram shows the xslt service being called with the XML resource to be transformed by the XSL instructions in another resource. At the physical level we show that the service relies on the Xerces open-source library.

Note that the xslt service is stateless - it does not remember anything between calls. All that it needs to perform its work is provided when it is called (This is an example of a RESTful service). Also note that the operand and operator arguments are URI addresses - not the resources themselves. To get these resources, the xslt service must issue sub-requests for each one and in the responses get the actual representations.

The xslt service does not need to know any specific details about how the representations are generated or delivered. All it does is ask for them in a sub-request and uses the returned representations when they are available. This logical coupling at the resource level provides an architecture that is innately loosely coupled, late bound, and infinitely flexible. For example, the ffcpl:/src/format/style.xsl resource could be mapped to:

• A remote resource
• A database query
• A style generating service which uses its own configuration information.
• A static file

And, not only does the xslt service not care how the resources are provided, the mapping could be changed at any time while the system is running 24*7. This flexibility is practically impossible to achieve in a system implemented using traditional physical code. In NetKernel, this flexibility is inherent in the system.

Transports

Where do the original requests come from?

While we are looking at the boundary between the logical and the physical we should briefly explore how requests originate. In NetKernel a transport acts as an event detector and bridge from the outside world. For example, the HTTP transport listens for an HTTP request and when one is detected, it creates a corresponding request and injects this as a root request into an address space. When the response to the root request arrives, the HTTP transport packages it up into a suitable form and returns it to the external client. NetKernel provides several transports including HTTP, JMS and Cron.