Accessors

In some ways NetKernel's software components are a transport independent generalization of Servlets.

A Servlet is bound to a URL address by the Servlet container. It receives HttpRequests on the HttpServlet interface that correspond with the HTTP verbs (POST, GET, PUT etc). The Servlet generates a resource by interacting with EJBs, or other Java-components, in the Java-domain (procedural Java classes).

NetKernel's analogous components are called Accessors.

A NetKernel URI address space may be bound to an Accessor class. A request for a URI which matches the URI address space will cause the Accessor class to be instantiated and a method on the IURAccessor interface to be called. Like Servlets, Accessors can generate a resource internally by interacting with Java components. However, in order to fulfil a request, an Accessor may issue further URI requests to the NetKernel system.

Figure1. HttpServlet and Accessors approach to the URI Address Space.

The use of the term "Accessor" is very deliberate. An Accessor accesses a resource, either by generating it internally or by issuing further requests. An Accessor is a client/server node located in the internal NetKernel URI address space. As well as hosting business logic and services, Accessors are the components used to house external client gateways to the outside world, as can be shown with an example.

Example file: request

A resource on the local file system can be accessed with the conventional file: URI scheme. NetKernel provides a File Accessor which services all URI requests in the file: scheme - so, for example, a request to SOURCE file:///C:\path\resource.xml will cause the kernel to find and instantiate the File Accessor class and invoke the asyncRequest() method on it. The File Accessor will locate the file on the host file system and return a byte-stream representation of the resource.